►
From YouTube: IETF112-RTGAREA-20211112-1430
Description
RTGAREA meeting session at IETF112
2021/11/12 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Hello,
everyone.
I
hope
you
can
hear
me.
It
is
9
30,
where
I
am,
which
means
that
it
is
time
for
the
session
to
start.
I'm
gonna
give
people
a
couple
minutes,
especially
because
I'm
missing
my
co-chairs.
C
A
Yes,
so
there
has
been,
the
llcj
specifically
has
been
looking
at
different
sites.
I
believe
it
has
been
made
public
that
we
are
not
considering
asia
and
we're
not
considering
north
america
either.
So
all
I
can
say
right
now
is
that
it
will
be
most
likely
in
europe.
A
Yeah,
it's
hard
to
say
more
inside
info
on
the
public
forum
being
recorded
and
transmitted
through
youtube,
but
yeah.
So
I
believe
that
we're
in
the
final
phase
of
getting
the
contract
signed-
and
you
know
figuring-
that
out
things
are
changing.
Of
course,
in
europe,
all
the
time
and.
A
That's
all
that's
all
I
can
say
I
guess
right
now,
yeah
so
antoine
just
said
in
the
chat
that
the
code
cases
are
going
up
again
in
europe.
So
yes,
I
I
don't
know
how
that's
affecting
the
negotiations,
because
I'm
not
part
of
that.
But
yes,
those
are
things
that
we're
all
keeping
an
eye
on.
A
C
A
So,
martin,
what
do
you
think
should
we
start.
A
F
Yeah,
I
think
we
should,
but
john
john
should
should
join
us
in
a
few
minutes.
A
Yeah,
I'm
assuming
there's
probably
other
people
other
routing
people,
not
just
other
people,
otherwise
people
in
that
site
meeting
as
well.
That
will
probably
join
us.
So
when
we
start
with
the
audience
trivia,
this
is
the
roadinger
open
meeting.
You
can
probably
see
me
on
the
video
martin
can
maybe
show
himself
too.
A
A
You
have
all
been
aware
of
the
note.
Well,
and
hopefully
you
have
all
noticed
that
we
all
the
chairs
of
the
different
working
groups
have
been
highlighting
not
just
the
ipr
nature
of
the
note
well,
but
the
parts
that
talk
about
the
behavior
and
the
conduct
during
the
meetings
there
are
links
here
to
the
anti-harassment
procedures
to
the
code
of
conduct.
A
Please
make
yourself
familiar
with
that.
Make
sure
that
whatever
behavior
that
you
display
in
the
meetings,
including
all
the
virtual
meetings,
the
the
jabber
or
the
meat
echo
and
some
messaging,
that
they
all
adhere
to
that
some
of
the
points
in
the
pro
conduct,
which
is
rc
7154,
are
the
ones
here.
The
reason
we're
here
all
of
us
is
to,
of
course,
contribute
to
the
ongoing
work
of
the
atf,
which
is
meant
to
make
the
internet
grow
work
better.
A
We're
here
to
do
engineering.
Please
focus
on
that
focus
on
on
technical
arguments.
Focus
on
treating
your
colleagues
with
respect.
English
is
the,
I
guess
the
fact,
the
language
of
the
atf-
and
you
know
that's
fine.
Many
of
us
don't
speak
english
as
a
first
language.
A
We're
always
looking
for
feedback
on
how
we're
doing
sadies
not
only
what's
going
well,
which
is
always
nice
to
hear,
but,
more
importantly,
what
may
not
be
going
well,
what
may
be
broken
with
the
area
or
what
you
know
things
we
could
do
better.
A
Many
of
you
hopefully
saw
a
survey
a
few
weeks
ago.
It
actually
concluded-
I
think,
earlier
this
week
on
a
360
evaluation
experiment
that
we
did
for
the
aesg,
so
where
you
could
have,
you
know,
send
feedback
about
us,
specifically
the
three
of
us
cds.
A
That
was
a
good
opportunity
if
you
want
to
talk
to
us
individually,
either
directly
or
indirectly.
If
you
want
to
tell
john
or
martin
about
me-
and
you
don't
want
to
tell
me
directly-
that's
fine,
you
know
tell
them
they
can
anonymize
things.
This
is
also
a
good
time
to
talk
to
the
namco
about
not
just
the
candidates
to
become
a
d
next
time
and
starting
in
march,
but
also
about
you
know
the
ongoing
work
that
we're
doing.
A
They
also
take
care
of
of
anonymizing
of
necessary
information
and
giving
us
some
feedback.
There's
not
a
lot
of
feedback
coming
but
again
yeah,
please
bring
it
up.
Tell
people
tell
us
how
we're
doing
and
what
can
we
do
better.
A
One
of
the
things
I
think
we
can
all
do
better
is
review
documents.
Please
please
review
documents.
While
the
working
group
review,
all
the
documents
are
not
yours,
especially
so
that
we
can
increase
the
the
quality
of
the
documents
that
not
only
are
produced
by
the
working
group
that
get
out
to
the
isg
and
the
rest
of
the
atf.
This
improves
the
quality
and
improves
the
process.
Of
course,
it
makes
it
hopefully
faster
for
everyone.
A
So
this
is
the
agenda
for
today.
It's
the
you
know
typical
agenda.
Some
of
this
will
be
at
the
top.
I'm
gonna
have
a
writing
director
report
and
then
we're
gonna
have
some
working
group
updates.
Those
six
working
groups
are
listed
there
and
we
should
have
time
at
the
end
to
for
any.
You
know
for
other
discussion.
A
Just
one
thing
drew
just
posted
in
the
chat
that
november
23rd
is
the
deadline
for
community
feedback
to
the
dom
com.
So
please
make
sure
you
you
provide
feedback
there.
Does
anyone
have
anything
to
say
about
the
agenda?
Any
comments,
any
things
you
want
to
change
add.
A
I
know
we
only
have
one
hour
so
should
should,
as
that
we
still
have
time
at
the
end,
not
a
lot
change
or
not
much
change,
nothing
change
to
be
specific
in
the
area
in
terms
of
working
groups
within
open,
close
or
which
are
any
of
the
working
groups,
some
because
it
was,
I
guess,
summer
and
vacation
time,
for
many
people
were
a
little
bit
slow.
Hopefully
we
can
pick
that
up
now
towards
the
end
of
the
year.
A
When
the
holidays
come
up,
we
don't
have
any
new
chairs.
The
last
match
came
in
the
last
itf,
quick
reminder
of
who
has
who
is
responsible
for
which
working
groups
in
case
you,
you
don't
know
everything.
All
this
information
is
working
there
as
well.
A
A
G
G
The
real
result-
and
basically
we
have
one
third
of
them
with
ready
one
third
with
net,
so
one
third
with
some
issues
and
we
feedback
this
to
corresponding
working
groups
to
further
discussion
and
before
we
proceed
into
the
iesd
review
and
on
the
right
hand,
side.
There
is
some
non-rtg
error,
drafts
review
result
and
I
think
a
half
of
them
are
having
issues
and
maybe
one-fourth
of
them
has
needs,
and
some
of
them
there
are
also
19
with
ready
status.
G
So
that
is
just
a
basic
capture
for
the
for
the
for
the
review
of
work
in
last
three
and
a
half
months,
and
we
are
looking
forward
to
see
the
ads
requesting
more
reviews
and-
and
we
also
expect
our
experts
help
as
much
as
possible.
Thank
you
for
all
the
experts
and
that's
my
part.
A
So,
thank
you
for
watching
director.
This
helps
a
lot.
I
know
it
helps
me
as
an
ad
to
get
reviews
from
you
guys
don
go
ahead.
H
C
The
worst
status
you
I
mean,
the
the
worst
status-
is
the
one
that
it
gets
logged
in
as
the
status
of
the
draft
like.
If
it's
not
ready,
that's
the
worst.
You
know
and
that's
the
one
that
gets
logged
and
in
decreasing
severity
that
that
would
be
how
the
statistics
are
taken.
I
Okay,
so
a
question
to
the
directorate,
since
I
haven't
participated
in
it
for
a
number
of
years.
What
would
be
the
single
biggest
change?
You'd
recommend
for
cleaning
up
the
draft
before
it
gets
to
you
that
you
think
the
working
group
should
do
better
about.
A
That's
that's
a
a
good
question.
You
know
personally.
I've
noticed
that
when
I
get
some
of
the
drafts-
and
you
know
this
answer
may
be
different
from
john
martin-
there
are
some
basic
things
that
could
be
checked.
You
know
references
security
considerations.
A
You
know,
I
still
see
many
drafts.
That
say
there
are
no
security
considerations
and
while
in
some
cases
that
may
actually
be
true,
it
would
be
at
least
nice
to
explain
why
there
are
none
of
them.
You
know
there
are
basic
things
with
ayana
allocations.
A
A
I
would
of
course
also
expect
that
it
wouldn't
be
us
to
the
ones
who
find
technical
issues
with
the
documents
that
doesn't
happen
all
the
time,
but
it
happens
once
in
a
while
and
if
they
have
gone
through
the
review
of
the
experts
in
the
working
groups.
Well
that
yeah,
you
guys,
know
a
lot
more
than
we
do
so
that
that
shouldn't
be
the
case.
I
don't
know
john
martin,
if
you
want
to
add
anything.
J
A
Yeah
so
jeff
suggested
on
the
chat
that
this
sounds
like
a
sort
of
a
checklist
yeah.
Maybe
there's
we
can
make
a
checklist.
I
am
under
the
impression
that
maybe
there's
something
in
the
wiki
somewhere.
I
know
that
adrian
had
done
a
presentation
when
he
was
a
d
about
some
of
the
things.
Maybe
we
can
dig
that
up
and
put
it
somewhere
too.
J
One
is
having
a
good
checklist,
one
is
keeping
it
up
to
date
and
one
is
actually
getting
people
to
use
it
at
the
appropriate
time
and
the
getting
people
to
use
it
seems
like
the
hardest
part
like
ideally,
authors
would
actually
go
through
and
read
the
checklists
for
authors
that
already
exist
and
act
on
them
and
if
they
did
probably,
you
know
most
of
the
things
that
we
catch
in
review
wouldn't
even
happen
because
they're
already
in
the
checklist
that
the
authors
supposedly
are
reading
through
so
yeah
I
mean
I'm
like.
J
Are
we
not
publicizing
the
checklist?
Well
enough,
are
we
not
letting
our
authors
know
about
them?
Well,
enough
are
the
are
the
checklists
you
know
too
heavy
and
and
not
usable
by
the
authors
like
all
of
this
would
be
useful
feedback.
D
I
was
thinking
for
just
a
minute.
I
got
confused
and
I
was
like.
Oh,
we
already
have
the
checklist.
It's
that
long,
write-up
list.
You
know
when
you
do
a
write-up
as
a
shepherd.
It
doesn't
have
everything
you
just
mentioned,
but
you
know
I
immediately
thought
of
it
right
because
it
goes.
You
know
it
doesn't.
D
Section
is
that
you
know
blah
blah
blah.
Maybe
maybe
the
write-up
should
be
done
before
the
routing
area
or
review.
D
I
just
went
through
the
through
this
process
with
the
ip
second,
it
was
very
weird.
I
felt
it
was
very
weird
that
the
chair
asked
me
as
the
author
of
the
document
to
write
the
write-up,
but
it
wasn't
an
entirely
horrible
idea
because
it
actually
you
know
and
that's
what
he
said
was
you
know
it
sort
of
makes
sure
that
all
the
stuff
is
there
anyway.
That's
why
I
thought
of
that.
I
think.
J
Up
on
that,
it
sounds
like
you
know,
as
an
author,
you
found
that
to
be
actually
a
better
experience
than
you
thought
it
would
be
and
like.
If
will
you
ask
your
authors
to
do
that?
Also,
like?
Is
it
that
good
of
an
experience.
D
You
know
I
don't
know,
but
I
think
that
it
could
possibly
stuart.
Can
you
mute
for
a
second
hear
myself
yeah?
So
thanks?
I
don't
know
if
I'd
do
the
write-up,
but
it
just
it
didn't
bring
to
mind
like
having
you
know
the
checklist
right
and
you
know
maybe
just
taking
that
that
was
useful
as
in
that
in
that
sense,
of
course,
I
write
write-ups
a
lot,
so
it
was
very
easy
for
me,
so
I
don't
know
if
I
would
ask
all
the
authors
to
do
it.
J
Yeah,
no,
I
mean
that's
exactly
what
I
found
right,
but
you
know,
and
hopefully
to
also
you
know,
reduce
the
load
on
the
shepard,
who
presumably
has
to
go
through
everything
that
the
author
put
into
the
into
the
write-up
anyway
and
verify
it.
D
It
wasn't
a
bad
idea.
I
we
just
have
a
lot
of
graybeards.
I
wonder
if
they'll
they'll
scoff,
what
are
you
going
to
do?
The
write-up
now.
A
So
stuart,
you
had
gone
off
the
queue.
I
thought
you
were
next.
E
So,
first
off
it
seems
to
me
that
before
directorate
get,
it
really
ought
to
be
reviewed
by
the
by
the
shepherd,
and
that
means
to
me
a
word
by
word
review
of
everything
in
a
complete
list
that
every
eye
is
dotted
and
every
t
is
crossed.
I
don't
see
why
it
would
be
otherwise
and
if
there's
more
questions
that
could
be
usefully
added
to
the
shepherds
report
to
make
sure
that
some
of
these
things
are
done.
E
I
think
that
would
be
a
very
useful,
a
very
useful
reminder
that
this
needs
to
be
done.
If
the
shepherd
wants
to
pass
some
of
it
back
to
the
working
group,
fine,
but
it
shouldn't
get
to
directorate
without
the
shepherd.
Having
checked
everything
in
in
detail.
D
D
E
D
D
E
J
Don
europe,
I
mean,
I
guess
we
could
talk
about.
You
know
what
exactly
is
early
direct
review
for
and
what
do
people
you
know
want
to
use
it
for
it.
Like
my
own
experience
of
it,
is
that
it's
sort
of
like
when
the
chair
says
yeah.
This
thing
is
pretty
close
to
being
ready,
but
we
want
somebody
outside
of
the
group
to
review
it
and
give
it
a
sanity
check,
and
that
kind
of
review
is
pretty
different
from
you
know,
sending
it
for
last
call
review.
J
H
Yeah,
I
I
think
a
checklist
would
be
great.
I,
as
a
as
an
author.
I
you
know
guilty
of
waiting
till
like
the
end
type
of
thing,
and
then
you
know
you
do
the
nits
check
you
do
the
submissions
checks
and
you
put
it
in
and
what
I've
I've
done.
A
number
of
yang
drafts
recently
and
I've
I've
been
tripped
up
by
the
system
and
and
even
just
like
mechanical
checks
that
I
missed
because
they're
not
part
of
this,
this
mission
process,
but
I
I
think
it
would
be.
A
A
Take
a
look
and
then
I
also
posted
another
link
to
something
called
the
authors
that
itf.org,
which
is
still
in
in
development,
but
the
intent
of
that
is
to
put
a
bunch
of
resources
in
there,
not
just
checklists
which,
but
also
the
authoring
tools,
how
to
do
the
xml-
and
you
know
stuff
like
that.
You
might
want
to
take
a
look
at
that.
C
One
thing:
one
thing
that
I
mean
this
isn't
true
of
all
the
drafts,
but
when
you
get
one
that
doesn't
it's
it's
kind
of
annoying,
especially
when
it's
one
from
that
isn't
a
routing
one
for
or
for
a
working
group.
You
don't
follow
is
if
you
get
a
draft
and
it
starts
right
in
with
out
saying
what
problem
it
solves
and
having
kind
of
an
overview
with
appropriate
references
to
other
documents
real
early
on
in
the
beginning,
and
I
think
I
think
it
would
be
good
if
every
draft
had
that.
C
I
know
that's
hard
to
do
because
I
don't
know
how
many
I've
seen
is.
You
know
you
have
like
the
abstract,
the
abstract
repeated,
and
then
they
start
right
into
encodings
and
then
how
it
works.
You
know,
and
you
kind
of
have
to
reverse
engineer
the
you
know
more,
a
more
detailed
overview
than
what's
in
the
abstract.
That's
just
that's
just
one
thing
that
I
find
happens
sometimes.
A
Yeah,
we
do
get
a
lot
of
comments,
ac
yeah
around
those
lines
from
reviewers
who
are
non
only
non-routing
reviewers,
but
none,
as
you
said,
people
who
don't
follow
a
specific
working
group,
because,
yes,
I
mean
sometimes
we
as
authors,
assume
that
everyone
knows
what
we
know
and
we
just
write
the
solution.
A
C
Reference
is
right
up
front
because
we
don't,
I
don't
expect
somebody
who's
doing.
You
know
most
of
our
most
of
our
documents
now
are
not
something
brand
new
their
enhancements
to
existing
protocols
or
solutions
so,
but
just
to
have
the
the
references
right
up
front.
So
they
could.
You
could
look
at
them
before
you
could
have
it
in
another
window,
so
you
could
consult
it
as
as
need
be,
while
you're
reviewing
it.
A
A
And
we're
gonna
start
with
babel,
donald.
B
Hi
there
I'm
donald
eastlake
one
of
the
chairs
of
the
novel
working
group
next
slide.
B
So
it's
one
of
the
smaller
working
groups,
perhaps
in
terms
of
number
of
drafts
and
things
like
that,
people
who
aren't
familiar
with
it.
You
know
it's
it's
distance,
vector,
running
protocol
but
augmented
with
mechanisms
to
avoid
the
void,
loops
or
count
to
infinity
or
anything
like
that
and
also
to
avoid
starvation.
B
So
it's
been
proven
to
be
quite
effective
in
a
number
of
instances.
You
know
it
has
various
motherhood
and
apple
pie.
It's
some
simple,
robust,
that's
been
implemented
multiple
times
and
opens
multiple
open
source
implementations
seems
to
be
pretty
robust,
against
embedded
to
behave,
networks
and
some
level
of
routing
some
level
implementation
and
errors
extensible.
B
It
particularly
seems
to
be
effective
in
networks
where
you
have
at
least
some
links
with
unstable
metrics.
These
are
typically
radio
links
or
overlays,
consisting
of
like
intercontinental
overlays
with
like
zillions
of
tunnels
involved,
so
that
you
get
the
combined
instability
of
all.
Of
these,
things
has
been
deployed
in
a
number
of
cases
and
it
was
seems
to
be
effective
in
small
unmanaged
networks.
Also,
next
slide.
B
Not
supposed
to
spend
much
time
on
documents,
but
people
should
be
aware.
Initially,
there
were
three
experimental
rfcs
documenting
it.
I
was
selected
as
the
homenet
working
group
mandatory
to
implement
routing
protocol,
so
it's
decided
to
standards
track
it
and
the
the
core
standards
track
documents
have
all
gone
through.
89.66
is
the
the
primary
one
on
the
routing
protocol.
There's
a
couple
security
ones
on
one
authentic
for
authentication,
one
using
dtls
for
encryption
and
authentication.
B
A
basic
information
model
is
through
and
source
specific
extension,
so
you
can
have
routing
that
depends
on
the
source
as
well
as
the
destination
next
slide.
B
So,
what's
going
on
currently
what's
happening,
there
yang
data
model
is
almost
through
it's
in
the
rfc
editor's
queue
and
work.
That's
really
happening,
it's
been
extended
so
that
you
can
route
ipv6
even
with
routers
that
have
no
ipv6
address.
So
you
can
have
the
next
hop
for
your
ipv4
routes
inside
your
your
router
network,
be
ipv6
addresses
and
it
seems
to
be
pretty
nifty.
B
It's
draft
is
currently
an
ad
evaluation,
the
most
complex
question
that
came
up
with
that,
I
think,
was
what
to
do
about
the
need
to
possibly
issue
icmps
from
a
router
out
of
version
4
ipv
version,
4
icmps
from
a
router
that
has
no
ipv4
address
and
if
there's
really
no
ipv4
address
around
that
there
is
at
least
experimentally.
One
could
use
the
dummy
ipv4
address
that
actually
has
been
allocated
and
is
in
the
iana
ipv4
special
uses.
Ipv4
address
registry,
which
is
192.0.0.8.
B
B
And
there
is
another
topic
in
the
charter
which
we
haven't
done
any
work
on,
which
is
multicast,
and
it's
partly
because
the
this
working
group
has
a
informal
but
very
strong
policy
of
of
not
even
really
adopting
drafts
unless
it's
been
implemented
and
deployed
at
least
limited
deployment
and
shown
to
work.
So
there
seems
to
be
a
little
demand
currently
for
multicast,
routing
and
and
it
hasn't
been
implemented
or
deployed.
So
really
no
work
has
started
on
that,
even
though
it
is
an
option
in
the
charter.
B
Next
slide
is
the
last
one.
This
just
gives
a
little
bit
more,
I
already
kind
of
said
what
was
going
on
with
the
ipv4
via
ipv6,
and
it's
a
little
more
on
the
round-trip
time.
B
You
would
imagine
that
that
would
be
unstable
and
lead
to
routing
oscillations
and
all
kinds
of
things,
but,
as
documented
in
the
draft
which
is
currently
expired
but
expected
to
be
reactivated,
there
are
various
techniques
and
hysteresis
and
so
forth,
which
have
found
to
be
very
effective
at
damping
that
and
in
actual
deployment
it's
improved
to
work
extremely
well.
B
So
nobody
completely
understands
why
it
works
so
well
and
if
there's
anybody
on
this
call,
who's
has
some
expertise
in
dynamic
system
of
stability
and
things
like
that,
and
I
would
like
to
look
into
this
and
perhaps
work
on
a
little
section
or
appendix
or
whatever,
in
the
protocol
that
explores
why
these
specific
methods
in
the
draft
have
been
demonstrated
to
to
work
so
well.
The
working
group
would
would
welcome
that
and
that's
the
end
of
my
report.
D
Yeah
so
having
had
to
write
a
a
comparison
draft,
a
while
back
between
babel
and
isis
for
home
net
use,
I'm
curious
how
that's
gone?
Have
you
seen
deployment
of
babel
in
the
home
net
scenarios
like
in
you
know
like
gateways
at
the
at
the
home.
B
I
I'm
not
aware
of
a
particularly
widespread
deployment
there,
but
I
actually
haven't
been
too
focused
on
that.
Most
of
the
uses
involve
you
know,
radio
meshes
overlays
so
and
other
uses
of
that
sort.
There
are
people
who
are,
I
have
valve
running
in
their
home.
How
many
of
them
are
are
non-implementers
available,
I'm
not
sure.
H
Yeah,
I
haven't
seen
anything
either
in
terms
of
deployments.
A
Thank
you
so
we're
gonna
move
to
mini
ronald.
A
I
don't
know
if
ronald
is
still
there.
I
saw
him
earlier
ronald,
yes,
you're
there.
A
It's
just
gonna
mute
myself,
so
yeah
we're
gonna
go
forward.
I
actually
I'm
gonna
skip
to
ivr.
I
got
a
request
from
one
of
the
chairs
that
they
have
to
go.
Where
is
idr.
I
Hello,
so
at
the
request
of
the
ads,
this
is
more
about
the
kinds
of
things
we're
doing
in
idr,
rather
than
endlessly
of
way
too
many
documents
that
we
all
have
to
stare
at
so
for
idr
and
for
bfd
we
try
to
keep
our
status
current
in
the
wiki.
This
is
as
much
for
the
fact
that
we
have
enough
work
going
on
and
we
are
older
and
can't
keep
things
straight.
That
lets
us
keep
track
of
it
ourselves.
I
So,
in
terms
of
interesting
work,
that's
been
happening
across
the
idea
in
the
recent
couple
months,
so
we've
been
having
a
lot
of
work
in
bgb
ls
extensions,
bhp
link
state
is
where
we
advertise.
You
know,
link
state
type
things
across
bgp
in
a
somewhat
abstracted
way,
very
helpful
for
traffic
engineering,
and
it's
become
very
popular
for
spring.
I
So
we've
been
seeing
a
lot
of
sr
type
things
that
have
been
going
in
there.
The
other
thing
that's
been
sort
of
at
the
top
of
idea.
Our
mind
has
been
things
related
to
bgp.
Flowspec
flowspec
is
the
feature
that
allows
us
to
send
effectively
firewall
components
inside
of
bgp.
I
It's
a
original
use
case
for
us
for
protecting
no
routers
across
your
network
with
a
common
set
of
firewall
rules
distributed
the
protocol
we
had
to
bust
the
base
rfc,
which
was
originally
5575
to
clear
up
a
number
of
lingering
nits,
but
part
of
what
the
work
that
we
did
there
effectively
gave
us
consensus
on
is
that
the
protocol
we
can't
safely
extend
the
match
conditions
that
are
passed
around
in
the
protocol.
I
The
fields
are,
in
many
cases,
type
value
rather
than
type
length
value.
This
is
perhaps
a
general
lesson
for
ietf
that
if
you
have
a
binary
serialization
of
stuff
stick
the
tlv.
You
know
that's
gonna,
be
the
best
answer,
no
matter
what
this
is
sort
of
unfortunate,
because
there's
been
a
lot
of
interest
over
the
last
several
years
about
extending
flow
spec
for
various
things
and
that
we
have
things
like
flow
spec
for
layer
two.
We
have
full
spec
for
other.
I
You
know
types
of
overlay,
underlay
and
tunnel
type
situations
happening
and
we're
also
seeing
that
people
are
finding
our
encodings
useful
for
other
things.
Like
psep,
for
example,
has
I
decided
to
leverage
the
flowspec
nlr
encodings
for
encode
for
putting
together
firewall
rules?
We're
also
seeing
like
that
net
is
having
interest
in
making
use
of
it
for
their
purposes,
we're
expecting
to
see
that
flowspec
v2
is
going
to
be
there
to
try
to
solve
some
of
these
problems.
That
initial
work
is
being
kickstarted
by.
I
You
know,
sue
harris
and
donald
eastlake,
so
we'll
be
having
some
interims
on
that,
hopefully
before
end
of
year,
and
the
idea
is
to
try
to
actually
get
that
done
at
a
fairly.
You
know
quick
pace,
because
the
core
of
the
technology
is
understood,
but
the
needs
for
future
encodings
is
necessary.
I
So
another
thing,
that's
of
interest-
is
that
we're
starting
to
see
a
lot
of
cross-working
group
and
area
bleed
over
for
various
technologies.
You
know
what
are
the
ones
that's
impacting
rdr,
specifically,
is
a
lot
of
multicast
related
things.
The
working
group
chairs
for
best
and
idr
are
talking
about
how
we
can
best
coordinate
this
sort
of
things
with
some
help
from
the
ads.
The
answer
is
we
don't
know
what
this
really
looks
like?
I
We
don't
have
strong
process
and
ietf
to
you
know,
govern
this
sort
of
thing,
so
I'll
be
figuring
out
partially,
as
we
go
along
minimally.
What
we
expect
to
see
is
we'll
be
building
up
a
manifest
of
the
various
documents
that
are
interacting
and
then
trying
to
get
them
tracked
in
a
single
place
where
everybody
can
see.
What's
going
on
and
very
likely
trying
to
find
some
interesting
interested
parties
that
want
to
help
with
the
coordinated
effort.
I
Another
piece
of
work
that
we
have
going
on
is
that
we
have
auto
configuration
for
bgp,
there's
been
sort
of
no
stumbling
around
for
the
last
couple
years.
We're
making
some
steady
progress
on
it.
The
design
team
requirements
document
is
complete,
we've
been
discussing
and
re-reviewing
the
existing
proposals
for
the
protocol.
I
I
So
we're
also
making
progress
against
the
b2b
yang.
Unfortunately,
part
of
the
headache
we're
running
into
is
that
over
the
very
strange
lifetime
of
this
document
you
know
we've
effectively
steadily
merged
in
all
of
the
idr
chairs,
along
with
bahesh
and
we're
all
very
busy
on
our
various
other
things.
So
we
haven't
made
as
good
as
forward
progress
as
we
would
have
liked.
I
Now
we
we
do
have
this
being
tracked,
largely
in
mahesh's
github.
You
know
if
this
were
the
current
day.
Stuff
we'd
probably
move
it
over
to
the
ietf
one,
but
you
know
this
is
where
it
currently
lives.
You're,
welcome
to
go
there
and
look
at
the
issue.
Tracker
and
you
know,
participate
with
us
if
you'd
like
the
work
began
with
the
open
config
model
and
has
been
steadily
getting
altered,
basically
to
suit
more
ietf
purposes.
I
Open
config
is
much
more
targeted
use
cases
for
the
operators,
whereas
the
ietf
agenda
is
that
we
have
to
have
much
more
broad
coverage
in
terms
of
what
components
we're
willing
to
service
and
what
our
extensibility
models
look
like,
and
the
phases
of
this
work
you
know
will
be
familiar.
Anybody
has
done
a
very
large
gang
module
and
especially
one
that's
interacting
with
a
lot
of
stuff.
You
know
the
first
phase
of
just
simply
making
sure
all
the
contents
in
there.
We
think
that's
done
there.
E
I
Certain
features
that
we're
not
intending
to
put
in
there,
you
know
bgp
being
a
protocol
with
many
extensions.
We
can't
put
everything
in
the
the
core
document,
but
you
know
what's
core
not
core
is
a
point
of
debate
depending
on
the
vendors,
the
restructuring
and
cleanup
of
the
structure
for
the
contents,
and
the
features
is
largely
done
as
well.
I
This
has
been
important
for
things.
You
know
what
we're
generally
calling
interwork.
Now
we
have
things
like
policy,
our
interactions
with
the
routing
config
module,
the
use
of
components
like
bfd,
and
you
know
this
ties
into
the
sort
of
flip
side
of
things.
Not
only
we
need
to
be
able
to
use
all
these
external
components.
I
The
bgp
work
is
going
to
be
heavily
reused
by
other
things,
so
you
know
our
various
rib
modeling
a
lot
of
our
data
structure.
Type
things
like
extended
communities
all
have
to
be
put
into
structures
so
that
they
can
be
imported
into
other
modules
without
a
huge
amount
copy
and
paste,
and
we
have
to
be
very
clear
about
what
our
ion
maintenance
looks
like
for
things
and
as
a
particular
example.
Maintaining
the
extended
community
stuff
is
going
to
be
a
very
interesting
challenge,
we're
hoping
to
get
this
stuff
done
by
end
of
the
year.
I
You
know
in
terms
of
the
full
content
and
then
hopefully
move
forward
to
itf
sorry
working
with
last
call
by
spring
next
slide.
Please.
A
That's
it.
That's
your
last
slide
for
idr
any
questions.
A
I
Okay,
bfd
is
both
a
little
bit
easier
and
more
interesting
problem
at
the
end.
Here
the
work
group
is
quiet.
I
You
know
you
know,
greg
was
greg,
mercier
was
encouraged
to
take
the
bfd
protocol
and
taking
a
plumbing
that
might
be
interesting
for
non-core,
use
cases
for
bfd
and
take
it
off
the
routing
working
group,
and
we
saw
the
presentation
of
that.
I
think
last
iatf,
and
this
means
a
lot
of
the
turn
of
no
new
things
going
to
bfd
has
slowed
down
a
little
bit
so
we're
mostly
focusing
on
driving
existing
work
to
completion.
I
We
have
a
document
that
is
basically
for
one-sided,
bfd,
no
example
b2b
or
static
next
hops.
That's.
I
Going
to
be
moving
off
to
isg
publication
very
shortly,
we
have
a
feature
that
allows
us
to
leverage
bfd
echo
type
procedures
without
actually
having
bfd
present.
This
originally
came
to
us
by
a
broadband
forum,
and
we
have
some
interested
people
that
are
wanting
to
do
a
cleaner,
ietf
document
for
this,
and
that
will
hopefully
also
hit
working
with
last
call
soon.
I
There's
a
feature
for
bfd
to
send
large
packets
to
basically
do
mtu
probing.
The
core
protocol
was
mostly
done
for
async
mode.
We've
had
a
request
to
integrate
some
echo
mode
as
well,
so
that
work
still
needs
to
happen,
and
the
last
cluster
of
things
that
we
had
in
the
open
work
was.
We
had
three
features
intended
to
make
authentication
both
more
usable,
lighter
weight,
faster
and
some
extent
more
secure.
I
At
the
moment,
it's
dated
on
a
specific
feature
document
that
needs
some
help
from
ellen
decock
who's
volunteered
to
help
us
with
finding
some
lightweight
hashes
how
we
can
integrate
the
bfd
and
once
that's
actually
been
cleared
through
and
probably
skip
that
cluster,
very
quickly,
bfd
being
a
plumbing
protocol.
A
good
chunk
of
what
we
actually
see
is
work,
that's
happening
in
other
working
groups.
You
know
bfd
being
used
for
x
purpose.
I
You
know,
and
the
working
group
exists
for
vfd
partially
to
help
with
review
for
those
other
proposals,
so
we're
expecting
to
see
reviews
come
in
sometime.
You
know
over
the
next
couple
months,
since
a
lot
of
these
individual
proposals
seem
to
also
be
close
to
their
own
working
group.
Last
calls
next
slide.
Please.
A
Before
we
go,
there,
greg
is
in
the
queue
greg.
Do
you
want
to
say
something
about
this
slide.
F
I
Yeah,
the
impression
I
have
is
that
bpf
does
not
want
to
be
in
the
business
of
standardizing
bfd,
but
tr
146,
which
was
the
very
loosely
worded
proposal
they
had,
is
pretty
well
implemented,
as
I
guess
in
you
know,
bbf
users.
So
having
this
cleaned
up,
an
ietf
seems
like
it
is
a
good
idea
and
minimally
doesn't
hurt.
I
Okay,
greg
is
no
longer
the
queue,
so
the
thing
that's
been
keeping
unfortunately
way
too
many
of
our
lives.
Busy
bfd
has
a
yang
module
that
just
finished
rfc.
Well,
that's
yay.
We
actually
got
that
done
being
a
plumbing
protocol.
You
know
bfd
was
sort
of
an
interesting
position.
Much
like
the
routing
config
module
policy
module
a
few
other
modules.
I
That
we've
had
you
know
very
back
in
the
early
design
days,
is
we're
going
to
have
a
bfd,
sorry
yang
grouping
that
allows
us
to
have
a
common
configuration
experience
for
bfd
that
was
under
the
client,
config
perms,
and
this
our
challenge
that
we
have
now
with
being
ietf
we're
intended
to
be
largely
vendor
neutral
when
we
can
model
things
in
a
neutral
way.
I
We
should
and
bfd
has
two
standard
ways
of
being
configured:
first,
one's
a
centralized
mode
where
you
have
sort
of
a
protocols
bfd
session,
where
you
configured
all
of
your
sessions,
your
parameters,
your
endpoints,
and
at
that
point
you
just
tell
your
clients,
you
know
bfd
is
enabled
for
know
this
particular
purpose.
So
it's
a
simple
binary
value.
I
I
The
problem
that
we
had
was
sort
of
realized
as
a
very
last
second
thing,
this
work
was
done
quite
some
time
ago.
The
rfc
happened
and
we
started
doing
our
audit
on
you
know.
Bgp's
use
of
things
see
prior
slide,
and
one
of
the
things
that
was
noted
in
the
tree
expansion
was
that
we
have
the
per
client
things
and
being
a
long
time
since
we
actually
worked
on
it.
I
I
couldn't
remember
what
we
actually
did,
so
I
pushed
the
panic
call
button
off
to
know
the
other
documents
that
were
impacted
by
the
bfd
rfc,
which
are
currently
in
queue
which
are
ospf
tim
and
isis,
and
after
going
through
the
panic,
we
did
eventually
dig
up
the
old
details
of
the
conversation.
I
Trouble
is
no
sense
that
the
conversations
happened.
The
desire
of
ietf
to
do
this
sort
of
thing
by
deviations
has
gone
away
so
we're
the
process
of
trying
to
see
if
we
can
actually
cleanly
patch.
In
you
know,
the
use
of
the
yang
feature
modality
and
that
allows
us
to
sort
of
cleanly
support
it
without
requiring
an
individual
vendor
to
ship
out
a
deviation
set.
Now
this
is
part
of
the
netcount
protocol.
You
know
in
terms
of
what
features
you
support
and
it's
a
cleaner
way
to
do
things.
I
What
this
is
required
is
some
discussion
among
the
bfd
authors,
the
yang
doctors
and
such
primarily,
because
we
would
be
making
a
change
to
the
published
9127,
but
it's
just
gone
out
the
door.
A
few
you
know
weeks
ago,
we're
not
expecting
anybody's,
actually
implemented
100
of
things
and
the
proposal
that
we're.
Having
is
that
you
know
just
simply
add
if
feature
to
the
impact
decline,
configs
update,
9127
and
no
changes
are
required
by
the
impacted
modules.
I
So
this
has
been
an
interesting
lesson
in
getting
this
stuff
right
for
cross
module
use
is
challenging
and
what
the
maintenance
challenges
are
going
to
be.
Didn't
intend
to
push
this
as
a
test
case
so
early
in
this
process,
but
now
we
have
there,
we
have
it,
and
that
said,
we
apologize
to
all
impacted
modules.
You
know,
for
you
know
the
you
know,
basically
shaking
the
tree
so
early.
A
I
can
hear
me
now:
yep
we
can.
We
are
sort
of
running
out
of
time,
so,
okay
working
groups,
thanks
in
that
case
next
slide.
L
L
L
L
L
There
has
been
some
discussion
on
what
how
this
is
going
to
be
implemented
on
the
writer's
side.
L
There's
one
one
of
the
spec:
that's
trailing
behind
and
that's
sort
of
an
alternative
to
the
the
div
surf
aware
approach,
which
is
in
the
in
the
drafts
currently
under
art
review,
and
that's
where
you
use
the
802.
L
L
However,
I
think
the
radio
band
thing
is
useful.
In
my
personal
view,
I
expect
working
group
adoption,
at
least
of
that
one,
maybe
also
the
general
utilization.
The
radio
quality
is
more
iffy,
but
that's
largely
based
on
the
views
of
very
few
people,
and
we
need
to
have
more
reviews
and
that's
a
general
problem
getting
people
to
to
review
other
other
people's
drafts
next
slide.
L
Please,
then,
there
are
some
things
that
are
on
our
charter,
our
current
charter,
that
we
should
be
working
on,
but
that
network
is
not
actually
happening
at
the
moment.
One
of
the.
L
L
There's
also
a
charter
item
on
management
of
manage
and
how
this
is
different
from
your
standard
management
in
the
in
the
face
of
frequent
split
submerges
of
your
network,
and
actually
we
are
eyeing
the
asynchronous
management
architecture
or
it
will
have
a
new
name,
but
this
is
being
presented
right
in
the
next
time
slot
to
the
money
weapon
group
by
edurane
who
has
sort
of
invented
this.
L
Then
we
still
have
a
responsibility
for
the
maintenance
of
olazar
v2.
Maybe
not
everybody
knows
it,
but
in
addition
to
isis
and
ospf
there
is
a
third
standards
track
link
state
protocol
in
the
itf.
It's
called
osr
optimized
link,
states,
writing
and
it's
for
manage,
of
course,
and
we
ran
into
a
a
practical
issue
original
some
large
interoperability
event
where
there
was
a
problem
with
routers
rebooting
and
then
being
unable
to
join
the
network.
L
Again,
there
are
some
ideas
on
how
to
solve
that,
not
by
a
protocol
change
but
by
some
practical
guidance
on
configuration,
and
it
would
be
good
to
write
it
up
and
furthermore,
there
is
a
back
to
the
app
again.
There
is
a
need
or
perceived
need
to
write.
Some
implements
guidance
or
clarification
document.
However,
the
people
best
place
to
do
this
at
the
moment.
Don't
have
the
time
right
now,
so
we're
looking.
A
Thank
you,
ronald
we're,
gonna
we're
pretty
much
out
of
time.
We're
gonna
skip
the
questions
because,
as
ronald
said,
his
working
group
is
meeting
in
the
next
slot.
So
please
join
we're
gonna
stay
here
for
another,
maybe
10
minutes
to
cover
the
last
two
working
groups.
So
if
you
guys
can
please
stay,
that
will
be
great
dominique
go
ahead.
M
M
D
M
Ram
and
networks
such
as
low
power
radios
with
data
rates
in
the
100k
bits
per
second
and
up
that
could
be
radios,
can
be
also
power
line.
Communication
wrong:
oh
yeah,
great!
Thank
you.
So
that's
the
kind
of
networks
we're
interested
in
and
the
use
cases
are
smart
metering,
smart
cities,
smart
buildings,
factory,
floor
automation,
etc.
M
D
M
Adaptation
for
low
low-power
nurse
networks,
lightweight
implementation
guidance.
You
know
profiling
protocol
stacks
for
implementation
on
constrained
devices.
Six
dish
is
a
synchronous,
mesh
network
of
ieee,
15.4
radios,
raw
animal,
etc.
Next
slide,
please.
D
M
M
We
strive
to
have
minimum
control
traffic
and
we
achieve
that
by
several
means.
For
example,
if
we
only
do
collection
going
up,
so
we
don't
nodes
that
don't
need
to
be
destinations,
don't
even
advertise
themselves
in
the
in
the
topology
and
also
we
slow
down
the
control
traffic.
It's
the
topology
stable
using
a
tricular
algorithm,
so
the
the
network
goes
quiet.
If,
if
everything
is
stable,
so
that
was
a
base
flavor
of
ripple,
then
we
added
multicast.
We
added
optimize,
optimized
point-to-point
routing
across
the
the
dark
structure.
M
We've
also
looked
at
compression
we're
still
looking
at
compression
of
the
routing
headers,
because
six
slow,
six
lupine
provides
compression
of
the
headers
of
the
data
packets,
but
the
routing
control
packets
still
convey
prefixes
and
addresses,
and
we
want
to
compress
ipv6
addresses
that
we
want
to
compress
next
slide
please.
M
So
that
was
the
background
and
now
what
we're
doing
is
okay,
I'll
to
be
safe
on
time
I'll
just
pick
the
reactive
point-to-point
flavor
of
ripple
using
an
aodv
algorithm
which
allows
to
do
reactive
routing,
as
opposed
to
the
proactive
of
the
original
version.
M
We
are
also
working
on
projecting
routes
into
the
network
in
when
we
have
routing
tables
from
a
central
controller,
and
that
entails
adding
control
messages,
adding
options
to
be
able
to
detect
the
radio
links
that
are
available
to
build
a
topology
that
is
not
aligned
to
the
dag
structure.
Next
slide,
please.
M
We
have
some
other
work
ongoing,
selecting
parents
up
the
dag
such
that
they
have
good
properties
like
they
have
common
grandparents
that
allows
to
set
the
the
path
for
doing
packet,
replication,
elimination
along
parallel
paths
to
the
root
to
add
redundancy
and.
M
A
Thank
you
dominic.
So
we
are
way
over.
Ac
is
up
to
you
and
chris.
If
you
want
to
go
over
or
if
you
want
to
leave
this
for
the
next
atf
as
it's
being
discussed
in
the
chat,
the
slides
are
going
to
be
posted
anyway,
since
the
data
tracker,
if
people
want
to
go,
take
a
look
at
that.
D
C
This
is
you
know,
lsr
is
the
merger
of
the
former
ospf
and
isis
groups.
We
realized
we
were
doing
a
lot
of
common
things
together
and
brought
them
together.
It's
it's
ospf,
v2
and
which
is
main,
which
is
only
for
I
limited
to
ipv4,
and
then
we
got
isis,
which
is
a
dual
stack
protocol.
We
got
ospf
v3,
which
also
is
a
dual
spec
stack
protocol
and
with
the
extended
lsa
extensions,
it's
now
completely
extendable.
C
C
One
of
the
main
things
we've
been
working
on
for
the
last
few
years
is
segment
routing.
We
have
it
for
both
the
mpls
data
stream
and
the
srv6
data
stream.
It
has
all
the
signaling
for
all
the
different
types
of
sids,
as
well
as
how
routes
are
computed
with
those
sets
we're
pretty
much
done
with
mpls
the
srv6
we
have
drafts
for
those.
The
isis
is
almost
done.
There's
some
work
on
implementations
for
ospf
v3,
and
it's
there's
disagreement.
It's
being
held
off
it,
but
hopefully
by
the
next
ietf.
C
We'll
have
ospfv3
done
as
well.
Next
slide
flex
algorithm.
This
is
pretty
exciting
work
and
it
it
really
allows
you
to
dynamically
define
constraints
based
on
a
lot
of
initially
it'll,
be
different
types
of
metrics
different
admin
groups.
In
other
words,
those
are
like
srlg
groups
for
different
routes,
so
you
could
effectively
have,
depending
on
prefix,
multiple
planes.
Now,
what's
really
nice
about
this,
is
you
can
do
different
algorithms
for
different
prefixes?
C
Yet
you
only
have
to
have
one
for
forwarding
play,
whereas
in
the
past
you
know
some
of
the
other
things
where
you're
doing
different
things
in
different
for
different
topologies
like
mtr,
which
I'm
not
saying
the
two
are
the
same,
but
you
had
you
know
most
people
implemented
with
different
fibs,
and
so
it's
it's
a
pretty
pretty
pretty
powerful
thing,
and
now
that
we
have
this
we're
having
proposals
to
add
constraints
based
on
bandwidth
and
other
constraints,
so
you
could
for
different.
C
As
long
as
you
have
a
different
endpoint
associated
with
a
different
application,
you
could
do
a
lot
of
the
stuff
they're
talking
about
in
the
apn
discussions
for
different
applications.
It
supports
both
segment
routing
paths,
and
now
we
have
proposals
for
native
ipafs
next
slide
flooding
optimizations.
C
One
thing
we
found
is
the
igps
have
been
very
redundant
in
their
flooding.
You
flood
on
all
interfaces
except
the
one
you
received
on
basically,
and
we
decided
people
have
had
there's
been
proprietary,
extensions
to
block
flooding
on
certain
interfaces
for
years
and
years,
and
it's
just
kind
of
and
there's
also
an
isis
has
had
a
mesh
group
where
you
only
flood
to
you
know
you
don't
flood
to
everybody
in
the
mesh
group,
and
now
everybody
realized
that
you
could.
C
So
we
have
both
centralized
and
distributed
calculation
of
this
of
us
of
a
sparser
flooding
tree
and
that's
that's
one
set
you
know
of
disseminating,
which
you
know
either
the
topology
or
which
algorithm
is
being
used
to
calculate
the
topology
and
distributed
faction.
C
Also,
we
have
some
proposals
for
area
abstraction
so
that
you
could
take
a
piece
of
your
topology
and
completely
abstract
it
and
there's
we're
we
have
ospf
ttc,
ttz,
trent,
topology,
transparent
zone
and
we're
working
on.
We
have
isis
topology
transfer
parent
zone,
and
now
we
have.
We
also
have
a
I
hate
to
say
it,
but
it
seems
like
a
more
straightforward
to
do
it
way
to
do
it
with
area
proxy.
That's
a
little
bit
simpler.
C
We
also
have
you
know
in
bgp
many.
You
are
familiar
with
the
route
reflector.
C
We
have
a
proposal
to
limit
the
number
of
adjacencies
over
which
you
have
to
you
know
establish
within
an
area
with
the
sort
of
like
a
equivalent
to
a
route
reflector,
I
mean
there's
a
lot
of
different
things
when
you're
doing
it
with
a
link
state
protocol,
then
with
bgp,
but
that's
also
some
inter
very
interesting
work.
And
finally,
we
have
flooding
speeds.
Optimization.
C
The
old
iso
specs
for
isis
limited
severely
limited
the
number
of
lsps
link
state
protocol
pdus.
You
could
flood
over
an
interface
in
a
certain
and
say
a
second,
and
we
have
ways
of
getting
feedback.
Both
explicit
feedback
in
the
form
of
protocol,
encoding
and
feedback
from
the
network
in
in,
in
other
words,
how
fast
the
receiver
of
the
lsps
is
acting
them
to
improve
this
speed
and
be
able
to
do
higher
speed,
bursts
and
everything
and
and
really
speed
up
the
protocol
for
some
of
the
bigger
domains.
C
Next
slide
protocol
maintenance-
I'm
not
going
to
say
much
more
here,
we're
just
you
know.
There's
a
lot
of
people
want
to
put
things
into
the
igp's
apple
at
the
node
link
and
prefix
layer,
and
we
have
to
decide
basically
does
this
really
belong
in
the
igp
igp
as
an
underlay
for
all
the
overlay
protocols,
be
it
bgp,
you
know
ib
gp,
be
it
list,
be
it
proprietary
protocols
that
use
you
know,
use
use
the
igp
as
underlay,
it's
pretty
critical
that
it
work.
Well.
So
we
we
we
look
at
these.
C
We
look
at
the
volume
and
the
frequency
that
it
changes
and
we
have
other
ways.
Unfortunately,
we
have
really.
We
have
other
ways
to
do
flooding
of
non-routing
information
in
separating
instances,
but
people
aren't,
we
really
haven't
gotten
those
deployed.
We
have
the
standards,
but
not
deployment
and.
C
We
have
I
we
have
sometimes
a
lot
of
enhancements
to
the
basic
protocol
like
there's
a
there's
like,
for
instance,
this
isi
support
for
additional
layer,
additional
levels
of
hierarchy
right
now,
both
ospf
and
isis
support
two
levels.
You
know
like
effectively
a
backbone
in
non-backbone
areas,
but
this
is
for
multiple
layers
of
hierarchy
with
the
lower
level
completely
subsumed
by
the
layer.
Above
it
last
slide,.
D
Yeah,
I
want
to
throw
in
something
use
this
opportunity
to
try
to
attract
some
attention
from
other
groups.
Back
two
slides
ago,
when
ac
mentioned
the
flooding
speed,
optimization,
that's
congestion,
control
right,
so
people
interested
in
congestion
control.
You
know
from
over
in
the
transport
area,
basically
tcp
right,
we're
trying
to
get
max
well,
I'd
like
to
see
maximal,
and
I
think
other
people
are
trying
to
get
maximal
flooding,
speed
right
to
maximally
use
these
these
links
to
flood.
D
So,
if
that's
interesting
to
you
pop
over,
it's
not
just
igp,
this
is
kind
of
some
cool.
You
know
crossover
stuff,
that's
it.
C
Last
slide,
of
course,
we
got
the
la
yang
models
and,
as
jeff
covered
in
excruciate
jeff
haas
covered
in
excruciating
detail.
We're
just
waiting
for
this
one
bfd
issue
to
be
resolved
where
we
didn't
want
to
ship
a
model
that
would
require
the
predominant
implementations
to
have
dv
to
have
a
deviation
for
every
instance
of
bfd
configuration,
and
then
we
got
we
got
drafts
for
all
the
other
things.
We
talked
about
on
the
previous
slides
for
augmentations
to
the
base
ospf
and
isi,
seeing
models.
A
Well,
so
we
don't
delay
anyone
anymore.
Thank
you
and
we'll
see
you
hopefully
in
person
next
time
somewhere
in
europe,.