►
From YouTube: IETF113-RTGAREA-20220323-0900
Description
RTGAREA meeting session at IETF113
2022/03/23 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
B
B
Okay,
so
again,
good
morning,
it's
1001
here
in
vienna
good
afternoon
good
evening
to
everyone
else.
Thank
you
for
being
here.
This
is
the
routing
area
open
meeting.
It
was
pointed
out
that
you
know
this
is
not
the
first
time
we
have
a
hybrid
meeting.
We've
always
had
hybrid
meetings.
The
difference
this
time
is
that
we
have
a
lot
less
people
on
site.
Of
course,
I
am
alvaro
and
we
have
john
and
andrew
on
the
screen.
B
B
We
can
okay,
so
let's
there
we
go,
hey
sorry!
No!
No!
This
is
great.
So
this
is
the
time
of
the
year
where
we
have
four
of
these
here
in
front
of
the
room,
because
today
is
the
day
where
we
have
the
changing
of
the
dots.
If
you
want
to
see
the
exciting
ceremony
later
on,
the
plenary
is
tonight
where
the
formal
change
of
leadership
will
happen.
B
If
you
were
saying
something
you
were
muted,
but
so
we've
all
have
seen
the
noteworth
slide,
we're
familiar
with
it.
Please
keep
in
mind
that
this
is
not
just
about
intellectual
property
and
contributions.
It's
about
behavior
as
well.
There
are
links
to
a
number
of
bcps
down
there
and
we
chose
to
highlight
a
couple
of
the
things
from
rc7154
about
behavior
treat
people
respect
speak
slowly
at
the
mic,
keep
in
mind
that
there
are
people
from
all
around
the
world.
They
speak
different
languages.
B
This
is
about
engineering.
Let's
keep
the
the
discussions
technical
to
try
and
find
what
the
best
solution
for
the
internet
is.
This
should
be
something
that
we
all
keep
in
mind,
not
just
when
speaking
at
the
mic,
but
we're
interacting
with
others
at
the
meetings
through
the
through
the
iem
and
also,
of
course,
on
email.
After
after
the
meetings
next
yeah,
we
have
a
couple
of
meeting
tips,
hopefully
you're
all
familiar
with
the
different
buttons.
B
By
now,
in
the
mute,
echo
interface
and
in
the
agenda
that
little
phone
icon,
there
is
the
one
where
you
can
locally
hear
in
vienna,
get
onto
meet
echo,
get
onto
the
queue
et
cetera
things
like
that
for
the
remote
participants
make
sure
that
you
share
audio
and
video
when
you
are
speaking
and
turn
it
off.
Otherwise,
video
is
fine
if
you're
presenting.
B
B
We
have
some
general
links
to
other
resources
here
in
vienna
or
here
in
the
ietf113.
B
Next,
we're
always
looking
for
feedback
about
us
sads.
How
are
we
doing?
What
can
we
do
better?
There's
you
know
always
something
that
that
can
be
improved,
really
good.
You
know
it's
always
nice
to
hear
that
as
well,
not
only
about
our
performers
but
about
the
area
in
general
as
well.
B
What
needs
fixing,
because
it's
broken,
what
is
actually
working,
what
can
be
enhanced?
Maybe
it's
not
broken,
but
yeah.
We
can
do
something
better,
please
you
can
come
to
us
individually.
You
can
go
to
any
of
us
at
any
point.
B
B
Please
please
please!
So
here's
the
agenda
for
today
we're
going
to
spend
some
minutes
on.
Just
you
know,
administrative
stuff,
then
we're
going
to
have
some
working
group
updates
in
this
order.
If
you're
here
in
the
room,
please
come
up
here
to
the
microphone.
B
I
said
before
that
this
is
the
time
of
the
year
when
we
change
leadership.
Martin
ends
today
his
four-year
10
years
in
80..
During
these
four
years,
I
have
been
truly
honored
to
work
with
him.
He
has,
I
can
very
confidently
say,
had
the
the
full
experience
of
being
an
ad
a.d,
an
isg
member.
B
He
has
had
all
types
of
working
groups,
working
groups
that
are
quiet,
nice
work
in
groups
that
are
not
so
quiet,
and
so
nice
he's
even
been
able
to
help
us
with
the
other
ids
in
resolving
conflict
and
stepping
in
to
resolve
conflict
and
other
working
groups.
Thank
you
for
that.
B
B
B
In
there
he
has
been
shepherding
several
buffs
buffs
that
have
had
impact
on
different
areas
where
he
has
had
to
interact
with
not
just
ads,
but
but
people
and
everywhere
from
the
application
area,
security
transport
everywhere
he
has
shepherded
buffs
around
work
that
has
to
do
with
other
sdos,
where
the
ietf
has
had
to
engage,
and
you
know
liaison
exchange
and
discussions
about
whether
the
atf
should
do
work
or
not
in
relation
to
other
work
going
on
elsewhere
in
the
industry.
B
He
has
pretty
much
done
it
all
in
these
four
years
and
he
still
has
found
time
to
review
documents
to
participate
in
asg
discussions
and
to
spend
time
with
his
family
he's
not
here
at
the
atf
he's
spending
some
time
in
in
normandy
with
his
wife
and
his
son
or
skin
in
the
alps.
B
So
thank
you,
martin
for
all
the
work,
the
time
and
the
dedication
that
you
have
put
into
these
last
four
years
for
the
atf,
and
we
know
that
you
will
keep
putting
in
more
time
and
more
dedication
and
more
effort
in
the
future.
Please.
I
know
that
martin's,
not
here
physically
or
in
any
of
your
homes
either.
B
C
Thank
you
very
much
alvaro
for
this
very
touching
long
series
of
words.
You
were
talking
about
family,
I'm
actually
taking
my
son
to
school.
I'm
sorry
life
has
been
messy,
we're
just
out
of
a
second
coved
in
four
months,
so
I'm
trying
to
cope.
Thank
you.
Thank
you
very
much
and
thank
you
all
for
being
kind
enough
with
me.
Over
these
three
years.
C
Thank
you.
No
I'm
I'm
very
touched
and
I'll
think
of
a
longer
message,
and
I
wish
all
of
you
three
all
the
best
so
john
alvaro
and
and
anando
for
this
new
cycle.
Thank
you
again.
B
So
we
have
our
newer,
the
andrew
he's
on
the
screen
andrew.
You
want
to
say
a
few
words
introduce
yourself.
F
Yeah
hi,
I
didn't
really
bargain
on
saying
anything,
but
I
just
wanted
to
say
that
I
think
it's
an
honor
and
a
privilege
and
I
will
do
the
best
I
can
and
I'm
always
open
to
anybody
approaching
me
if
you
want
to
chat
or
anything.
F
B
G
Thomas
eckerd
yeah,
I
was
on
nom-com
this
year
and
I
just
wanted
to
say
thank
you
very
much
that
we
had
three
excellent
candidates
on
on
the
roster
a
lot
more
than
other
areas,
right
so
very
happy
about
that,
and
also
about
all
the
feedback.
G
We
got
from
the
individuals
to
help
us
make
the
hard
decisions
so,
and
I
think
it
would
be
great
if
we
get
even
more
people
from
the
routing
community
next
year
around
I'll,
have
to
say
that
maybe
to
the
three
of
you,
I'm
not
sure
I
haven't
seen
something
comparable
to
what
the
warren
did
in
the
ops
area.
I'm
trying
to
you
know,
question
the
community
to
you,
know,
prepare
for
next
year's
nomcom
and
get
even
more
candidates,
so
that
and
also
the
feedback
from
the
community
so
but
yeah.
G
Thank
you
very
much
again
to
to
the
three
of
you
and
welcome
andrew
to
your
new
job.
B
B
So
you
know
he's
trying
to
you
know,
build
up
a
group
of
names
right
to
consider.
Sometimes
we
know
you
because
you
participate.
Sometimes
we
don't
know
if
you're
interested
or
not-
and
you
know
same
applies
here
if
you,
if
you
want
to,
if
you're
interested
in
participating
in
any
of
the
positions,
please
let
us
know
if
you
want
to
know
more
about
what
it
takes
day-to-day
to
be
the
work
of
the
nad.
B
Please
approach
any
of
us
we'll
be
very
happy
to
tell
you
the
all
the
exciting
perks,
the
extra
pay,
the
extra
food
that
we
get.
You
know
et
cetera,
and
you
know
all
the
sort
of
extra
work
that
we
have
as
well.
B
It
is
important
that
we
maintain
you
know
continuity
of
the
atf
there's
been
yeah,
there's
a
lot
of
work,
good
work,
important
work
that
we
do
so.
Yes,
please
think
about
it
and
you
know
there's
opportunities.
All
the
time.
B
Great
so,
besides
the
huge
change
of
course
of
ads,
the
area
hasn't
changed
a
lot
more.
We
don't
haven't,
opened
or
closed
any
working
groups
or
recharge
or
anything
in
the
last
year
or
since
last
meeting,
and
we
don't
have
any
new
chairs.
We
have
two
buffs
that
have
been
approved.
B
One
is
called
msr-6
for
multicast
segment,
routing
with
ipv6,
there's
a
buff
that
we
approved,
but
we
haven't
held
it.
Yet
we
have
been
working
with
the
proponents
to
get
them
ready,
we're
probably
going
to
have
a
interim
buff
sometime
before
ietf
114..
B
D
Wasn't
targeted
towards
creating
a
working
group?
I
think
a
lot
of
you
were
there.
There
was
a
great
deal
of
energy.
I
thought
at
the
the
buff
a
lot
of
good
back
and
forth
with
the
proponents.
D
I'm
not
really
gonna
try
to
summarize
technical
outcomes,
because
that's
what
the
slide
sets
and
so
on
are
for,
but
I
think
it's
probably
the
the
big
takeaway
is
there
was
a
lot
of.
There
was
a
lot
of
energy
around
it.
There
was
good
feedback
to
the
components
that
probably
the
single
most
most
repeated
comment
was.
D
Please
don't
fix
your
problem
by
shoving
state
into
the
network,
of
course.
That
might
just
be
me
engaging
a
little
confirmation.
Bias
too,
or
I
should
say,
pushing
state
into
the
underlay,
which
is
a
different
thing,
and
subsequent
conversation
is
going
to
take
place
on
the
doncast
mailing
list,
anything
to
add
from
any
of
the
other
ideas
or
people
who
are
there
anyway.
I
do
encourage
people
to
get
on
the
mailing
list
and
engage
in
the
conversation,
because
I
think
that
this
will
be
a
continuing
topic.
B
B
Well,
that's
it!
If
you,
you
have
any
issues,
go
talk
to
your
id.
If
you
need
to
talk
to
anyone
else,
feel
free
to
talk
to
any
any
of
us
at
any
point,
so
we're
gonna
go
into
the
rest
of
the
agenda.
The
first
thing
that
we
have
is
a
report
from
the
routing
area
directorate,
haumean.
D
And
just
before
we
launch
into
that,
let
me
say
I
I've
been
flipping
slides
so
far.
I
will
continue
to
do
so
if
you
want
to,
if
you
want
me
to
pass
control
of
the
slide
clicker
to
you,
while
you're
speaking
just
let
me
know
and
I'll
I'll
hand
you
the
controls,
but
other
than
that,
just
you
know,
do
the
usual
next
slide
next
slide
thing.
H
First,
thank
you,
john
alvaro.
This
is
another
long
presentation,
so
please
help
to
flip
the
pages
and
yeah.
This
is
yeah
the
update
of
the
reporting
for
routing
direct
rate
and
this
team
is
composed
by
the
top
experts
from
rotting
average
yeah.
Second
page,
please
yeah.
H
Everybody
is
now
appointed
by
the
ads
and
actually
before,
right
before
this
meeting,
probably
in
the
january
and
february,
we
the
the
ads
work
on
some
personnel
changes
and
we
have
replaced
about
five
people
to
be
substituted
in
the
in
the
team.
So
this
will
be
a
kind
of
farewell
to
john
his
brand
dave
and
the
join
and
manaf.
H
They
left
the
team
because
of
different
reasons-
and
it's
time
to
say
thank
you
for
the
all
the
contribution
in
the
past
and
the
meanwhile,
we
are
welcoming
new
members,
xiaohui
jain,
trooping,
donna
and
muhammad.
H
So
we
wish
to
collaborate
with
you
in
the
future
and
as
euros.
The
purpose
for
this
team
is
to
review
the
drafts.
The
last
call
draft
and
early
review
to
the
routing
area
work
and
we
are
also
providing
the
review
for
some
related
working
other
area,
for
example
obs,
and
if
you
are
interested
you
understand
us.
Please
turn
the
chat
to
check
the
wiki
page
and
next,
please.
H
So
here
are
some
statistics
from
the
summary
of
statistics
since
the
last
ietf
and
we
have
theoretically
updated
this
figures
from
2020
and
we
have
now
more
than
100
early
review
and
last
call
review
so
far
and
from
last
itf
in
november
we
have
succeeded
in
three
early
reviews
and
the
13
last
call
reviews.
H
So
this
is
basically
in
normal
average,
from
only
the
numbers
of
review
request
and
we
also,
in
the
right
hand,
figure.
We
have
the
the
distribution
of
the
review
request
for
different
working
groups
and
the
top
three
would
be
idr
best
and
rsr.
H
So
finally,
yeah
this
is
the
distribution
or
the
percentage
of
the
result,
because
each
of
the
review
results
would
be
shared
with
working
group,
chairs
and
feedback
to
the
corresponding
working
groups
and
basically
for
rtg
area
for
rotting
every
drop.
So
we
are
having
around
1
100
of
that
and
basically,
we
have
one
third
of
them:
ready
have
nets
or
have
some
issues
only
a
few
of
them
label
as
not
ready
and
request
further
work
and
the
right
hand
will
list
all
the
non.
B
Presentation,
thank
you
so
much
yeah
the
wrath
director.
It
has
a
very
big
impact
on
how
on
the
quality
of
our
documents,
so
thank
you
so
much
to
everyone
who
who
has
participating
and
continue
participating
in
the
running
director.
B
B
So
we're
going
to
the
working
group
statuses-
this
is
you
know
a
few
minutes.
Five
six
minutes
or
so
per
working
group
talk
about
some
of
the
highlights
in
your
working
group.
So
beer,
tony
I'm
assuming
you're
here.
I
Yeah,
okay,
excellent
right
so
I'll
make
it
relatively
snappy
beer
bye.
Now
everybody
should
kind
of
know
what's
going
on
there
next
one,
please
usual
node!
Well,
next,
one,
please!
Okay!
So
we
active
a
bunch
of
rfc
is
published
about
17
active
drafts
on
the
work
last
call
2
is
g4
and
we
have
about
14
drafts
like
in
different
stages
of
discussion.
You
know
adoption
and
ideas
forthcoming
and
so
on.
So
this
is
the
amount
of
activity
next
one,
please,
okay,
so
what
was
notable
what
was
happening?
I
We
have
for
our
work
for
beer
going
on.
You
know
two
three
different
solutions
with
multiple
drafts:
good
discussions,
stuff
kind
of
converge,
last
issues
being
resolved
to
get
the
stuff
adopted,
the
tea
work,
the
brte
work
is
kind
of
finished.
The
stuff
is
being
published,
a
lot
of
spec
coming
out
there
from
jeffrey's
site
and
some
other
authors
multicast
as
a
service
is
going
on.
We
had
pretty
rough
going
by
the
dn
convergence
on
how
to
carry
beer
in
ipv6.
So
that's
done.
I
There
is
a
bunch
of
interesting
proposals
on
oam
and
work
going
on
the
no
aim,
so
those
are
kind
of
the
notable
things
stuff
I
didn't
put
up
here
so
we're
seeing
more
and
more
adoption
we're
seeing
some
new
silicon
and
we're
seeing
a
full
p4
implementation,
a
whole
of
giant
and
some
of
commercial
forks
are
getting
onto
a
beer
backbone,
the
traditional
motor,
because
it's
being
hooked
up
to
that,
so
there's
a
lot
of
activity
there.
Next
one.
I
think:
that's
it
yeah
thanks
we're
brewing
here.
J
Yeah,
so
let
me
just
give
a
brief
pim
summary.
J
From
darren,
nope
is
work,
that's
related
to
sigmund
routing
and
point
to
multiple
point
work
pim
as
a
reminder
is
protocols
for
ip
multicast
and
not
specific
to
protocol
independent
multicast,
and
so
a
couple
years
ago,
almost
in
working
with
the
spring
chairs
and
the
working
group
we've
taken
over
the
responsibility
of
segment,
routing
and
point
to
multiplayer
work
and
we've
just
had
an
informal
agreement
with
spring
to
address
such
proposals,
and
we
are
in
the
process
of
making
it
official
in
our
charter.
J
We
are
waiting
on
a
few
things
before
implementing
it,
but
basically
what
we'll
add
is
something
like
what
we
have
here
is
that
is
to
develop
a
point-to-multi-point
protocols,
including
srsrv6
p2mp
work
in
agreement
with
spring.
This
may
also
require
a
point-to-multipoint
protocols,
as
requested
from
other
working
groups
which
I'll
get
to
that
last
point
in
a
minute.
J
This
segment
routing
point
to
multipoint
work,
creates
a
policy
to
instantiate
a
point
to
multi-point
tree
by
stitching
replica
replication
segments
together,
and
the
replication
segment
itself
is
is
defined
in
spring.
So
we're
doing
the
p2mp
policy
in
pym.
There
is
a
lot
of
related
work,
that's
happening
in
other
working
groups
and
I'll
have
to
say
it
seems
to
be
working
pretty
well.
J
I
really
appreciate,
for
instance,
idr
just
recently
sue
reaching
out
to
us
and
other
working
groups
just
to
let
us
know
that
this
is
going
on
in
their
working
group
and
how
we
wanted
to
handle
it,
and
so
that
first
draft
you
see
there
is
being
is,
is
modifying
bgpls
and
so
it's
being
handled
in
idr.
J
Another
related
draft
is
being
worked
on
in
pce,
since
it's
specifying
extensions
to
psap
and
something
similar
and
best
as
well.
So
this
whole
area
in
the
past
has
been
somewhat
confusing
of
who
handles
what
it
seems
like
we've
kind
of
come
to
an
agreement
of
what
we
will
and
will
not
do.
J
I
think
for
pim
we're
taking
on
the
sr
related
work
in
relation
and
agreeing
with
spring
and
as
far
as
these
other
working
groups
are
concerned,
we'll
just
get
involved,
as
they
request
us
to
get
involved
and
they
seem
to
be
wanting
to
handle
their
own
point
to
multi-point
work.
In
their
own,
in
their
own
working
groups,
next
slide
and
last
slide.
So
there's
there's
other
work
as
well.
J
That's
somewhat
interesting,
of
course,
there's
the
yang
drafts
that
we've
been
working
on,
but
there
are
also
some
dr
improvement
related
drafts
in
pim.
Make
the
dr
election.
J
Less
likely
for
packet
loss
and
to
make
that
dr
election
more
sticky,
so
that,
like
when
a
new
dr
that
has
a
higher
priority,
comes
into
the
network,
it
doesn't
immediately
become
the
ddr,
but
the
the
other
one.
It
remains
as
the
dr
and
so
and
a
new
backup
designated
router
role,
which
is
also
being
proposed
that
we've
adopted,
which
will
immediately
take
over
without
much
packet
loss.
J
So
we
we
have
these
two
drafts
that
do
similar
things
just
kind
of
a
different
approach
and
we're
trying
to
decide
whether
we
progress
them
further
converge
them
and
we'll
be
talking
about
this
on
thursday
when
we
meet
and
then
just
some
other,
as
maybe
some
interesting
work
that
you
may
find
interesting
is
there
are
some
new
drafts
that
are
being
proposed,
such
as
pim
light,
which
there
may
be
some
instances
where
there's
some
interfaces
that
don't
want
to
have
the
overhead
of
a
pim,
neighbor
relationship,
but
still
want
to
accept,
joins
prunes
and
asserts,
and
so
there's
that
draft
that's
being
proposed
and
it'll
be
presented
this
week
and
there's
also
mrh.
J
K
L
Okay,
working,
hey
hello,
so
this
is
dr
speaking
here
I'm
going
to
make
a
quick
update
on
the
lsvr
working
group,
so
we
have
our
session
tomorrow
at
10
o'clock,
so
the
agenda,
what
I
prepared
in
a
couple
of
slides
is,
like
you
know,
first,
to
explain
where
we
are
with
the
lsvr
and
the
time
schedule,
quick
understanding
of
what
it
actually
is
and
then
we're
gonna
cover
the
the
next
steps
of
the
working
group
itself.
So
next
slide
please!
L
So
we
started
our
work,
so
we
got
like
created
around
idf
101,
so
that's
about
like
four
years
ago.
I
guess
which
is
quite
a
long
time,
and
then
we
were
given
a
shock.
You
know
to
be
in
existence
and
to
work
upon
upon
our
deliverables
for
about
like
two
years,
three
years
now
we
felt
a
little
bit
there
and
we're
still
working
on
this
thing
now
now.
The
good
thing
is
that
at
least
right
now
we
have
a
protocol
spec,
which
is
considered
to
be
ready
for
iesg.
L
It
went
through
a
few
cycles
through
the
routing
directory
that
we've
used
in
the
working
group.
It
went
to.
You
know
isg
already
they
set
it
back
and
now
we
also
have
confidence.
So
next
slide,
please
so
here
so
so
the
three
deliverables.
What
we
had
to
complete
at
the
end
of
this
working
group
would
be
an
applicability
applicability
statement,
the
ns3r
spec
and
the
description
of
how
you
know
each
link
state
vector
actually
looks
like
how
the
transport
actually
works.
So,
as
I
mentioned,
we
consider
this.
You
know
really.
J
L
And
the
work
we
have
is
ready
to
be
sent
towards
iesg
at
this
point
in
time.
Another
part
of
the
deliverable,
of
course,
is
also
we
need
to
manage
this
technology.
We
need
to
have
like
a
young
specification
for
that.
That
is,
spending
up
on
further
idr
work
on
bgp,
because
the
lsvr
you
know,
based
upon
bgp
short
forwarding,
is,
you
know,
leaning
a
lot
upon
the
bgp
technology
on
bgpls.
More
specifically,
so
next
slide,
please.
L
So
if
you
look
into
the
different
components,
so
we
can
actually
carve
them
up
into
four
different
sections
here.
So
we
first
look
at
the
bottom
one:
it's
like
each
router.
It
will
actually
have
like
link
states
that
needs
to
be
harvested
yeah
and
initially
we
were
looking
into
ltp
version
one
for
that,
but
what
we
discovered
is
that
there
may
be
no
there's
not
enough
space
in
an
llpp
packet
itself
to
describe
and
to
exchange
all
the
protocol
information
required.
L
So
we
developed
like
like
a
first
lucky
requirement
of
like
you
know
what
would
be
necessary
for
that,
and
then
we
developed
l3dl
and
we
also
worked
with
them
together
with
the
ieee
and
into
you
know,
enhancing
led
we
crafted
as
a
result
of
that
ldpv2
actually
was
created
from
that
now.
Once
we
have
the
listed
information
of
a
router,
it
needs
to
be
encoded
into
some
sort
of
a
common
understanding
of,
and
that
actually
needs
to
be
shared.
L
You
know
between
all
different
routers
within
a
particular
area,
and
that
is
done
by
you
know
rather
insane
distribution,
and
that
is
where
each
pspf
comes
into
place
in
the
pgp
technology,
and
on
top
of
that
we
also
are
using
like
spf
for
the
routing
table
calculation,
and
that
is
where
you
know
beach.
Dspf
deviates.
L
L
So
initially
you
know
when
we
were
looking
into
different
kind
of
solutions.
We
selected,
you
know
a
pgp
based
solution.
Why
is
because
you
know
bgp
is
really.
You
know
is
a
very
well
known
protocol.
It
is
stable,
it
scares,
you
know,
scales
a
lot,
it's
very
you
know
many
people
actually
know
there's
reliable
transport.
It
has
guaranteed.
You
know
deliveries.
All
you
know
fancy
and
good
things.
The
downside
of
what
pgp
is
is
that
this?
L
You
know
it
uses
like
part
hunting
and
it's
a
distance
detector
protocol
itself,
which
is
maybe
not
the
most
optimal
in
at
that
point
in
time
for
describing
a
topological
database
within
the
network
itself.
So
for
that
we
used
like
you
know,
we
decided
to
go
for
php
ls
on
that
one
and
change
the
way
it
calculates
the
routes
and
how
it
distributes
links
and
information
between
different
nodes.
L
L
L
It's
like
a
small
puzzle
piece
you
know
associated
with
it,
and
the
puzzle
piece
actually
describes
like
you
know,
who
am
I,
who
are
my
neighbors
and
what
its
customer
neighbors
together
with
some
other
link
properties
associated
with
it,
just
a
typical
graph,
what
you
would
see
with
the
classical
link
state
routing
protocol
itself?
But
in
this
case
these
pieces
of
the
puzzle
are
exchanged
by
using
your
php
ls
and,
more
specifically,
by
the
pgpspf
variant,
and
we
also.
L
Software
for
that
we
just
like
savvy
so
the
next
slide,
please
so
from
the
peering
models.
So
what
we
are
using
for
this
is
something
reasonably
simple,
well
known
again
and
we
will
be
using
actually
we
are
using
like
route
reflector
technologies
for
for
this.
Some
people
may
also
want
to
call
it
like
a
controller,
because
there
may
be
more
things
you
want
to
do
with
it.
L
You
know
you
know
and
be
a
bit
more
smart
on
how
you
actually
use
topology
harvester
through
the
bgp
spf,
but
in
essence,
use
like
a
hierarchy
of
output,
vectors
and
they're.
Not
necessarily,
you
know,
probably
going
to
be
like
directly
connected
to
each
other,
but
they
don't
have
to
be
so.
If
you
pre-load,
you
know
information,
they
don't
really
have
to
be
directly
connected.
So
next
slide.
L
Is
so
in
the
classical
part
of
the
algorithm?
You
have
like
the
two
phases
like
phase
one
and
we
still
playing
on
the
router.
So
first
you
get
like
you're,
not
using
you're
out
this
thing,
and
then
you
have
a
calculation
of
degree
of
preference
with
each
of
these
particular
entries.
Then
you
select
the
best
one
out
of
them
and
then
you
actually
forward
those
best
routes.
You
know
to
the
rest
of
your
neighbors,
so
what
is
done
in
lsvr
is
slightly
different
and
then
we
follow
what
spf
actually
is
doing
so
each
route.
L
In
this
case
you
know
each
piece
of
the
puzzle
here
will
have
like
a
unique
nlri.
The
other
will
get
it
it
will,
you
know,
put
it
into
its
database
itself
and
it
can
actually
directly
forward
it
towards.
You
know
all
other
others
and
all
other
neighbors
you
know
as
such,
and
then
it
can
actually
do
the
right
calculation,
the
best
part
selection
and
after
that,
so
that's
quite
quite
a
big
win
from
from
a
convergence
perspective
in
big
networks.
L
So
there
are
some
benefits
here
for
using
bgp
spf
compared
to
classical
bgps,
because
we
have
used
the
you
know
the
spf
technology
here,
which
means
you
don't
really
have
to
wait
upon,
selecting
the
best
part.
We
can
forward
the
nris
directly
and
then
do
the
calculation
afterwards,
and
we
also
have
because
we
have
you
know
the
bgpls
encoding
itself.
We
will
get
like
at
the
end
like
a
full
topological.
J
L
Now
so
we
have
like,
you
know
our
base
pack,
you
know
hp.
Spf
16
was
last
updated
with
the
yana
code
points
which
were
requested.
We
actually
have,
like
you
know,
almost
finished
draft,
also
of
the
l3dl
work.
Now
this
part
of
work
has
not
been
fully
in
line
with
what
we
were
short
of
to
do.
So
that
is
something
we
will
have
to
change
before.
We
can
progress
and
also
onwards
towards
the
iesg.
L
So
our
next
step,
actually
is
you
know.
First,
you
know
we
consider
that
the
key
rules
actually
are
completed
right
now,
so
the
base
pack
will
be
sent
up
towards
the
ift.
You
know
once
the
shepherd
actually
finds
the
time
for
that
and
then
next
you
know
we
have
to
go
through
a
resharper
to
include
to
work
l3dl
as
a
formal
part
of
the
working
group
itself,
so
that
we
can
actually,
you
know
formally.
L
This
and
as
as
a
as
a
formal
on
a
word
item
itself,
even
though
it
actually
has
been
progressed
in
you
know
where
we
are
then
of
course
also.
We
still
need
to
manage
this
whole
technology
itself,
so
we
need
to
have
a
young
specification
upon
that.
It
is
in
the
works,
but
it
is
waiting
on
an
idr
for
the
bgps
set
of
so
that
is
it
actually.
If
no
questions,
then
we
can
move
to
the
next
one.
M
N
M
Waiting
for
alberto
review,
yank
model
caught
up
with
the
latest
changes
to
the
base
pack,
so
working
room
plus
call
in
progress.
We
expect
to
finish
it
after
this
atf
key
value
registry
as
well
in
working
with
last
call
and
will
be
finished
after
the
atf.
M
How
to
avpn
there's
good
progress,
there's
already
implementation
of
it
segment,
routing
it's
in
progress,
normal
working
process
and
we
plan
to
adopt
it
as
a
working
group
document.
After
this
atf
and
multicast
there's
no
really
progress,
we
don't
see
a
lot
of
traction
in
the
industry.
So
for
time
being
it
just,
you
know,
back-end
questions.
M
O
O
So
the
approach
that
we
we
used-
and
we
are
still
using
in
defining
young
models
for
these
different
types
of
networks-
is
to
start
with
what
we
call
the
the
types.
As
you
can
see
here
we
have
the
layer,
zero
types
of
optical
network
and
layer,
one
types
for
for
routine
networks.
Basically,
this
is
a
common
data
type
which
needs
to
be
imported
for
for
double
zone
for
flexi
grid,
in
layer,
zero
and
four
of
rotian
in
layer
one.
O
We
are
actually
working
on
on
a
beast
for
the
for
player:
zero
for
layer,
zero
type
to
include
the
transformation,
transponders
and
impairment
awareness,
so,
as
you
as
you
can
see,
are
also
in
the
intellect
mallet.
So
we
did
pretty
a
lot
of
work
in
the
impairment
free
type
of
networking.
O
Basically,
we
assume
that
reachability
is
the
only
issue
when
connecting
when
connecting
devices.
In
this
type
of
approach,
we
define
the
topology
models.
This
is
what
we
call
a
double
zone
or
flexigrid
double
zone
is
a
optical
network
with
a
fixed
grid,
each
channel
as
a
fixed
lead
for
this
type
of
network.
So
we
have
defined
topology
and
panel
models.
We
did
the
same
for
flexible
grid
type
of
networks
where,
basically,
the
the
grid
is,
is
not
fixed
and
it's
possible
to
define
a
channel
with
the
configurable
frequency
and
the
channel
width.
O
Now
we
are
moving
towards
the
next
step,
the
one
abolded,
which
is
the
optical
impairments
topology.
This
is
something
that
will
allow
for
better
interoperability
between
different
different
vendors,
taking
into
consideration
our
optical
impairments
awareness
in
networking,
it's
something
that
is
making
things
absolutely
more
complex,
but
will
finally.
O
Break
the
fact
that
most
of
the
networks
come
from
from
a
single
vendor,
similar
work
is
done
in
innotiana,
where
likely
we
don't
have
to
deal
with
optical
impairments,
because
everything
is
electrical.
We
have
the
layer,
one
types
topology
tunnel
model
and
something
which
we
are
starting
to
work
right
now.
This
is
a
draft
that
we
recently
adopted,
which
is
audience
slicing.
O
We
are
discussing
about
the
possibility
to
do
network
slicing
at
the
lower
layers
so
lower
than
the
packet
switching.
There
is
quite
some
discussion
over
there
because
someone
believes
that
we
just
need
to
build
an
applicability
statement
on
how
to
use
the
end.
The
networks
for
network
slicing
someone
some
others
believe
that
otiana
deserve
its
own
slicing
methods
here.
Obviously,
a
lot
of
alignment
with
these
is
is
needed
because
they
are
the
owners
of
our
network
slicing,
and
I
mean
most
of
the
discussions
are
done
in
conjunction
with
with
them.
O
So
we
believe
that
the
alignment
is
there
for
microwave.
We
we've
been
working
on
the
modeling
of
radio
links
and
we
are
now
working
as
working
group
on
the
topology
next,
please
again
young
models.
So
we
are
not
just
working
on
topologies
and
tunnels,
but
also
services.
We
define
the
layer
one
service
model,
probably
now
we
are
not
considerate
yet,
but
maybe
with
some
alignment
with
the
ops
working
group
might
might
be
needed
here,
since
they
they
own
the
layer,
2
and
m
layer,
3
and
m
models.
O
This
is
this
is
something
we
need.
We
need
to
consider
client
signals
and
topologies
again,
the
the
transport
network
is
is
used
to
carry
upper
upper
layer.
Type
type
of
services
here
is
where
we
are
discussing
how
the
client
signals
are
carried
and
matched
over
lower
layer,
topologies
and
then
network
inventory.
Here,
probably,
we
need
some
alignment
with
the
with
other
working
groups.
So
basically
we
have.
This
is
a
new
individual
draft
that
has
been
recently
proposed
in
ccamp.
O
They
they
are
working
on
the
data
model
for
network
artery
inventory.
This
is
pretty
much
optical
related,
but
I
I
would
say
that
some.
O
Let
me
say:
non-technology-specific
work
is
is
needed
here,
so
here
we
are
seeking
for
your
advice
on
which
working
group
we
need
to
align
with.
O
O
How
to
use
all
the
young
models
are
defined
by
the
itf
on
the
northbound
interface
of
another
controller
of
an
sdn
controller.
Lmp
lmp
is
the
protocol
owned
by
camp
for
for
link
management.
We
have
some
extensions
for
lmp
there
and
then
some
new
york
new
work
on
the
usage
of
optical
networks
that
will
interconnect
data,
centers
and
cloud
in
the
next
slides.
O
We
have
a
very
short
example
of
the
two.
Let
me
say:
topics
where,
where,
where
alignment
with
other
working
groups
is,
is
being
done
or
is
needed,
as
I
mentioned
before,
otian
slicing
is
the
first
one
where
we
we
already
have
alignment
with.
That
is
ongoing,
as
you
can
see
on
the
right.
That's
the
architecture
defined
by
the
t
by
the
tis
working
group,
the
otn
slice
controller
is,
is
being
added
with
several
options
where
the
dotn
slice
controller
is
directly
connected
directly
controlled
by
the
end-to-end
orchestrator.
O
O
Here
I
stole
a
slide
from
the
presentation
that
the
team
working
on
network
inventor
is
going
to
provide
the
next
next
friday
during
the
second
session,
and
this
is
basically
to
highlight
the
the
the
question
that
we
are
asking
ourselves
is
is
here:
is
there
some
generic
work
that
needs
to
be
done
somewhere
else
and
then
in
c-camp?
We
need
to
augment
it.
O
Next
slide,
the
last
one
milestone
to
be
updated.
We
are
working
on
that
my
students
were
pretty
outdated.
We
will
present
our
proposal
to
the
working
group
on
on
friday
and
john
expected
to
receive
it
for
approval
immediately.
After
that's
it
from
our
side.
B
Thank
you,
daniela
we're
gonna
go
over
to
tees
hi.
P
Okay,
my
name
is
pawan
veera,
my
co-chair,
the
traffic
engineering
architecture
and
signaling
working
group
along
with
lou
burger,
luis
contreras,
is
our
working
group
secretary.
We
also
have
a
distinguished
tech
advisor
in
adrian
farrell,
who
keeps
us
honest
from
time
to
time.
For
those
of
you
who
don't
know
what
peace
working
group
does,
I
would
let
you
go
through
slides
two,
three
and
four
at
your
own
pace
and
reach
out
to
the
teased
chairs.
P
Okay,
so
we
currently
have
about
22
working
group
documents,
given
that
we
spend
a
lot
of
time
discussing
architectures,
it
shouldn't
be
a
surprise
that
there's
a
lot
of
te
specific
data,
modeling
work
that
gets
done
in
the
working
group.
There
are
weekly
open
design
meetings
that
are
happening
for
some
of
these.
These
are
primarily
driven
by
the
authors
of
the
various
modeling
drafts
and
are
open
to
all
so
do
check
those
meetings
out.
P
If
there's
anything
here
of
interest
to
you
most
of
these
modeling
efforts
are
nearing
completion,
so
it
would
be
great
to
get
some
thorough
reviews
in
rfc
3272.
It's
an
itf
classic
discusses
the
principles
of
internet
traffic
engineering.
The
only
problem
is
that
it
was
published
two
decades
back
and
is
tad
outdated
rather
more
than
a
tad
outdated.
We
revisited
the
documentary
and
it
was
rewritten
to
make
it
more
relevant
to
the
current
times.
P
The
editor
has
just
told
us
that
it's
ready
for
working
up
last
call.
Hopefully
this
will
last
for
the
next
two
decades,
so
again
seeking
thorough
reviews
for
that
document.
P
Actn,
which
stands
for
abstraction
and
control
of
t
networks,
it's
an
umbrella
term
for
a
set
of
management
and
control
functions
used
to
operate
one
or
more
t
networks.
These
functions
are
typically
used
to
construct
virtual
networks
that
are
then
presented
to
the
customers.
The
framework
for
this
was
published
a
few
years
back.
I
think
it
was
in
2018.
P
There
is
a
fair
bit
of
discussion
in
the
working
group
about
its
applicability
to
network
slicing
and
how
it
can
be
used
to
create
the
infrastructure
to
pin
a
network
slicing
service,
that's
enhanced
vpn.
Then
we
have
this
topic
of
network
slicing
itself,
which
has
been
hogging
a
majority
of
their
time
and
tease
working
group
sessions.
For
the
past
couple
of
years
we
have
a
working
group
adopted
framework
document
for
what
we
refer
to
as
ietf
network
slices.
P
We
also
have
a
working
group
adopted
young
model
draft
that
discusses
how
an
itf
slice
service
can
be
requested.
We
also
have
various
solution,
specific
documents
that
are
being
thoroughly
debated
and
discussed.
So
we
do
understand
that
there
are
a
fair
number
of
network
slicing
related
documents
that
are
being
presented
and
being
pursued
in
other
working
groups
in
the
routing
area.
J
P
Group
adopter
document
that
talks
about
interworking
of
distributed
gm
plus
control
and
centralized
controller
systems.
So
that's
what
we're
currently
working
on
our
working
your
sessions
are
stated
for
today
we
have
two
back-to-back
sessions.
Do
come
join
us.
If
any
of
these
topics
interest
you
any
questions.
L
Q
M
To
remind
you,
we
were
chartered
to
work
on
some
work
that
doesn't
have
other
hum
in
atf,
such
as
young
models
for
driving
protocols
that
don't
have
working
groups
already
or
not
yet,
as
well
as
say,
most
importantly,
bringing
new
work
that
could
potentially
be
dispatched
into
other
areas
and
other
working
groups.
So
there
are
two
different
streams.
One
of
them
is
to
work
on
traditional
documents
such
as
faster
route.
M
M
Please
I'm
going
to
work
bgp
peak.
There
are
at
least
four
implementations,
I'm
aware
of
done
around
2015,
so
it
has
huge
educational
value
for
people
who
are
coming
networking
right
now
and
trying
to
learn.
How
do
we
do
faster
out
with
bgp?
You
know
in
some
natural
there
are
50
100
150
million
prefixes
today.
How
do
you
converge
fast
below
second
right?
So
this
is
an
explanation
of
particular
instrumentation,
but
again
educationally
a
lot
of
people
reading
it
and
for
them
it's
really
the
document
to
understand
bgp
faster
out
it's
progressing.
M
I
think
we
are
text-wise
getting
close
to
working
group
plus
call
to
finalize
this
work.
It's
been
around
for
a
long
time,
taylor,
fay,
being
reviewed
and
thank
you,
stuart
bryant,
for
his
very
valuable
reviews.
So
he's
a
shepherding
he's
shepherding
this
work
and
the
number
of
commands
he
wants
other
to
address.
But
the
progress
is
there
atm
bgp
work
that
describe
bgp
framework
for
mobile
space
and
aeronautical.
M
It's
a
reasonably
complex
and
long
document.
We're
really
happy
to
see
that
there's
interest
to
review
it
to
help
authors
to
improve
it.
So
work
is
ongoing
and
we
expect
to
start
working
group
last
call
sometime
after
this
atf
next
slide.
Please
we
recently
adopted
vfd
for
vrp,
so
we
could
use
bfd
to
provide
subsequent
convergence
for
brp.
M
You
know
vrp
usually
runs
slower
than
one
second,
so
the
combination
is
very
valuable,
especially
as
evpn
is
becoming
de
facto
standard
and
in
cases
where
it's
pure
layer,
2
vrp,
is
the
technology
to
provide
for
slayer
to
help
service
extinguishers.
Protection
is
in
our
traditional
chapter.
We
are
working
on
faster
out
for
different
parts
of
network.
In
this
case
service
net
to
cloud
work
is
told.
I
don't
think
we
are
going
to
progress
it.
M
M
In
young
area
we've
published
rfc
1967,
which
is
young
model
for
routing
policies
which
is
used
by
all
other
routing
protocols,
extended
cheap
young
models,
ready
for
working
with
lost,
call,
there's
no
changes
really
and
the
qos
model.
It's
really
good
work
here,
the
addressing
reviews,
the
operational
consideration.
M
M
M
Hpcc
is
new
work
and
I'm
going
to
discuss
couple
of
items
now
that
I
see
coming
and
are
important.
It's
not
very
visible
yet,
but
amount
of
traffic
that
have
very
different
characteristics
than
what
we
see
on
internet
is
coming
amount
of
rdma
trafficking.
Data
center
is
going
over
the
roof
machine.
Learning
clusters
are
getting
to
50
to
100
megawatt
size.
They
require
different
type
of
feedback
from
end
system
into
routing
system.
So
hpcc
is
an
approach
to
provide
clean
api
between
host
and
network
and
venture
influence,
routing.
M
Another
type
of
new
work-
that's
coming
is
semantic
routing.
Really.
What
we
are
trying
to
do
here
is
going
further
than
just
destination
based
lookup
routing
system.
What
other
fields
can
we
use
to
provide
better
routing?
What's
new?
M
So
it's
kind
of
more
research
area
right
now,
there's
some
more
going
in
irt
there's
number
of
drafts
in
routing,
but
we
are
in
very
early
stages,
still
unclear
where
this
work
is
going
to
happen
actually
back
to
hpcc.
We
are
in
discussion
with
transport
area
because
on
one
side
it
kind
of
influenced
routing
on
another
side,
it's
congestion
control,
really
what
you
want
to
do
is
and
host
to
get
enough
data
to
either
send
less
traffic
or
perhaps
change
entropy,
so
routing
system
have
more
metadata
to
larger
traffic
better.
M
So
again,
it's
all
being
discussed
right
now
with
transport
area
ideas
and
transport
working
group
chairs
last
area
is
routing
in
satellites.
We
see
really
large
deployments
of
satellites.
Networking
with
pixel
starlink,
all
the
stuff
is
being
deployed
at
huge
scale.
They
all
run
proprietary
protocols
today
they
don't
interwork
with
each
other.
There
is
definitely
need
for
a
routing
protocol
that
can
address
the
requirements
of
satellite
system,
which
is
quite
different
than
wire
system
due
to
changes
due
to
sometimes
proximity
and
not
in
transition
links
are
going
up
and
down.
M
So
this
is
kind
of
early
work
we
started
here,
but
eventually
I
believe,
there's
really
need
for
interoperability
between
different
systems
to
provide
what
atf
does
best
really
solutions
that
allows
different
systems
to
work
with
each
other.
So
those
are
kind
of
three
areas.
I
see
more
and
more
discussions
and
we'll
continue
working
on
them.
M
Very
good
question
I
mean
we
couldn't
test
spf
before
we
put
together
specs
right,
so
we
need
to
start
somewhere.
We
need
to
understand
the
characteristic
of
satellite
networking.
We
need
to
understand
how
to
solve
them,
and
it's
not
really
a
new
problem
right.
We've
done
quite
some
work
in
monet
on
wireless
systems.
So
there's
a
lot
of
experience
here
by
better
understanding
the
problem
space
and
what
needs
to
be
done.
Eventually,
we
could
propose
solutions
that
at
least
partially
have
been
validated
by
atf
and
their
working
code.
M
N
I
was,
I
was
trying
to
get
my
phone
to
load
to
get
in
the
queue
real,
quick.
I
I
suspect,
tony's
question
is
actually
more
of.
Is
the
intention
of
the
satellite
thing
supposed
to
eventually
get
to
a
standards
track
where
there
would
be
multiple
implementations?
And
I
think
that
that's
where
his
original
question
came
from
is
like
how
do
you
test
interoperability?
It's
not
like
I'm
going
to
go
and
as
akamai
going
to
launch
a
satellite
for
example,
and
then
implement
my
own
routing
protocol.
M
M
D
R
M
B
B
So
you
have
seen
only
about
a
third
of
the
working
groups
here
and
there's
a
lot
of
exciting
work,
there's
a
lot
of
current
work
that
needs
participation
and
review
and
and
and
the
input
from
from
all
of
you.
So
please.
The
objective
of
these
short
presentations
is
for
you
to
see
what
is
going
on
in
other
places.
B
Now
we
have
a
something
different.
This
is
not
something
that
is
being
worked
in
the
itf
right
now,
but
since
the
routing
area,
open
meeting
is
an
open
meeting
and
it's
not
a
working
group,
we
invited
adrian
perrig
from
eth
and
apply
systems
to
talk
about
zion,
which
is
something
they've
been
working
on
for
a
while.
They
have
deployments,
and
so
he's
going
to
provide
an
overview
of
that
go
ahead.
S
S
S
S
We
also
very
early
start
with
formal
verification
and
I'll
come
back
to
this
in
a
minute
and
also
looked
at
scalability.
How
can
we
design
a
system
that
can
have
very
rapid
convergence
to
enable
global
communication
next
slide?
So
we're
certainly
not
the
first
team
who
worked
on
this
and
they're
roughly.
S
S
Next
line,
and
so
architectural
principles
we
followed
were
to
achieve
stateless
packet
forwarding
so
to
avoid
inconsistent
forwarding
state
on
different
routers,
so
also
the
routing
system
itself
has
in
a
way
no
no
convergence
phase.
So
there's
it's
always
converged
so
to
speak,
and
that
provides
a
lot
of
advantages.
S
So
the
first
insight
that
we
had
on
this
journey
is-
and
maybe
it's
obvious,
but
still
I
think
it's
useful
to
to
say
this.
If
you
really
need
high
assurance
for
a
large
scale
distributed
system,
you
really
have
to
have
a
formal
verification,
and
so
we've
done
this
in
scion
and
worked
with
research
groups
of
david
basin
and
peter
miller
at
eth,
and
we
found
a
lot
of
bugs
in
the
process
and
we're
able
to
very
early
change
the
design
thanks
to
such
a
formal
verification
next
slide.
S
So
the
first
aspect
of
scion
that
I'd
like
to
present
is
that
we
we
started
with
was
to
achieve
a
sovereignty
of
networks.
So
we
said,
if
the
the
roots
of
trust,
the
cryptographic
keys,
that
define
the
trust
routes,
they
need
to
be
local.
It's
it's
very
difficult
to
create
networks
that
have
a
few
of
these
routes
of
trust
that
are
distributed
in
in
some
way,
and
so
we
created
a
structure
with
isolation,
domains
that
would
locally
define
the
roots
of
trust
and
then
globally,
connect
and
cross-certify
each
other
in
a
way.
S
So
that
was
the
initial
idea,
but
then
actually
turns
out.
This
also
helped
with
scalability,
because
the
routing
system
then
finds
path
segments
across
these
isolation,
domains
and
also
within
each
isolation
domain.
So
that's
the
high
level
motivation
here
and
the
next
slide,
and
so
here's
overview
in
one
slide
I'll
go
a
little
bit
into
more
details
in
the
following
slides
but
in
essence
in
the
control
plane
path
segments
are
being
found
through
a
process
called
beaconing
between
the
what
we
call
coriosis.
These
are
the
main
isps
that
manage
these
isolation
domains.
S
They
have
a
process
that
looks
similar
to
how
bgp
operates
to
find
these
path
segments
and
then,
within
each
isolation
domain.
The
beacons
are
only
sent
by
these
corios's,
so
leafy
asses,
they
don't
themselves
initiate
beacons
and
all
the
other
s's
except
the
core
is
simply
forward
this
beacon.
So
it's
also
highly
scalable
mechanism,
and
so
these
path
segments
are
found
in
this
beaconing
process.
S
They
are
then
redistributed
through
a
path,
server
infrastructure
that
is
a
pull-based
and
not
not
push-based.
So
it's
very
lightweight
and
highly
scalable
way
to
disseminate
these
path
segments.
So
you
can
think
similar
to
how
dns
works,
and
so
when
two
entities
want
to
communicate.
So
in
this
example,
here
we
have
a
host
in
asf
who
wants
to
communicate
with
the
host
in
ass,
and
so
it
looks
up
these
path
segments.
In
this
example,
it
gets
the
six
path
segments
that
can
be
combined
in
only
two
ways.
S
In
this
example,
then
it
encapsulates
this
forwarding
information
at
the
as
level
in
the
path
in
the
packet
header,
and
so
it
can
select
for
every
packet
which
pathway
wants
to
take
the
path.
Information
is
also
based,
not
just
as
level
but
based
on
the
interfaces
between
or
the
connections
or
the
links
between
the
ass.
S
So
you
have
diversity
if
the
same
set
of
asses
connects
in
many
different
places,
so
you
can
make
use
of
all
these
different
path
options.
So
in
the
in
the
data
plane,
then
we
have
these
packets.
With
this
information,
there's
also
cryptographic
protections
built
in
that
prevent
changes
and
then,
in
the
end,
routers
become
very
simple.
They
for
the
forward
the
packets
based
on
this
information
and
so
in
a
way
there's
no
per
path
state.
On
routers
routers
essentially
have
a
cryptographic,
actually
only
one
single
cryptographic
key
to
verify
this
information
and
it's
symmetric.
S
So
it's
extremely
fast.
It
can
be
checked
in
within
nanoseconds
right
next
line.
So
in
the
control
plane,
we've
seen
how
these
path
segments
are
being
created.
Then,
in
the
data
plane,
information
is
being
extracted
from
this
control,
plane,
information
and
there's
also
cryptographic
protections
built
in
so
the
control
plane.
We
use
digital
signatures
to
authenticate
this
routing
information
or
this
path
information,
but
then,
in
the
data
plane
there
is
highly
efficient
asymmetric
key
cryptography
used
to
then
ensure
that
paths
cannot
be
forged
or
changed
in
any
way.
S
That
is
not
permitted
by
the
architecture,
and
so
here
we
just
see
how
fields
are
being
extracted
from
the
control
plane
and
put
into
the
data
plane.
So
the
overhead
is
12,
bytes
per
aes,
that's
being
traversed
12
bytes
is
not
little,
but
it's
we
believe.
Given
all
the
advantages,
that's
that's
a
good
trade-off
right
so
for
the
actual
forwarding
two
aes
operations
are
needed,
and
even
in
soft
in
software
on
commodity
intel
or
arm
or
other
chips
amd,
it
takes
only
about
30
cycles,
processor
cycles
to
compute
an
as
operation.
S
So
next
line,
so
just
a
few
details
to
give
you
a
bit
more
intuition
how
this
works.
So
this
beaconing
process,
we
have
these
coreys's,
so
the
main
isps
that
govern
an
isolation
domain
they
initiate
these
beacons,
then
other
aes
is
simply
forward
them
across
their
interfaces
based
on
the
also
routing
policy
and
actually
the
policies.
S
We
try
to
be
very
close
to
the
economic
principles
of
today's
internet,
those
with
peering
links
and
so
on,
where
society
actually
closely
mirrors
what
happens
in
today's
internet.
So
we
definitely
want
to
adhere
to
those
principles,
and
so
these
path,
construction
beacons.
They
create
path
segments
that
can
then
be
immediately
used
for
communication
next
slide.
S
Next
line
yeah
great,
so
then
there
is
a
path
server,
also
in
each
autonomous
system
that
stores
this
path,
information
so
an
as
can
select,
which
paths
it
makes
available.
It
can
locally
tell
its
hosts,
which
paths
they
can
use
to.
We
call
go
upstream
towards
the
core
or
and
in
the
next
slide
also
there
is
a
passer
in
the
core
where
an
as
can
register
how
others
can
reach
it.
So
that's
on
the
next
slide.
S
Please,
and
so
here
one
can
do
in
a
way
ingress
path,
control
by
selecting
which
paths
are
being
communicated
to
other
entities
for
reaching
its
as
and
so
one
can
register
only
the
paths
that
are
compliant
with
one's
policy,
and
so
then,
these
paths,
anyone
on
the
internet
can
then
fetch
to
communicate.
In
this
example,
with
this
ass
here
next
slide
and
so
for
communication,
then
these
path
segments
are
being
combined
in
various
ways.
You
can
do
also
shortcuts.
S
And
then
these
yellow
paths
are
the
different
paths
that
can
be
selected
from,
and
we
see
also
one
example
of
appearing
link
where
one
can
go
and
use
the
peerlink
from
o
to
p,
even
though
there's
no
direct
links
so
to
speak,
that
is,
were
no
beacon
when
the
cross,
but
because
both
o
and
p
announced
the
peering
link
with
the
right
cryptographic.
Information.
S
So
here
also
on
the
global
scale.
These
paths
are
combined
and
again
we
see
several
opportunities
now.
Maybe
in
this
slide
it's
not
that
interesting,
but
in
general,
when
we
model
the
internet
graph,
of
course,
there's
huge
amount
of
path
disjointness
across
the
top
isps,
and
so
we
anticipate
that
a
really
very
large
number
of
paths,
assuming
isps
policies,
do
permit
communication
and
a
lot
of
different
path.
Choices
become
become
feasible,
next
line.
S
Of
course,
there's
also
bandwidth
overhead
and
for
this
additional
information,
although
we
believe
that
these
12
bytes
per
aes
is
is
manageable
operationally.
There
is
more
effort
in
a
sense
that
it's
a
security
architecture,
so
each
ais
needs
to
have
a
certificate
that
requires
additional
management.
Overhead
and
also
the
initial
setup
cost
training,
people
and
so
on,
is
actually
the
the
biggest
cost
in
in
scion,
because
people
need
to
learn
how
this
works
and
for
isps,
though
it's
turns
out
it
all.
S
So
for
an
isp,
the
deployment
is
actually
quite
simple.
People
have
referred
to
as
a
homeopathic
upgrade
to
a
nice
view,
so
it's
not
that
much
that
much
effort.
In
essence,
the
isp
set
up
a
few
border,
routers
and
path
server
certificate
servers
on
the
beacon
servers
which
are
just
hosts
within
the
network,
and
so
there's
been
a
lot
of
surprise
how
little
work
it
actually
is
to
become
a
cyanispy,
of
course.
Integrating
this
with
internal
processes
can
be
quite
complicated,
but
to
get
started.
S
It's
actually
less
effort
than
one
things:
okay
and
there's
no
changes
to
internal
infrastructure
of
the
isp,
that's
also
important
to
say
so.
Sign
can
reuse
the
internal
switching
fabric,
be
the
mpls
or
an
ip
switched
backbone
or
whatever,
and
sound
traffic
can
reuse
the
internal
fabric.
Thank
you
next
slide.
S
Also
for
and
and
customers,
the
deployment
has
been
actually
quite
straightforward
because
of
a
sign
ip
gateway
that
translates
between
ip
and
sign
traffic.
So
the
end
applications
and
hosts
don't
need
to
even
know
about
this
new
infrastructure,
and
so
several
customers
use
this
in
production
actually
already
for
several
years
and
benefit
from
the
opportunities
of
cyan
without
having
to
change
any
of
the
applications.
S
Of
course,
there's
also
end
host
stacks
that
can
then
make
use
of
cyan
natively,
but
initially
it's
of
course
much
simpler
to
to
transparently
translate
between
ip
enzyme
next
line.
So
the
current
deployments
are
left
by
on
a
fire
systems.
The
the
global
scion
network
was
constructed
in
a
way
that
it's
not
an
overlay,
that
it's
really
as
independent
failure
models
from
bgp,
so
there's
no
dependence
of
the
today's
assigned
backbone
on
bgp.
S
So
that's
already
quite
nice
to
have
these
two
independent
systems,
even
though
they
run
over
some
of
the
same
networks.
Internally,
there's
also
three
different
implementations:
there's
an
open,
open
source
implementation
in
go
on
apaya
has
their
own
proprietary,
high
performance,
implementation
and
synthlabs
built
the
sign
router
mp4
that
achieved
over
a
terabit
of
throughput,
and
these
are
the
current
implementations.
S
The
deployment
there's
six
isps
that
offer
a
native
sign
connectivity,
the
first
three
in
switzerland
and
the
others.
Actually
cyberlink
is
also
in
switzerland,
but
of
course,
additional
ones
exist
and
are
already
trying
out.
So
one
can
get
signed
connectivity,
for
instance,
in
any
household
in
south
korea,
and
it's
also
spreading
in
the
sense
that
more
and
more
isps
are
interested
in
their
joining
this
network.
S
S
So
for
standardization,
there's
of
course,
work
to
be
done
and
also
that's.
Why
we're
here
and
I
believe
we
satisfy
a
lot
of
the
success
factors
needed
for
standardization
in
rfc,
5218
and
we've
also
had
a
site
meeting
yesterday
to
discuss
how
we
could
go
about
this
standardization.
We're
very
much
looking
forward
to
also
feedback
from
this
group
to
getting
your
advice,
how
we
could
proceed
next
line.
S
Lots
of
resources
exist
code
and
on
san
architecture
papers.
A
book
there's
also
a
new
book
coming
out
we're
just
waiting
for
the
printer
to
to
hit
the
print
button.
So
hopefully
the
new
book
from
springer
for
lock
will
be
coming
out
within
a
few
weeks
next
line.
S
So
one
observation
I
briefly
wanted
to
talk
about
was
that
stable
paths
and
multipath
is
necessary
and
not
just
a
luxury
so
with
single
path.
Forwarding
it's
difficult
to
achieve
strong
availability
guarantees,
for
instance
during
route
convergence,
and
we've
also
seen
one
has
to
do
work
to
prevent
routing
loops.
S
That's
that's
already
operational,
so
I'll
give
in
the
next
slide
two
next
two
slides
two
examples
for
why
this
is
necessary,
so
the
first
one
is
about
bottleneck
routing,
so
we've
seen
several
real
world
events
that
had
were
quite
noticeable
at
the
global
scale
of
outages.
Were
the
the
protocol
changed
to
a
path
that
had
insufficient
bandwidth
then
resulted
in
high
packet
loss,
so
the
path
was
operational,
but
had
such
high
packet
loss.
S
That
applications
were
not
usable
and
it
took
quite
some
time
to
recover
because
the
routing
system
thought
well,
the
the
path
is
working,
but
in
fact
for
applications
it
was
not
practically
usable,
and
so
this.
This
is
one
example
where
even
a
secure
protocol
would
not
have
operated,
because
in
both
of
these
cases,
the
path
that
was
switched
to
that
had
insufficient
bandwidth
was
a
correct
path,
so
security
by
itself
would
not
have
addressed
this
issue
on
the
next
slide.
S
S
It's
also
high
performance
because
pathware
networks
allow
you
to
perform
application
specific
optimizations,
and
that
is
not
just
for
security,
but
also
has
the
opportunity
to
give
higher
performance
to
end
applications
and
also,
of
course,
the
whole
system
was
designed
for
high
security,
high
assurance
availability
to
also
even
with
secure
control
messages
and
so
on.
So
really
security.
Up
to
the
last
point-
and
this
has
been
a
12
year-
long
journey
for
us
starting
actually
in
2009
and
the
team
is
at
eth
and
several
collaborators
is
shown
on
the
next
slide.
B
Yeah,
thank
you
adrian.
We
have
some
time
for
questions
or
comments,
please
in
the
queue.
If
you
have
any
question
or
comment
for
already
during
about
this.
G
I
just
said
so:
yeah
audio
sucks,
the
I
didn't
see
from
this
well.
Thank
you
very
much
for
the
presentation.
That
was
very
nice,
although
I
knew
it,
but
anyhow,
I
didn't
quite
see
you
know
some
background
information
about.
You
know
who
would
be
the
operators
of
the
current.
You
know,
deployment
that
you
have
in
terms
of
you
mentioned
180
data
centers.
Could
you
kind
of
elaborate
a
little
bit
about
that
current
operational?
G
You
know,
motivations
or
so
who
those
folks
are
that
are
running
the
virtual
machines,
I
guess,
or
and
and
what
their
experience
is
right.
S
Yeah
very
good,
thank
you.
So
in
in
switzerland,
we
have
swisscom
sunrise
switch
and
as
the
main
operators
and
now
cyberlink
has
a
new
isp,
joining
them
and
globally.
Inner
cloud
has
this
network.
Where
they're
offering
cloud
connectivity
there
are
over
180
data
centers,
where
they
then
provide
also
connectivity
inside
cloud
deployments,
and
so
their
their
offering
is
to
provide
native
science
connectivity.
Also
in
inside
inside
cloud
deployments.
S
Also
talindus
in
luxembourg
is,
is
one
of
the
isps
and
but
they're
more
more
coming,
some
of
them
not
in
not
with
official
products
but
doing
more
more
poc
like
offerings,
but
the
the
network
is
growing
and
they're
more
and
more
isp
is
not
joining
this.
This
network,
we're
simply
looking
out
to
make
sure
that
it
is
running
independently
from
other
systems.
So
if
other
systems
fail
sign
would
not
be
affected
and,
of
course,
vice
versa,
as
well.
G
No
because
I
mean
you
you've
been
asking
about,
you
know
how
to
proceed
with
something
like
this
in
the
ietf
and
typically
the
best
driver
to
do
something
is
to
basically
show
the
need
to
define
the
interoperable
components
of
something
like
this.
If,
if
it's
in
routing,
then
then
the
routing
components,
of
course,
you
may
be
driven
around
different
areas
depending
on
you
know.
Oh
the
security
aspects.
G
We
have
no
idea,
we
tried
and
failed
go
to
security
area
and
so
on,
but
effectively
it
is
exactly
what
I
was
asking
for
in
terms
of
a
list
of
operators
that
want
to
have
this
that
feel
that
if
the
ietf
provides
standardized
rfcs
that
it
helps
them
to
achieve
for
what
they've
already
been
doing
in
their
private,
idaho,
so
to
speak
so
far,
a
better
yeah,
reliable,
standardized
interval
experience
right.
So
I
think
that's
that's
going
to
in
our
role.
Can
probably
tell
you
a
lot
more
about
that.
I
think
that's!
E
Hi,
I'm
simon
leinan,
responding
to
turner's
question
directly,
so
we
are
I'm
with
switch
we're
one
of
those
operators
who
have
been
running
scion
services
and
we're
offering
this
on
a
commercial
basis
for
a
deployment
in
the
financial
industry,
mostly
well
our
industry.
Oh
our
interest
is
that
this
becomes
something
sustainable
and
independent
of
from
like
a
research
group
or
startup.
E
So
of
course
we
we
will
be
happy
for
this
to
be
standardized
in
a
sort
of
a
neutral
forum.
That's
one
one
aspect
also:
probably
the
the
quality
of
the
implementation
would
also
benefit
from
review
in
a
form
such
as
the
itf,
yes
as
to
how
to
bring
this
work
from
the
the
academic
research
sector,
but
also
from
operators
who
not
who
are
not
necessarily
using
interacting
with
the
idf,
is
a
different
question
and
I
guess
that's
sort
of
for
the
ietf
bureaucracy
to
to
facilitate
yeah.
E
But
if
you
have
questions
about
how
this
feels
to
an
operator,
I'm
happy
to
talk
to
people
thanks.
M
Jeff
and
sir,
first
of
all,
I'm
happy
to
see
here,
we've
been
discussing
a
couple
of
years
of
our
linkedin
messaging
right.
It
was
a
good
idea
to
come
here.
The
next
step
would
be
to
really
decouple
problem
spaces.
It's
not
just
routing.
It's
name
resolution,
it's
addressing
the
more
more
things
that
this
that
are
not
standardized
by
etfs
today
right.
So
when
someone
sees
this
for
the
first
time,
it
looks
like
ball
in
the
ocean
because
you're
replacing
dns
you
you're
talking
about
stuff
that
really
incomprehensible
to
some
degree.
M
So
you
came
here
to
meet
us
as
well
right.
It
goes
both
ways,
so
you
figured
out
already
that
there's
area
that
works
on
dns
areas
that
work
on
ip
address
and
carrier
that
works
and
routing
this,
where
you
are
now
try
to
break
your
problem
statement
into
smaller
comprehendable
pieces
that
could
be
addressed
by
particular
areas
and
people
who
know
what
this
is
about.
That
would
be
really
good
next
step
for
you.
N
Jared
mont,
so
I
think
similar
to
the
side
meeting
that
we
had
yesterday,
it
would
help
also
to
understand,
is
the
intention
to
bring
the
scion
work
forward,
or
is
it
to
go
and
bring
the
the
technological
capabilities
that
was
developed
as
part
of
scion
into
the
other
protocols
that
are
already
existing
within
the
ietf
and
determining
sort
of
which
pathway?
N
You
know,
you're
looking
to
go
that
that
would,
I
think,
help
a
lot
of
us
because,
similar
to
what
jeff
said
it
does
feel
a
lot
like
boiling
the
ocean,
and
so,
if
we're
trying
to
say
okay,
we
need
to
go
and
secure
these
protocols.
We
need
to
secure
them.
You
know,
as
I
brought
up
yesterday,
you
know
you
know
start
down
at
the
lynx
state
where
we
traditionally
build
a
lot
of
the
networks.
N
You
know
from
there
on
up
and
figure
out,
okay,
what
infrastructure
needs
to
be
changed
or
modified
or
improved
in
order
to
have
the
properties
that
make
this
valuable
for
the
financial
institutions
and
others
that
are
using
it
and
have
a
much
clearer.
You
know
kind
of
a
clear
goal
set
out
of
there.
S
So
the
intent
is
definitely
to
bring
the
the
whole
protocol
to
standardize
and
with
all
the
consequences.
But
of
course
I
was
having
cross
fertilization
with
other
efforts
to
see
how
can
they
benefit
from
sign
and
how
can
sign
benefit
from
them.
I
think
there's
also
a
lot
of
possible
interactions
with
segment
routing,
for
instance,
and
other
working
groups
as
well.
S
So
I
think
there
was
one
more
point,
but
it
just
escaped
me,
but
that
definitely
I
see,
there's
a
lot
of
potential
possible
interactions
with
different
groups
and
different
efforts
and
including
improving
scion
itself
and
making
it
make
it
better
over
time.
Q
In
fact,
this
this
example
of
a
world
protocol
shoot
addressing
a
set
of
use.
Cases
that
are
very
interesting
to
customers
for
specific
isps
relates
to
for
me
to
the
question
of
deployments
of
experiments
or
lower
market
use
cases
in
in
networks
that
are
produ
used
in
production,
and
it
relates
to
a
work
that
has
been
presented
in
irtf.
I
think
one
or
two
meetings
ago
about
tcpls
and
the
members
of
the
tcpls
team
have
proposed
a
mechanism
called
protocol
plugins
in
order
to
deploy
innovation
in
actual
production
networks
in
the
form
of
small
vms.
Q
So
maybe
one
work
that
could
be
interested
to
interesting
to
do
in
iitf
would
be
to
have
a
method
for
researchers
and
people
willing
to
deploy
new
use,
use
cases
and
new
protocols
to
interact
with
vendors
and
operators
to
deploy
those
those
new
things
and
find
ways
to
manage
their
experiments
in
isolation.
For
the
time
they
are
not
successful
enough
for
wide
adoption,
but
yet
not
arming
the
running
of
the
operational
networks,
and
I
think
it
would
be
a
very
valuable
work
to
do
in
ietf
to
address
the
problem
of
the
ossification
of
the
internet.
M
M
M
The
visibility
of
insecurity
of
routing
system
got
bumped
up
to
the
highest
level,
so
I
think
we
are
going
to
see
more
funding
and
more
industry
interest
because
finally,
there
is
a
driver
to
go
to
the
next
step
right.
I
think
they
are
very
surprised
that
bgp
sec
is
not
only
not
deployed.
There
are
no
commercial
implementations,
at
least
not
shipping
implementations.
M
So
there's
going
to
be
a
huge
push
to
do
something
on
top
of
origin
validation
and
it's
going
to
be
either
bgp
set
something
better
something
probably
more
deployable
than
this,
but
a
solution
needs
to
come.
I
mean.
Finally,
there
is
interest
of
government.
There's
money,
there's
industry
pushing
for
it
so
great
good
time.
B
B
Well,
I
guess,
unless
john
andrew
martin,
you
have
anything
you
want
to
say,
I
think.
B
We
are
done
for
today,
hopefully
we'll
see
each
other
again
and
more
of
us
in
person
and
not
wearing
our
masks.
So
often,
thank
you,
everyone
for
being
here,
both
here
and
online
and
again
we'll
see
you
next
time.
Bye.