►
From YouTube: IETF100-TUTORIAL-ROUTINGAREA-20171112-1345
Description
ROUTINGAREA TUTORIAL at IETF100
2017/11/12 1345
https://datatracker.ietf.org/meeting/100/proceedings/
A
Okay,
thank
you
very
much.
Okay,
I'm
Joel
Halpern.
This
is
sue
hares
over
here,
Martin
vicaroo,
who
helped
us
prepare
this
material
from
earlier
material.
The
credit
for
the
earlier
materials
at
the
end
is
not
here
right
now.
He
wanted
to
help
also,
but
he's
in
transit.
We're
gonna
try
to
give
you
in
one
hour
an
overview
of
the
routing
area.
That
means
we're
gonna
go
very
quickly
through
a
lot
of
material.
The
slides
themselves
are
posted.
So
when
you
have
more
time,
you
can
look
back
over
it.
Next.
A
Just
this
area,
so
you'll
see
next
slide.
We're
not
going
to
tell
you
how
to
do
network
routing,
that's
a
whole
science.
We
could
spend
a
whole
day
on.
How
do
you
do
routing
in
all
the
variations
that
can't
choose
not
to
you
love
to
have
that
discussion,
but
that's
not
what
this
is
for
and
we're
not
going
to
talk
about
how
you
design
routing
protocols.
There
are
many
theories
on
that.
It's
an
interesting
discipline.
A
That's
new
work
builds
on
existing
work,
so
the
old
leads
to
the
new,
as
in
most
disciplines,
so
routing
has
been
recognized
as
a
core
division
since,
as
in
1989,
when
there
were
only
six
areas,
but
one
of
them
was
routing
I
served
as
routing
area
director
from
1994
to
1998.
So
we've
been
doing
routing
here
for
a
long
time,
because
that's
what
holds
the
network
together
got
all
these
endpoints
and
you
got
to
get
the
packets
between
them.
A
Everything
that
goes
on
in
the
middle,
that's
routing,
so
there
are
currently
seven
areas
in
the
IETF.
The
number
has
varied
over
the
years.
For
example,
what's
now
art
used
to
be
two
different
areas?
At
one
time,
ops
was
two
areas,
one
for
network
management
and
one
for
operations.
We
merge
them.
We
split
them.
Routing
has
been
a
stable
area
of
the
whole
time.
A
There
are
15
area
directors,
one
of
the
interesting
changes
a
couple
of
years
ago,
so
we
had
a
third
area
director
to
try
to
keep
the
work
manageable
because,
as
you
can
see,
we
have
a
lot
of
27
working
groups.
It's
a
lot
of
work.
So
that's
that's.
Why
there's
so
much
the
ATF
has
130.
The
number
has
varied,
but
it's
pretty
stable,
120
and
130
working
groups
in
the
IETF
across
all
the
areas.
It's
a
lot
of
work.
The
routing
area
has
also
been
pretty
stable.
A
A
Having
said
that,
I
will
admit
that
routing
is
one
of
the
areas
that
tends
to
have
some
very
long-lived
working
groups,
because
we
have
to
maintain
the
routing
protocols
and
since
the
problems
keep
shifting
is
always
maintenance
work
and
we'll
get
back
to
that
in
a
little
while
now
back
up
one
more,
that
was
one
more
so
this
last
year
we
published
250
RFC's.
We
we
publish
a
lot
of
documents
and
roughly
30%
of
those
were
in
of
30%
of
the
working
group.
A
Ones
were
from
the
routing
area,
so
a
lot
of
drafts
we've
got
a
lot
of
work
going
on.
There
also
32
things
that
were
not
working
groups
so
that
we
do
as
an
IETF
published
things
that
are
not
from
the
works.
That's
important.
It
helps
us
progress,
things
that
don't
quite
fit
eat.
Anything
as
I
alluded
to
earlier.
The
point
is
that
hosts
are
not
directly
connected.
It's
yeah.
A
If
you
had
to
build
the
network
by
intricate
directly
interconnect
you
all
the
hosts,
it
would
be
a
nightmare
routing
is
what
enables
traffic
to
get
from
a
sending
host
to
a
receiving
host.
Whether
that
host
is
a
phone,
a
tablet,
a
server
in
the
computer
room
routing,
is
how
you
get
the
packets
between
that's
what
it's
about.
So
your
outers
receiver
packet.
They
look
at
it,
they
look
at
the
destination
IP
address
they
decide.
Where
does
it
need
to
go
and
they
send
it
on
its
way?
A
Now
there
are
lots
of
refinements
of
that
lots
of
variations,
but
that's
the
basic
problem
and
generally
routes
are
known
in
a
distributed
fashion.
There
are
some
ways
that
we
can
program
routes
across
portions
of
the
network,
but
if
you
think
about
the
network
as
a
whole,
it
is
a
distributed
environment
and
routing
is
fundamentally
a
distributed.
A
Computation
everybody
advertises
a
little
bit
and,
based
on
what
you
see,
you
can
figure
out
what
the
best
way
to
get
things
to
the
destination
now
best
can
be
complicated
because,
as
an
operator
for
example,
you
may
have
business
constraints.
Certain
paths
cost
more.
Certain
paths
cost
less.
Certain
paths
can
deliver
things
that
you
promised
certain
can't
so
best
is
not
a
simple
parameter,
but
the
basic
idea.
A
Is
you
get
the
information
from
this
distributed
computation
and
you
do
your
piece
of
the
packet
forwarding
in
such
a
way
that
packets
get
to
the
destination
and
we
like
it
to
be
very
robust
so
that
even
while
things
are
changing
in
the
network,
because
the
network
is
not
stable,
it
doesn't.
I
saw
some
beautiful
research
work
about
10
years
ago
on
how
you
could
make
a
really
really
small
routing
table.
If
only
everything
would
stay
put,
all
the
links
would
stay
up
and
effort,
nobody
would
move
and
no
technology
would
change.
A
We
could
then
calculate
these
really
neat
tables
yeah,
except
that's
not
how
the
world
works.
We
are
in
a
highly
dynamic
world,
and
so
that's
a
lot
of
what
routing
deals
with
is
the
dynamic
behavior,
so
the
routing
area
concerns
itself
or
the
protocols
and
mechanisms
to
route
these
packets
to
Pho.
We
talk
about
the
routing
control
and
the
necessary
forwarding.
State.
The
internet
area
deals
with
the
actual
packets
on
the
wire.
A
There
are
lots
of
things
that
are
similar
to
routing
but
aren't,
and
we
don't
claim
to
do
them.
We
will
provide
advice.
We
have
experience
with
this
distributed
computation
problem,
so
other
people
who
have
a
similar
problem
we
give
suggestions.
We
cooperate
with
folks
on
CD
ends
on
sip
distribution
on
multipath
TCP.
You
want
to
make
sure
that
things
work
with
the
way
this
routing
system
works,
but
we
don't
try
to
solve
everybody's
problem
for
them.
A
That's
one
of
the
rules,
and
one
of
the
things
that
the
IETF
tries
very
hard
to
do
is
to
leverage
our
range
of
expertise
while
working
on
things
in
different
areas.
Don't
try
to
do
everything
in
one
place,
because
there's
too
much
to
go
way
too
much
to
do
so.
We
can
do
informal
reviews,
we
can
give
advice,
but
we
don't
try
to
do
the
work
so
now
next,
but
the
other
side
of
this
is
there's
a
lot
of
overlap.
A
I
mean
we
have
is,
is
and
OSPF
we're,
finally
on
the
verge
of
merging
those,
but
they
were
actually
two
different
routing
protocols.
They
behave
differently
in
certain
ways,
but
they
have
to
do
very
similar
things,
but
we've
got
lots
of
other
routing
protocols,
which
also
overlap.
Babel
has
its
constraints,
but
it
needs
to
learn
from
other
things.
Idr
a
suit
can
talk
about
an
excruciating
detail
have
to
leverage
everything
else.
The
system
has
to
work
as
a
system,
which
means
routing
interacts
with
other
things,
and
transport
interacts
with
things.
Congestion
effects
are
very
important.
A
People
try
to
adjust
routing
for
congestion.
That
turns
out
to
be
very
tricky.
You
have
some
a
lot
of
experience
with
how
that
can
go
wrong
and
how
to
do
it
in
ways
that
are
better,
so
there's
lots
of
interactions
across
topics
which
means
scheduling.
All
of
this
is
really
hard.
There
are
25
or
27
working
groups,
many
of
which
ask
for
two
sessions,
some
of
which
settle
for
only
one,
but
we
only
have
so
many
slots.
So
sometimes
we
got
even
routing
groups
competing
with
routing
groups
for
time.
So
that
means
no.
B
Will
pick
it
up
from
here
so
maintenance,
our
old
working
groups
that
are
long
established
protocols?
We
have
to
keep
maintaining
him
for,
like
BGP
BGP,
still
all
considered
Mike.
Thank
you.
We
have
to
maintain
protocols
like
is
ice,
PGP
ambulance,
they
run
the
internet
so
and
there's
plenty
of
extensions
because,
as
you've
experienced
in
your
own
environment
for
your
own
customers,
the
IT
technology
really
turns
over
every
two
to
three
years,
whether
it's
for
your
home,
your
mobile
phone
and
then
we
have
some
new
work.
B
We
have
some
ideas
for
specialized
protocols
or
new
protocols
for
routing
applications
go
ahead.
So
let
me
go
through
the
division.
We
have
core
routing
protocols,
we
have
specialist
routing
protocols,
we
have
sub
IP,
we
have
routing
support
our
operations.
How
do
you
configure?
We
have
routing
services,
we
have
things,
we
call
experiments,
there
are
successful
experiments
for
the
most
part
and
we
have
close,
but
not
forgotten,
it's
important
to
get
done
with
the
set
of
work
and
close
it.
If
you
can
go
ahead,
so
let
me
go
through
the
core
routing
protocols.
B
These
are
fundamental.
These
protocols
are
usually
in
maintenance
mode.
Although
maintenance
mode
may
be
some
substantial
changes,
but
it
just
means
that
these
protocols,
like
BGP
eius,
eius
OSPF
ambulance,
are
widely
deployed.
New
work
is
treated
with
a
high
degree
of
caution.
We
don't
want
to
break
the
internet.
Okay,
go
ahead,
Oh,
SPF,
okay!
These
are
one
of
the
SPF
or
shortest
path.
Distance
protocols
and
the
work
of
maintenance
is
in
the
OSPF
group.
B
Eius
eius
is
the
old
iso
protocol
that
started
when
OSPF
ania
size
were
interchanging
in
the
work
in
1987.
Much
of
the
work
that
mirrors
what's
done
in
OSPF
others,
a
new
version
wasn't
needed
because
those
size
can
share
v4,
v6
and
other
things
in
there.
So
again,
the
extensions
look
the
same
and
we're
hoping
to
merge
the
two
groups.
Next,
one
IDR
is
one
of
the
groups.
I
co-chair
and
it's
probably
one
its
BGP
and
BGP
is
what
you
use
to
communicate
between.
B
Maybe
large
providers
like
AT&T
you'll,
find
that
it's
used
in
many
data
centers
like
Microsoft's
data
center
or
Facebook's
data
center,
and
it's
essentially
in
maintenance
mode.
We
take
our
input
from
the
grow,
which
is
an
Operations
Group.
That
says
these
are
the
things
we
need
in
our
BGP
operational
networks
and
best
inspring
have
protocol
editions.
Best
is
providing
LT,
VPNs,
l3,
VPNs
and
other
things
and
spring
is
providing
source
based
routing.
B
Jacking
the
working
group
developed
something
that
sat
on
top
of
a
public
key
infrastructure.
It
devised
a
way
to
sign
the
routes.
So
you
know
it
comes
from
just
your
network
to
another
network
and
it
has
a
way
to
distribute
keys.
So
this
is
we're
hoping
to
go
forward.
Cider
is
now
closed,
its
door
and
it's
gone
over
to
the
operations
area
where
operators
and
networks
will
say
hmmm
how
do
I
use
this?
Is
this
protocol
really
sufficient
as
it
is
go
ahead
for
multicast
is
another
one:
that's
gone
for
a
long
time.
B
It
started
with
PIM,
sparse
mode
and
that's
pretty
much
what's
been
deployed,
but
it
also
takes
up
IGMP
and
MPLS,
so
your
local
laptops
use
IGMP
and
ml
DP.
If
your
v6,
it
used
to
be
in
the
all
split,
but
it
also
is
now
working
very
closely
with
another
operating
operations.
Group
called
mbone
notice.
B
Itf
will
have
some
protocols
developed
and
then
hand
them
over
to
the
operations
group
where
operators
come
and
focus
on
am
I
getting
what
I'm
needing
either
operators
in
large
enterprises,
small
enterprises
or
provider
networks
like
AT&T,
Verizon,
NT,
now,
there's
also
a
maintenance
mode
for
PIM,
and
it's
trying
to
again
improve
the
security
in
the
scaling.
You're,
gonna
notice.
B
I
say
that
over
and
over
we
just
keep
trying
to
refactor
and
make
sure
the
stuff
grows,
with
the
demands
that
users
place
go
ahead
now
spring
was
a
new
working
group
that
tried
to
take
on
a
new
look
at
source
routing
you
notice
in
routing
we
say:
well,
that's
one
idea:
we've
had
for
a
long
time,
but
now
we're
going
to
take
a
new
twist.
Why
is
that?
Because
the
needs
of
the
network
change
you're
gonna,
hear
it
from
me
again
every
two
to
three
years,
and
so
sometimes
an
old
idea.
B
We
take
off
the
shelf
and
set
that'll
solve
that
problem
and
the
contrary.
Building
blocks
are
being
worked
on
for
MPLS,
ipv6
and
routing
protocols
are
added
to
try
to
make
this
source
routing
work
in
the
new
area
and
the
source
routing
is
trying
to
help
carve
pathways
through
lots
of
networks
or
car
pathways
inside
of
data
centers
go,
it
coordinates
with
MPLS
and
go
ahead
6-man
for
int.
Now,
let's
talk
about
the
specialist
routing
protocols.
B
These
are
routing
protocols
which
might
not
be
point
is
the
other
one
across
the
whole
internet,
but
they
might
be
deployed
in
your
home.
They
might
be
deployed
in
a
subset
of
networks,
and
these
environments
divide
very
special
routing
protocols.
The
devices
may
be
constrained.
You
may
have
constrained
in
sensors
networks.
It
has
a
cost
of
routing.
Dates
may
be
high,
so
we're
really
looking
at
how
do
we
actually
constrain
the
information
set?
So
these
specialized
problems
give
rise
to
these
targeted
working
groups
go
ahead.
B
So
if
bable
bable
is
for
your
home
network,
it's
a
place
where
you
can
have
wired
and
wireless
mesh
networks.
It's
an
augmented
and
rethought
distance
vector
protocol.
One
of
the
earliest
deployed
running
protocols
was
a
distance
vector
protocol
and
currently
it's
an
experimental
RFC's,
but
the
working
group,
the
ITF,
saw
enough
value
in
the
experiments
to
say
that
needs
to
be
standardized.
It
needs
to
be
ready
to
for
home
network
devices,
and
so
it's
upgrading
its
specification
and
it's
putting
management.
Now
you're
gonna
hear
a
couple
words
you
haven't
heard.
B
Probably
before
yang
Yang
is
just
a
data
modeling
language
that
we're
now
using
for
our
management,
because
our
idea
is
to
have
one
network
management
protocol
and
switch
in
a
whole
lot
of
data
models
sounds
like
things
that
are
being
used
in
computer
science.
All
the
time
and
babble
is
the
mandatory
protocol
for
HomeNet
and
that's
where
it
takes
a
lot
of
its
input
go
ahead.
Man
a
is
something
that
again
has
been
a
long
a
long
time.
B
It
started
with
people
who
had
military
networks
where
they
drove
around
in
in
jeeps
and
wanted
to
be
connected.
It
considers
battlefield
environments,
emergency
response
times.
You
heard
the
Hurricanes
people
who
come
in
and
they
drop
in
after
the
Hurricanes
or
the
the
floods
or
the
fires,
with
with
radios
on
the
back
and
create
individual
networks,
so
that
sometimes
the
Internet
of
developing
nations.
B
But,
as
you
saw
in
several
of
the
responses
to
problems
across
the
globe
now
the
outstanding
working
items
are
trying
to
make
sure
you
can
get
the
right
link
characteristics
because
you
can
picture
if
you're
being
dropped
into
a
hurricane.
You
need
to
know
if
you
think
the
link
is
good
or
if
another
link
is
better
because
you've
got
line
of
sight
and
there's
going
to
be
a
lot
of
additions
to
oil.
S.R.O
Lesar
is
another
variant
of
a
protocol
like
ISIL
SPF.
B
B
This
is
where
people
who
really
want
a
network
for
high
quality
video,
maybe
they're
gamers,
maybe
they're,
providing
medical
technology
gee,
and
they
want
to
have
layer,
2
and
layer
3,
and
they
want
paint
bounds
on
loss.
If
your
doctors
doing
one
of
those
robotics
things,
you
want
to
make
sure,
if
he's
having
surgery,
that
he
has
low
loss
of
data,
that
he
has
low
latency
and
everything
works.
B
Fine
and
these
networks
are
tuned
for
that
environment
and
the
data
plane
has
to
be
compatible
with
the
I
Triple
E
time
sensitive
networking,
which
is
again
looking
at
things
like
this
for
a
good,
video
or
medical,
and
it
will
use
MPLS
or
IP
as
the
data
flow.
The
use
cases
are
again
audio-video
electrical
automation
systems,
if
you're
in
a
factory
and
cellular
radios,
ok
next
one
sub,
IP
sub
IP
was
for
a
short
time
and
area
with
its
own
director.
B
That's
when
ambulances
first
being
deployed
when
we
had
new
layer
topologies
like
ATM
or
we
had
new
optical,
go
ahead.
So
MPLS
is
the
largest
and
well-known
how
many
people
know
about
it
have
heard
the
word
MPLS
before
ok,
so
we're,
at
least
in
that
one,
it's
the
largest.
It's
usually
across
the
world.
It's
been
used
for
large
providers,
so
some
packet-
you
have
transmits
it
at
least
to
get
here
it
does.
It
has
several
protocols,
it
has
LDP
rsvp-te
extensions
for
our
SPF
and
MPLS
TP
and
om,
which
is
the
operations,
the
management.
B
How
do
you
test
these
links?
And
so,
while
these
aspects
of
these
things
are
in
maintenance
mode,
because
again,
every
two
to
three
years,
life
changes,
there's
always
a
little
bit
of
revision
to
make
sure
it
stays
capable
and
it
generates
at
least
two
to
three
RFC's.
To
keep
going
with
that
possible
work.
That's
coming
is
OEM
security
notice.
We
keep
saying
security
because
the
attacks
are
going
up.
The
network
keeps
thinking
about
it,
go
ahead.
B
C
camp
is
a
generalize
MPLS,
so
we
have
specific
MPS's
and
then
we
have
a
generalized
MPLS
and
they
work
very
well
for
the
fiber
optics.
There
are
these
very
large
fiber
things
which
are
OTN,
which
are
basically
here's,
MPLS
and
there's
fiber
that's
been
directed
and
that
generic
MPLS
added
additions
to
existing
protocols,
RSVP
OSPF,
is
is,
and
it
also
worked
down
to
the
very
fiber
and
to
the
photonics.
B
So
what
happens
is
they
can
now
get
very
good,
fail
over
time,
subset
and
fail
over
time,
and
they
continually
work
to
get
better
because
the
fibers
do
get
better
over
time.
Go
ahead.
Flex
grid
was
one
example
where
things
are
changing
and
the
data
centers
are
picking
up
the
fiber.
So
you
see
we're
getting
another
use
case.
B
Besides
just
long-haul,
the
l2tp
is
a
seasonal
working
group
because
it
has
layer,
2
tunneling,
and
this
is
an
example
where
a
working
group
will
come
up
and
it
will
say
hi
we've
got
some
work
to
do
and
then
it'll
go
away.
We
call
that
going
on
hiatus.
The
High
days
is
like
I'm,
going
to
sleep
for
a
while
and
when
you
have
more
work,
wake
me
up
and
it's
currently
working
on
a
gang
model
go
ahead
so
T's.
Now
this
is
an
interesting
new
working
group.
B
B
to
Singapore
that
needs
traffic
engineering,
so
these
traffic
engineering
was
first
formed
by
the
MPLS
and
C
camp
to
take
this
specific
work
and
focus
on
it
to
get
it
done,
it
handles
high
architecture
and
it
handles
management
together
for
this
traffic
engineering,
for
either
the
data
center
provider
networks
and
maybe
even
for
small
networks
where
they
might
not
have
enough
bandwidth.
So
it
has
oversight
and
it's
doing
some
really
exciting
modeling
work
for
traffic
engineering
and
it's
working
on
the
four
edge
of
trying
to
provide
quick
configuration.
B
You
might
want
it
for
your
company
or
for
your
home
because
you
want
to
be
able
to
get
just
the
right
bandwidth
and
they're
working
on
new
configuration
models
to
do
that,
they're,
also
working
on
segment
routing.
How
many
people
have
heard
the
phrase
segment
routing
before
okay?
Well,
you're
gonna
see
this
and
lots
of
our
pieces
go
ahead.
Next,
one
trail
trail
is
another
working
group
I
charter.
B
It
was
developed
as
an
alternative
to
802
one
eight
q,
which
is
eius
eius
for
layer
two
drill
is,
is
either
layer
two
and
it
provides
a
protocol,
that's
transparent
to
operation
for
bridging,
and
they
really
can't
see
it.
It
runs
I
sized
in
the
center,
but
it
provides
a
seamless
bridging,
so
you
plug
it
in
and
it
just
works
and
it
supports
multiple
destinations.
It's
been
used
in
data
centers
and
it's
been
used
in
some
campus
networks,
both
education
and
some
corporate
campuses.
B
It's
currently
doing
the
same
sort
of
things
that
you've
seen
from
eius,
eius
or
other
things
where
it
says.
Okay,
now
we
got
one
topology.
Can
we
have
a
virtual
topology
with
just
some
of
you?
You
know
it's
like
a
friends
network.
I
just
want
to
talk
to
some
of
my
friends,
okay
and
you're,
seeing
that
because
the
data
centers
really
do
need
sometimes
one
cluster
to
talk
to
a
second
cluster.
This
work
is
going
to
be
completed
by
March
2018
and
will
probably
close
or
go
into
hiatus.
Probably
this
one.
B
Maybe
a
hiatus
moment,
am
I
on
your
turn.
I
got
one
more
okay,
so
routing
support
and
operations.
So
this
is
one
of
my
passions
is
because
IP
started
with
a
lot
of
hand.
Configuration
and
we've
tried
to
work
step
by
step
to
get
better,
because
one
of
the
things
that
you
do
is
you
say:
I
want
to
configure
a
network
and
if
my
little
phone
app
can
be
done
in
hours,
my
network
connectivity
should
be
done
in
minutes
and
the
problem
is
the
automation.
B
Tools
have
traditionally
lagged
behind,
but,
as
I've
said,
with
a
new
approach
that
says
we'll
use
one
protocol
on
a
whole
bunch
of
data
models.
We
hope
to
change
this
now.
The
operations
management
and
the
operations,
administration
and
management
or
the
OEM
is
a
set
of
tools
that
are
actually
helping
you
monitor.
So
you
combine
configuration
with
these
monitoring
tools,
because
when
you
have
a
connection
to
your
home,
does
anybody
ever
have
problems
with
it?
I
sometimes
do
and
I
complain
and
say
you
know.
B
This
connection
is
bad
and
I
have
my
own
tools
that
run
it,
but
we
want
to
be
able
to
have
that
for
everyone.
So
you
can
say
my
tools
are
bad
and
the
people
running
your
network
and
say
yep
you're,
right,
okay,
so
BFT
is
one
of
those
tools
that
we
use,
because
it's
a
short
hello,
hello,
I'm
here,
hello,
I'm,
not
here
or
hello,
I
heard
you.
We
thought
it
would
be
a
short-lived
group
because
it
was
a
simply
hello.
Packet
am
I
getting
my
packets.
B
Who
are
you
up,
but
it's
found
to
be
useful
in
so
many
working
groups.
We
keep
getting
thinking,
it's
going
to
get
done
and
then
they
add
a
few
more,
but
its
current
focus
is
multicast
and
seamless
BFD
for
end-to-end
monitoring.
Again,
if
you're
at
the
end,
where
you
want
to
say,
can
I
get
there,
you
might
want
to
say
hello.
Are
you
there
to
the
remote
end
and
have
it
come
back?
Okay,
our
to
us.
This
is
another
working
group
I
chair.
B
The
working
group
chose
Yang
and
use
Netcom
press
come
go
ahead.
Pce
was
in
initially
considered
to
be
something
like
what
we
now
have
is
Sdn,
but
it
predates
it
for
years,
and
it
said
maybe
I
have
a
really
fast
computation
machine
over
here
and
I
should
be
using
that
instead
of
this
really
expensive
router,
so
PCE
allowed
to
be
able
to
have
computational
paths.
Now
it
handles
these
sophisticated
computations
and
it
is
an
interactive
protocol
with
the
networks.
B
It
will
say:
oh
I've
got
a
network
event
and
it
may
have
several
places
within
the
networks
that
they've
offloaded
this
calculation.
What's
the
benefit,
if
you
have
photonics
and
you
have
thousands
of
photonic
pass,
perhaps
you
want
to
do
pick
three
or
four
to
light
up
and
you
suddenly
discover
you
have
more
traffic,
so
you
light
up
a
few
more.
This
PCE
can
help
you
do
some
of
the
calculations,
it
will
report
Network
events,
it
will
supply
updates
and
it
will
have
new
pass
setups.
B
It
encompasses
some
of
the
segments
routing
and
its
future
cases
are
coming
from
the
t's
working
group
and
sometimes
from
the
inte
from
tsch
and
the
debt
net
so
again,
you're,
seeing
that
old
protocols
or
old
concepts
are
continually
being
reused
in
the
next
generation
of
routing.
Why
is
there
a
value
for
that?
The
value
for
that
is
because
we
don't
have
to
remake
everything.
A
Thank
you,
so
the
next
category
we're
going
to
talk
about
of
the
routing
services
groups,
because
we
use
routing
to
deliver
just
plain
packet
forwarding,
but
also
to
deliver
enhanced
services
VPNs
at
layer,
3
or
at
layer
2
pseudo
wires,
which
we
want
to
make
the
network
behave
as
if
you
actually
had
a
real
wire
between
the
two
edge
points.
So
these
things
deliver
services.
They
leverage
all
the
routing
technology,
so
we
do
it
in
routing
and
it's
part
of
this
work
there's
been
a
bunch
of
new
ideas
in
there
and
consolidation
of
working
groups.
A
Next,
so
one
of
the
ones
we
have
there
is
the
BGP
enabled
services,
because
a
lot
of
the
services
have
to
cross
operator
domains.
You
want
to
be
able
to
get
your
VPN
from
here
to
where
you
are,
even
if
that's
more
cross
operators.
Therefore,
you
want
to
use
BGP,
which
is
the
inter
domain
routing
protocol
to
support
these
things.
So
the
biggest
focus
right
now
is
what's
called
a
VPN
which
is
Ethernet
VPNs,
so
that
you're
getting
a
layer
2
service
using
BGP
to
carry
not
just
where
is
the
service.
A
But
where
are
the
individual
MAC
addresses,
so
it
gives
up
very
fast
response
time
for
knowing
things
you
don't
have
to
flood
packets
across
the
the
operator
domain.
Flooding
is
expensive
when
you're
talking
about
across
the
internet,
and
so
it
because
it's
bgp
of
course
coordinates
very
closely
with
the
IDR
working
group.
A
They
also
do
some
other
LDP
enabled
services,
but
their
focus
is
l2v
PMS
that
are
not
driven
from
BGP,
and
so
they
get
the
Ethernet
style
service,
for
that
looks
like
a
wire
and
they
have
a
very
careful
definition
of
what
that
means
and
what
the
constraints
are
and
how
to
make
that
work
using
things
like
rsvp-te
and
LDP.
So
it's
the
converse,
if
you
will
des,
is
on
the
BGP
side.
Pals
is
on
the
non
BGP
side
and
they
go
together.
Next,
okay,
I!
A
Guess
we
have
on
vo
three
of
these
days,
one
of
the
things
that
we
do
is
we
move
working
groups
between
areas
when
it
seems
like
they
fit
so
I
believe
talk
about
Lisp
later
Lisp
was
in
the
internet
area.
It's
now
in
the
routing
area
and
vo3
was
in
the
internet
area.
It's
now
in
the
routing
area,
because
we
looked
at
and
said,
the
control
structures
are
becoming
the
focus,
but
it's
also
during
a
data
encapsulation
they're
agreeing
on
what's
called
the
genève
encapsulation
for
delivering
overlay
services
in
data
centers.
A
So
there's
a
long
time
that
was
spent
on.
Do
we
use
VMware's
via
clang?
Do
we
use
genève?
Do
we
use
GRE?
What
are
we
used
for
this?
A
lot
of
debate
right
now,
control
and
security.
Imagine
that
how
do
you
secure
this
stuff
appropriately
is
a
very
big
issue,
because
you're
talking
about
stuff
that's
operating
at
packet
times,
but
that
wants
isolation.
You
don't
want
tenants
getting
mixed.
A
That
would
be
very,
very
bad,
so
they're
trying
to
run
it
and
find
the
right
balance
and
security
delivery
in
there
service
function,
changing
which
is
when
I
happen
to
co-chair,
is
concerned
with
delivering
traffic
to
the
right
places.
It's
a
little
different
from
classic
routing
classic
routing
is
about
delivering
packet
to
the
far
end
where
it's
at
rest,
but
operators
deliver
services,
whether
it's
firewall
services,
URL
filtering
services
that
are
mandated
by
governments,
content,
transcoding
services
that
help
cellular
we
behave
well,
they
deliver
transparent
services.
A
You
don't
want
to
have
all
of
the
packets
from
all
of
your
users
going
through
all
of
your
functions
like
scaling,
really
really
bad,
so
service
function.
Chaining
is
a
way
to
control
which
packets
visit,
which
services
RFC
76065.
It
describes
the
architecture.
The
network
service,
header
ID,
describes
the
encapsulation
mechanism
we're
going
to
use
because
it
is
another
overland.
It's
an
overlay
with
path,
identification
and
metadata.
A
The
iesg
approved
last
week
the
publication
of
the
network
service
header
as
an
RFC,
a
proposed
standard
RFC
we're
now
moving
the
work
forward
on
OAM
on
security
and
on
related
issues,
but
away
I'm
operability
and
security
where
the
work
is
next
so
looks
like
we're
actually
ahead
of
schedule,
a
little
bit,
which
is
good.
So
if
you
have
questions
you
can
ask,
but
we
got
a
lot
to
cover.
There's
one
more
category
of
things
we
want
to
talk
about.
We
encourage
people
to
do
things
that
are
not
necessarily
obviously
correct.
A
Take
risks
experiment,
so
we
charter
working
groups
to
produce
experimental
results,
and
then
we
look
at
the
results
to
say
is
that
proving
useful?
If
so,
we
move
it
to
standards
track,
but
it's
good
I
actually
wish.
We
had
a
few
more
experimental
things,
because
if
you're
gonna
do
experiments,
everyone
said
well,
you
ought
to
be
failing.
Otherwise,
you're
not
experimenting
enough
and
we
had
a
very
good
track
record
of
successes.
So
the
way
it
goes
so
one
of
them
is
beer.
A
Basically,
some
folks
looked
at
the
way,
multicast
scales,
and
they
said
this
is
painful.
Why
does
it
hurt
so
much
when
I
want
to
carry
multicast
across
the
across
my
domain?
They
said
what,
if
I
could
mark
in
the
packet
the
multicast
tree,
and
they
thought
about
it
a
bit.
It's
not
obvious
how
you
do
that,
but
they
came
up
with
a
very
good
way
to
do
it
and,
yes,
it
changes
the
phoning
behavior
of
routers,
so
it's
risky.
A
This
is
asking
people
to
step
up
to
a
major
change,
but
if
multicast
matters
and
in
certain
environments
it
matters
a
lot.
This
is
a
viable
way
to
do
it
that
scales
much
better.
We,
however,
you
got
to
do
it
without
replacing
all
the
routers
in
the
internet
or
you
can't
deploy
it
because
if
you
have
to
replace
everything
all
at
once
no
deployment
we
had
back
in
the
early
80s,
we
had
experience
with
Flag
days.
We
learned
don't
do
that.
You
cannot
replace
everything
at
once.
A
You
can't
even
you
might
think
well,
ok,
look
deploy
the
new
software
in
every
place
and
then
turn
it
on.
All
at
once
sounds
great
blows
up
in
our
faces,
so
we
try
to
learn
our
lessons.
So
that's
a
very
enthusiastic
working
group
they're
producing
their
experimental,
RFC's
and
already
talking
about
moving
to
standards
track
because
vendors
are
implementing
it.
Customers
are
using
it,
so
we're
really
moving
forward
very
quickly
on
it.
That's
what
we
like
to
see
next
locator
identify
our
separation
is
a
major
problem.
A
The
very
very
short
form
of
this
problem
is
an
IP
address
represents
both
who
is
communicating
and
where
they
are
in
the
network,
as
Yaakov
rector
used
to
say
either
the
IP
addressing
has
to
follow
the
topology
or
the
topology
has
to
follow
the
IP
addressing
well.
That's
because
it's
doing
two
things,
it's
forwarding,
which
is
topology,
but
it's
also
identity.
So
for
the
last
10
or
12
years,
we've
been
working
hard
on.
How
can
you
separate
them?
A
One
of
the
approaches
to
that
is
Lisp,
my
co-chair,
the
Lisp
working
group
and
it
started
out
as
experimental
RFC's.
We
published
a
whole
set
of
experimental
RFC's
on
the
encapsulation,
the
mapping
system,
so
that
you
can
get
from
an
identifier
to
a
locator
to
deliver
packets.
All
of
those
things
it's.
It
turns
out
to
enable
a
very
large
number
of
overlay
cases.
It's
really
good
for
large
scale,
dynamic
VPNs
for
data
centralized.
A
For
a
lot
of
things,
we
are
now
working
on
new
rfcs
that
will
move
it
to
the
standards
track
by
focusing
on
the
use
cases
that
have
turned
out
to
matter.
That's
one
of
the
interesting
things
you
may
think
you're
building
the
problem,
the
solution
for
internet
scaling,
that's
what
the
inventors
really
were
after,
but
it
turns
out
what
they
built
was
a
really
great
overlay
management
technology,
so
we're
gonna
standardize
it
for
that
problem
because
it
works
really
well
for
that.
A
Next,
there
is
a
little
bit
of
catch-all
work
and
specialist
work
that
doesn't
fit.
Sometimes
the
AG,
the
area
directors
just
take
care
of
it.
They'll
say
just
give
it
to
me:
I'll
take
care
of
sponsoring
it,
but
sometimes
we
do
a
working
group
for
a
while
to
take
care
of
it.
I,
don't
even
gotten
this.
Let's
see
next
I
guess
this
was
the
only
place
we
could
put
our
G
gwg.
This
is
a
area-wide
working
group.
It
serves
to
take
work
that
doesn't
fit
anywhere
else.
A
So
it's
actually
a
long
lived
working
group,
but
what
it
happens
for
you
were
a
group
working
on
in
any
given
time
changes
because
it's
got.
What
do
we
need
to
spend
some
attention
on?
We
don't
want
to
spin
up
a
whole
working
group
for
it,
so
that
describe
how
routers
can
improve
routing
success
to
catch
all.
A
It
serves
as
an
incubator
for
a
lot
of
ideas
and
we're
lots
of
people
are
talking
about,
there's
all
sorts
of
work,
so
the
one
thing
mobile
age
computing
is
another
example
of
things
that
come
up
they're
young,
who
mentioned
young
many
years
ago
we
had
SNMP
simple
network
management
protocol,
but
it
wasn't
simple
and
the
structure
for
management.
Information
for
SNMP
was
even
harder
than
the
protocol
itself
and
nobody
was
doing
configuration
with
us
turns
out.
There
were
some
good
reasons
for
that.
A
So
he
went
back
to
the
drawing
board
and
said:
can
we
design
something
that
actually
works,
that
people
can
actually
use
for
interoperable
configuration
of
network
devices
we
developed
in
the
operations
area,
the
protocols
for
net
cons
and
the
net
mod
working
group
to
find
the
language
for
describing
that
work,
which
is
yang
Yang,
describes
the
information
that
you're
going
to
manage.
You
can
then
exchange
that
using
XML
or
JSON,
but
the
description
is
in
yang.
It
describes
the
managed
objects
that
we
need.
It
is
not
object
oriented.
It
is
very
much
network
management
centric.
A
It
is
built
to
solve
the
network
management
problem
and
it
is
getting
tremendous
uptake.
It's
even
getting
used
for
a
lot
of
other
things.
I
won't
waste
time
on
that.
But
it's
tremendous
object.
There
are
a
hundred
and
twenty
active
IDs
with
the
yang
in
the
title.
There's
open
source
work
I
to
our
s,
for
example,
focused
on
using
yang
for
our
configuration
we
try
to
put
the
net
mod
working
group
can't
hold
all
of
the
yang
work.
That
would
make
no
sense
because
they
don't
have
the
experts
on
what's
being
modeled.
A
So
the
working
groups
in
the
routing
area
are
responsible
for
their
own
yang
models,
but
they
have
to
work
with
the
net
mod
guys
to
make
sure
they
build
consistent,
workable
yang
models
and
for
things
that
way,
we
don't
have
any
place
to
do
it,
because
it's
old
models
that
we
need
to
refresh.
We
do
it
in
order
to
GWT
next.
A
The
ITF
has
birds
of
a
feather
sessions.
We
have
some
rules
on
that.
No
topic
can
have
more
than
two
birds
of
a
feather
sessions.
If
you
can't
figure
out
what
you're
doing
in
two
sessions,
you
probably
don't
have
a
clear
enough
idea
and
will
generally
Ward
you
after
the
first
one.
You
don't
know
what
you're
trying
to
solve,
because
people
have
somebody
wanted
to
do
a
working
group
on
Sdn.
A
What's
the
work
you
have
to
focus
on
an
achievable
topic,
so
buffs
exist
to
allow
us
to
have
a
discussion
on
a
topic
and
then
to
drive
to
clarity
on
what
is
the
work
that
needs
to
be
done.
We
have
a
companion
organization,
the
IRT
s,
I'll
talk
about
it
later
we're
much
fuzzier
things
can
be
done,
but
they
still
need
to
be
progressing,
but
IETF
engineering
groups
have
to
be
about
engineering,
something
with
a
specific
goal
and
a
clear
understanding
of
what
we're
doing
so.
A
This
session
we're
having
a
non
working
group
forming
Bob
on
data
center
routing.
There
are
about
six
different
proposals
for
ways
to
improve
routing
behavior
in
highly
meshed
leaf
spying
data
center
networks,
because
if
you
just
run
IFIs
or
OSPF
on
a
leaf
spying
network,
you
see
this
massive
explosion
of
information.
That's
not
doing
you
any
good
at
all
and
everybody's
going.
It's
got
to
be
a
better
way
and
people
are
finding
many
different,
better
ways
and
so
we'll
be
exploring
all
of
those.
What
is
the
problem?
We
need
to
solve.
What
are
the
constraints?
A
What
are
the
ideas
in
this
birds
of
a
feather
session,
and
it
should
be
an
interesting
discussion.
Wednesday
I
believe
it's
Wednesday
morning.
Next
slide
we
do
close
working
groups,
that's
a
good
thing.
It
means
you
laid
out
an
achievable
set
of
work
and
you
didn't
the
forces
working
group
that
I
was
involved
in
for
many
years.
We
got
the
work
done.
We
closed
the
working
group,
it's
not
that
what
you're
doing
is
dead
or
pointless,
but
rather
you've
done
the
work.
Let
people
go
implemented,
use
it.
A
If
we
need
to
wake
it
up
again,
we
can
we're
good
at
that,
but
focus
on
using
it.
So
some
of
them
are
antiques,
rip
and
rip.
V2
sue
said
really
old,
distance-vector
protocols.
They
have
some
interesting
problems,
but
particularly
in
terms
of
the
complexity
you
could
implement
easily.
They
were
really
easy
to
implement
in
the
late
80s
and
early
90s
and
then
later
90s
for
rip
free
to
rip
detail
had
to
be
done
because
the
original
RIP
encoded
IP
address
classes
in
its
underlying
mechanism.
A
Whoops
we
moved
to
a
classless
Internet.
You
can't
do
that,
so
we
had
to
revise
it
very
simple
protocol
still
out
there.
People
use
it.
Brrp
is
a
beautiful
piece
of
redundancy.
That's
used
all
over
the
place.
The
working
group
is
closed.
We've
got
it
done,
everybody
uses
it.
It's
really
great
forces.
I've
talked
about.
You
can
find
the
work
the
list
over
there
of
all
the
things
that
we
have
done
and
it's
all
there's
a
lot
of
interesting
work
in
there.
Next.
A
One
of
the
ways
routing
routing
area
gets
its
work
done,
and
this
has
now
become
common
to
most
areas
in
the
IETF.
It's
not
all
I
think,
but
most
I
think
maybe
all
of
them
have.
It
now
is
Directorate,
so
you
know
that
you've
probably
heard
from
other
places.
We
have
area
directors
who
are
responsible
for
the
area
area
directors
are
human.
They
can't
do
everything.
We
have
three
area
directors
in
routing.
They
still
can't
do
everything.
A
So
we
have
is
a
set
of
people
who
advise
the
area,
directors
they're
selected
by
the
area,
directors
they
serve
at
their
pleasure
and
their
job
and
in
the
IETF
terms,
is
to
provide
advice.
So
we
have
46
members
on
the
routing
area
Directorate.
That's
because
we
want
to
review
a
lot
of
things.
We
want
to
do
early
reviews
to
look
for
if
there
are
there
serious
problems
here
that
are
being
ignored
by
this
working
group,
so
we
can
call
attention
to
it.
Early
in
every
piece.
I've
ever
worked
on.
A
I
would
much
prefer
to
be
told
early,
you're,
ignoring
a
hard
part,
then
to
get
all
the
way
through
and
think
I'm
done
and
then
have
somebody
say
oops.
You
forgot
something
important.
So
we
why
to
catch
things
early,
that's
part
of
what
the
routing
Directorate
does
different
areas.
The
directors
have
different
jobs,
but
the
purpose
is
to
provide
good
quality
and
to
look
at
routing
issues
in
drafts
outside
of
the
routing
area,
because
we
said:
there's
overlaps,
there's
routing
issues
that
other
people
come
up
with.
A
Behaviors
people
make
assumptions
about
what
routing
can
do,
and
sometimes
it
can't
and
we'd
rather
catch
that
and
say
you
know,
the
system
doesn't
work
the
way
you
understood
it.
We
are
all
very
skilled
here,
but
we
also
all
make
mistakes
more
eyes.
Looking
at
things
early
across
areas,
it's
really
really
helpful.
So
there's
some
coordinators,
John,
Hardwick
and
Amy
ye,
who
are
big
help
to
folks
like
me
who
serve
on
the
routing
Directorate
because
they
take
care
of
who's.
A
A
The
real
message
I
want
to
get
to
you
guys
is
there's
lots
of
ways
to
contribute
to
work
at
the
IETF.
We
want
you
to
participate.
That's
why
we're
taking
the
time
to
try
to
give
you
a
sense
of
the
breadth
of
all
of
this
get
on
the
mailing
lists.
Watch
the
discussion
participate
in
the
discussion
once
you
know.
What's
going
on,
if
you
have
good
ideas,
write
your
own
internet
drafts
bring
them
forward.
There
are
also
other
ways
you
can
help
us
and
that's
that
the
core
way
is
contributing
review.
A
Drafts
I,
don't
know
a
working
group
that
can't
use
more
reviewers,
because
the
big
challenge
is
extra
eyes.
Looking
at
things
to
say
what
did
we
miss
because
it's
very
easy
when
you're
working
on
something
you're
neck
deep
in
it?
You
assume,
you
know
how
it
all
works.
You
assume
the
word
say
the
right
thing
until
somebody
points
out,
you
said
exactly
the
opposite
of
what
you
meant.
A
Please
catch
really
help
me.
It
happens
the
number
of
times
where
I've
seen
that
as
surprising,
but
yes
right
exactly
the
wrong
thing
minute.
Takers,
chopper,
scribes,
we'd,
love
the
help.
We
appreciate
everybody
who's
willing
to
do
that.
If
you
get
a
little
bit
more
experienced
become
the
working
group
secretary
I,
don't
let
you
see
the
process
that
you
learn,
how
things
work
we
have.
We
as
chairs
really
appreciate
our
working
group,
secretaries.
They
help
us
function
and
it
gets
you
visibility
into.
A
A
So
next
and
there's
lots
of
work
in
other
places
that
overlaps
with
routing
may
be
the
right
place
for
you,
because
of
what
your
interests
are.
Are
some
of
those
other
works
that
the
amount
of
operation
stuff
I
mean
if
we
can't
make
these
routing
protocols
operational,
if
we
can't
use
them
in
the
real
world,
we've
wasted
our
time
so
operationalizing
these
meeting.
The
operational
constraints
is
very
important.
You
can
see
a
number
where
do
a
joint
operations
and
management
deployments
global
routing
operations?
There's
a
lot
of
work
in
ops.
A
That
really
is
core
to
routing,
but
the
key
is
operational
requirements
and
we
try
to
drive
that
the
internet
area,
of
course
overlaps
with
routing
the
distinction.
We
draw
a
line
and
say
this
is
routing.
This
is
internet,
but
they
live
hand
in
hand.
So
the
internet
areas
6-man
discusses
packet,
forwarding
behaviors,
and
what
can
you
do
in
the
middle
because
they
want
behavior,
they
want
functionality,
but
it's
got
to
be
informed
by
what
routing
does
and
what
routers
can
do.
So,
there's
a
lot
of
overlap.
Hip
was
an
all
interesting
one.
A
So
you've
gone
back
up
one
more
home.
Networking
sue
talked
about
six
tissues
at
time.
There's
places
where
you
need
real
understanding
of
time
and
turns
out
time
is
a
really
complicated
thing.
You
think
it's
a
really
nice
simple
thing:
it's
not
frightening
me
when
I
discovered
that
and
performance
measurement
next,
so
as
I
alluded
to
we're
almost
out
of
time,
the
IRT
F
does
a
lot
of
things.
They
do
research.
Their
job
is
not
to
look
at
things
that
are
ready
for
engineering.
Rather,
their
job
is
to
discuss.
A
What
would
the
internet
implications
be
for
this
piece
of
technology
or
that
piece
of
technology?
How
could
we
do
this
kind
of
thing
in
the
internet?
So
there
was
an
SDN
research
group
because
it
was
what's
the
implications
on
the
internet
from
the
deployment
of
Sdn.
Currently
there's
global
access
network
virtualization
that
were
coding,
which
is
a
different
kind
of
thing.
How
do
you
put
information
into
packets
for
redundancy
pathaway?
Networking
is
a
new
one.
That's
trying
to
see!
A
Well,
if
you
have
specific
constraints,
maybe
you
need
to
know
more
about
the
paths
in
the
network
and,
of
course,
IOT
thing
to
think
next
slide.
There
is
an
independent
stream,
not
everything
we
publish,
has
to
go
through
the
ADEs
or
through
working
groups.
If
there's
informational
documents
that
you
think
would
benefit
the
IETF
bring
them
to
the
end
of
it,
but
they
don't
fit.
Maybe
the
right
answer
is
to
bring
them
to
the
I
independent
stream.
A
Editor
Neville
Brownlee
is
currently
the
editor
Adrian
Farrell
will
be
the
editor
lots
of
interesting
work
gets
published
that
way,
it's
really
nice
and
varied
work.
These
are
links
that
things
you'll
need.
Next
slide:
lots
of
thanks
by
the
way
I
wanted
to
add
a
thank
you
to
you
of
for
providing
a
laptop
and
we
couldn't
connect
our
laptops.
A
This
material
was
backup
one
please.
This
material
was
based
on
work
from
Adrian,
Farrell
and
Jeff
Haase
they'd,
so
we
reused
a
lot
of
their
slides.
We
did
ask
all
the
area
director.
All
the
working
group
chairs
for
input,
the
area
directors
helped
us
get
this
together,
but
we've
been
doing
this
so
I
hope
this
was
useful
to
you.
I
believe
we
are
now
out
of
time.
But
if
somebody
has
a
quick
question
or
two
we
can
probably
answer.