►
From YouTube: IETF-RTGAREA-20220201-1600
Description
RTGAREA meeting session at IETF
2022/02/01 1600
https://datatracker.ietf.org/meeting//proceedings/
D
E
C
D
C
B
B
B
B
If
we're
at
a
point
where
we
can
start
that
discussion
and
jeff
haas
is
going
to
talk
about
a
I'm
going
to
say,
discovery
protocol
and
he's
going
to
show
some
slides
we're
going
to
go
from
there
and
have
a
discussion
in
here,
but
because
before
we
start
all
that
you
already
saw
on
the
video
andrew
olson,
who
is
now
offline.
So
all
that
400
gig
times
for
massive
bandwidth
didn't
work.
C
C
B
D
Okay,
it
should
be
fairly
short
at
the
last
iatf.
We
had
a
suggestion
that
that
had
come
out
of
the
sort
of
joint
planning
with
the
iab
and
iesg
about
you
know.
Let's
please
remind
our
our
participants
that
you
know
the
note
well
is
not
just
about
ipr.
It's
also
about
maintaining
a
civil,
or
sometimes
people
say
professional.
D
D
We
are
all
adults
here
and
sometimes
we
use
adult
language,
but
different
adults
are
comfortable
around
different
kinds
of
adult
language,
and
so
it's
it's
sort
of
almost
embarrassing
to
me
to
say
that
we
should
probably
try
to
keep
locker
room
language
off
the
mic,
but
I
think
that
we
should,
because
you
never
know
who's
going
to
be
made
uncomfortable
by
that,
and
I
think
that's
you
know
that's
fair.
We
we
shouldn't
say
you
have
to
be
comfortable
with
swearing
in
order
to
participate
in
the
ietf.
D
D
D
D
F
Yes,
okay,
sorry,
I
think
in
the
past
we
we
touched
a
little
bit
the
shepherding
part,
and
I
think,
if
I
remember
correctly,
we
discussed
that
it
would
be
a
really
good
practice
if
we
assign
shepherding
or
shepherds
to
the
documents
actually
before
the
last
call
actually
helping
in
polishing
the
the
document,
because
we
complained
a
lot
in
the
past
about
the
fact
that
documents
get
out
from
the
working
group
and
the
quality.
Some
sometimes
is
not
the
best
with
even
like,
like
still
sections
market,
to
be
done,
and
something
like
that.
F
D
D
Yeah,
I
I
guess
a
related
point
is
just
I
mean
on
the
subject
of
shepherd
recruitment.
I
know
that
it's,
you
know
very
common
for
chairs
to
just
take
on
the
shepherding
job
themselves,
and
I
I
just
want
to
point
out
that
it
you
know
it
is
a
useful
way
or
potentially
useful
way
to
bring
people
into
the
process
is
to
say:
oh
you
you
want
to
become.
D
D
So
you
know
a
point
to
consider
especially
sort
of
in
tandem
with
the
oh
you're
interested
in
in
being
involved
shepherd
something
for
me
and
by
the
way,
maybe
do
it
during
the
or
prior
to
the
working
group.
Last
call.
Okay,
thank
you.
That's
it
for
my
topic.
Unless
anybody
else
wants
to
contribute
a
comment.
B
G
G
I
blame
microsoft
for
much.
We
don't
have
enough
time
for
that.
Okay,
so
what
is
this?
This
is
a
request
for
some
generalized
discussion
and
you
know.
Maybe
this
will
lead
us
to
a
buffer
or
something
else,
or
maybe
somebody
will
just
say
this
is
a
solved
problem.
No,
we
don't
need
to
do
anything
here,
one
of
the
things
that
I've
been
seeing
over
the
course
of
sets
in
my
work.
G
Much
of
it
bgp
is
that
we
have
some
need
for
what
I'm
going
to
be
calling
a
generalized
capability
discovery
tool,
and
you
can
swap
the
word
capability
for
feature
what
you
think
about
such
things,
I
think,
depends
on
what
technology
suite
you're
sitting.
Inside
of
so
what
do
I
consider
the
problem?
G
I
think
that
one
of
the
headaches
we
have
to
deal
with
regularly,
especially
as
our
technologies
continue
to
mature
and
add
new
stuff,
is
that
incrementally
deploying
new
features
is
challenging
in
a
network
yeah.
We
all
know
this.
We
try
to
avoid
flag
days
and,
as
a
consequence,
we
have
you
know
portions
of
our
network
that
do
or
do
not
support.
G
You
know
some
new
capability,
some
new
feature
and
part
of
the
problem
is,
you
know,
what's
sort
of
the
minimal
threshold
to
get
something
deployed,
you
know
whatever
your
definition
of
deployment
means
and
for
technologies
that
require
you
know,
sets
of
boxes
to
be
connected
together,
supporting
the
same
feature
to
get
this
job
done
now.
Do
you
know,
are
these
boxes
actually
connected
in
such
a
way
and
if
they
require
interaction
with
external
devices
like
a
controller,
especially
for
programmed
cases?
G
Does
the
controller
have
sufficient
visibility
into
what's
going
on
the
network
to
get
this
job
done
so
very
clearly,
routing
protocols
have
a
lot
of
the
stuff
that
we're
looking
for
now.
We
do
see
this
in
a
lot
of
protocols
in
terms
of
what
they
do
for
incremental
deployment,
but
the
more
generalized
case
isn't
necessarily
dealt
with
as
part
of
that
and
programming,
I
think,
is
you
know
one
of
the
key
things
that
leads
us
to
the
problem,
but
it's
certainly
not
alone
picking
two
easy
use
cases.
G
Maximum
segment
death
depth
was
a
bit
of
discussion
that
we
had,
which
led
to
two
very
simple
rfcs.
You
know
the
general
idea
there
is,
if
you're
using
technology
for
no
steered
traffic,
maybe
using
mpls
your
label
stacks
can
be
the
tool
that
you
want
to
get
the
job
done.
But
since
many
devices
don't
support
arbitrary
depth
for
a
label
stack
well
that
becomes
problematic.
G
Now,
how
do
you
know
if
you
can
steer
something
through
a
specific
node
in
your
network
if
it
has
a
limited
stack
depth
and
what
is
that
depth
and
knowing
what
that
is
at
some
point
in
the
network?
Maybe
you
can
adjust
your
technology
to
do
the
appropriate
thing,
I'm
having
a
specific
example
of
this
sort
of
headache
with
php
flowspec,
even
the
sort
of
very
boring
core,
rfc
type
stuff,
isn't
100
supported
in
some
cases.
So
the
easy
example
of
that
is
a
lot
of
implementations.
G
Well,
it
means
that
since
flow
spec
has
implicit
rule
ordering,
if
you
don't
support,
match
kind
of
field
or
it
ignores
matching
in
the
field.
Your
filtering
intent
may
not
be
done
as
you
expect,
and
that
can
result
in
things
like
the
traffic
getting
thrown
away.
Because
of
you
know
how
flow
spec
is
being
deployed,
or
maybe
that's
intended
to
be
your
safety
bar
and
stuff.
G
That's
allowed
the
pass
through
based
on
given
the
scp
may
not
be
getting
handled
and
we're
starting
to
see
that
headache
creep
up
as
we're
starting
to
add
new
flow
spec
features.
We've
been
sort
of
on
pause,
as
we've
been
doing,
the
update
to
the
original
flow
spec
rfc
and
that
work
is
starting
to
creep
forward
again
so
easy
example,
my
employer
has
a
feature
that
allows
us
to
filter
on
the
contents
of
packets,
rather
than
just
simply
the
header
fields.
Well,
what
happens
in
your
deployment
if
your
devices
don't
consistently
support
this?
G
G
Now
we
do
have
mechanisms,
for
you
know
what
we
need
is
mechanisms
to
discover.
You
know
the
devices
how
they're
hooked
up
together
where
their
capabilities
are-
and
you
know,
as
we
all
know,
routing
protocols
do
a
lot
of
this
stuff
for
us
already,
depending
on
you
know
their
flavor
and
picking
easy
example.
G
Igps
are
usually
in
an
excellent
position
to
share
a
lot
of
this
type
of
information.
You
know
they
have
here's
the
device,
here's
the
topology
that
they're
hooked
up
into-
and
you
know
the
protocols
are
very
extensible.
You
can
stick
more
and
more
stuff
in
there,
which
means.
Theoretically,
you
can
just
sticky
note
all
of
your
appropriate.
You
know
capability
information
in
there
that
could
be
carried
across
your
entire
network,
but
there's
a
very
obvious
reluctance
to
try
to
do
that
because
it
overloads
the
igp
itself
and
sort
of
degrades
its
core
use
case.
G
Picking
a
different
example:
bgbls
does
a
lot
of
the
same
sort
of
things
that
the
igp
does
different
encodings
has.
The
advantage
that
can
be
inter-domain
has
some
of
the
same
encoding
overheads
that
igp
does.
But
the
nice
thing
is
it's
not
an
igp.
We
do
have
the
flexibility
to
stick
more
things
in
there
and
you
know
we
have
a
lot
of
opportunity
to
use
that
as
an
extensible
thing,
and
this
is
not
to
say
that
phblos
is
the
answer.
G
It
was
just
a
useful
talking
point
about
stuff
that
we
do
have
that
can
potentially
be
repurposed
there.
So
the
question
becomes.
What
do
we
need?
Is
it
one
of
our
existing
solutions
know
for
this?
Do
we
need
something
brand
new,
or
maybe
this
isn't
really
a
problem?
It's
just
all
in
my
head.
This
is
where
I
pause
and
open
up
the
discussion.
H
One
of
the
reasons
you
know
we
we've
done
this
is
because
it
rides
on
top
of
all
the
machinery
in
the
routing
protocols
right
and
the
secure.
You
know
the
securities
there
everything's
there,
so
I
don't
think
inventing
something,
I'm
not
saying
whether
we
should
limit
this
to.
You
know
one
way
of
doing
it,
but
I
don't
know
that
I
would
think
some
inventing
something
new
would
be
a
good
idea.
G
G
We
can
certainly
add
one
there's
a
lot
of
pressure
to
maybe
do
it
in
existing
technologies,
and
I
think
the
concern
I
have
is,
if
you,
if
you
push
to
use
an
existing
technology,
you're
also
running
into
the
politics
with
the
technology
yeah
just
pick
up
the
igps
just
because
you're
the
speaker
now
we
we've
seen
this
conversation
over
and
over
again
of
this
is
a
cool
thing
to
do.
But
please
don't
stick
this
in
igp.
It
doesn't
help
the
core
use
case.
So
we
keep
on
running
into
these
sort
of
mismatches.
G
C
Yeah
so
from
my
perspective,
look
we
use
a
lot
of
bgpls
a
lot
and
it
does
seem
to
me
that
ls,
if
you
could
find
a
way
to
get
information
into
it,
would
be
a
very
good
place
to
put
this.
The
problem
then
becomes:
how
do
you
get
the
additional
information
into
ls
and
particularly
because
the
ls
deployments
out
there
are
pretty
inconsistent
as
it
is
with
what
they
carry
in.
C
In
my
experience,
so
to
me
this
almost
seems
like
the
ideal
solution
would
be
to
use
ls
we
needed
to
distribute
you
know
into
domain
or
whatever
else,
but
then
you
still
need
a
mechanism
to
get
the
stuff
into
ls
and
you
don't
want
loads
and
loads
of
ls
speakers.
So
it's
got
to
be
distributed
somehow,
and
I
think
that
to
me
is
where
it
comes
down
to,
because
the
ls
makes
sense.
But
how
do
you
get
it
in
there
and-
and
that
is
kind
of
my
sticking
point.
G
Yeah,
I
totally
agree
with
that
and,
of
course
us
has
its
own
sort
of
standalone
use
cases,
so
you
know
for
some
networks,
people
might
object
to
having
all
those
extra
states
stuck
onto
the
beach
building
uri
that
carries
around
the
stuff
for
ls,
but
one
of
the
nice
things
about
bgp,
at
least
for
this
type
of
use
case,
it's
possible
to
have
multiple
instances
of
the
stuff
running
that
don't
necessarily
cross
with
each
other.
You
know
as
an
example
there's
a
vpn
flavor
bhpls.
G
That
would
let
us
have
basically
a
standalone
instance,
for
you
know
the
state
declaration
that
doesn't
have
to
live
in
the
same
use
cases
for
other
things
to
use
ls,
for
so
the
protocol
is
capable
of
handling.
That
again,
I'm
not
saying
ellis
has
to
be
the
answer,
but
I
guess
one
of
the
other
observations
here
is,
you
know,
maybe
an
indirect,
a
functional
point
that
needs
to
be
solved
as
we
work
on
this
thing.
If
we
decide
to
pick
up,
the
work
is
yeah.
G
G
Maybe
the
answer
is
we
have
all
these
things
that
are
used
to
pass
around
topology
like
ls,
we
have
basically
k
structure,
k,
values
that
we
want
to
attach
to
things.
Well,
maybe
the
functional
requirement
is.
We
need
a
way
to
glue
these
things
together.
So
it's
very
easy
to
get
a
streaming
version
of.
What's
the
capability
set
attached
to
the
network.
E
E
We
have
years
and
years
ago
demonstrated
one
can
take
the
igp
information
distribution
technology,
pull
it
out
of
the
igp,
even
create
some
collectors,
so
the
topology
doesn't
have
to
be
the
same
as
the
igp
topology
and
use
it
to
manage
information.
Now
the
problem
we
used
it
for
which
was
nhrp
turned
out
to
be
irrelevant.
That
happens.
E
E
E
G
H
H
H
We
do
have
a
completely
separate
mechanism
that
makes
use
of
of
of
of
the
igp,
but
it's
nobody's
been
really
interested
in
implementing
it.
I
mean
I
haven't
pushed
that's
why
I
haven't
pushed
it
forward.
It
actually
even
supports
the
concept,
because
you
don't
need
it.
It
has
nothing
to
do
with
forwarding.
You
can
even
support
remote
neighbors
without
tunneling,
and
then
you
see
you
could
have.
G
H
The
example
we
have
well
not
only
that
they
don't
want
to
use
something
they
want;
they
just
want
their
application.
Let's
just
put
it
in
the
both
the
router
capabilities,
which
is
you
know,
both
isis
and
ospf
have
those
and
just
for
this
one.
You
know
this.
This
is
this
is
this
is
something
everybody
needs
anyway,
and
people
have
said.
This
is
something
everybody
needs
when
it
turns
out
it's
just
a
few
select
routers
in
the
domain.
They
still
try
and
push
it
forward.
H
G
F
D
You
know.
Please
use
this
this
fully
generic
one.
Instead,
you
know
the
answer.
Is
you
know
it's
incredibly
unfair
that
that
you're
insisting
that
I
have
to
to
go
to
this
huge
amount
of
extra
trouble
to
to
get
this
new
protocol
implemented
and
deployed?
Whereas
you
know
everybody
who
came
before
me
didn't
have
to
so
there's
a
real
chicken
and
egg
problem
there.
D
The
second
kind
of
closely
related
one
is
touched
off
by
what
joel
was
saying
about.
You
know
it's
it's
relatively
easy
and
expedient
to
add
these
things
to
the
the
igp
or
or
again
to
pgp,
and
it's
kind
of
the
straw
that
broke
the
camel's
back
problem
that
we're
talking
about
right.
It's
like
every
now
and
then
it
gets
asserted
that
that
the
campbell's
back
is
going
to
be
broken
if
we
keep
putting
unrelated
but
but
easily
added
things
into
it
right.
D
I
remember
well
over
a
decade
ago,
it
was,
it
was
being
claimed
that
if
we
added
one
more
thing
to
bgp,
the
internet
was
going
to
stop
working.
It
hasn't
stopped
working
yet
and
we
haven't
stopped
adding
stuff.
But
the
the
argument
still
has
some
validity
and
final
point
is
that
I
think
we're
kind
of
talking
about
inventing
a
you
know
a
dump.
I
D
Protocol
right
a
a
message,
bus
for
everything
that
isn't
part
of
you,
know
core
ib,
igp
or
core
bgp,
but
still
needs
to
be
distributed
right
and
my
there's
a
little
bit
of
a
marketing
problem
with
that.
In
that
I
I
fear
that
people
may
react
to
that
as
like.
Well,
my
thing
is
important,
so
my
thing
should
go
into
the
igp.
D
My
thing
is
not
you
know.
The
dump
truck
protocol
is
for
unimportant
things,
so
so
none
of
these
are
insurmountable,
but
I
think
they're,
all
you
know,
kind
of
organizational
or
psychological
things
that
we
have
to
consider.
If
we're.
Actually,
you
know
wanting
to
make
progress
on
fixing
this
problem,
which
we
haven't
yet
agreed
that
we're
going
to
try
to
do,
but.
G
Exactly
the
whole
point
is
that
they
try
to
figure
out.
Do
other
people
see
this
as
a
problem
worth
solving
and
sort
of
hitting
andrew's
point
from
chat.
You
know,
telemetry
is
a
way
to
get
this
stuff
out.
Every
one
of
our
protocols
has
some
way
of
listing
out
its
optional
features.
That's
how
we
incrementally
deploy
our
individual
protocols,
but
right
now,
there's
no
way
to
basically
query.
You
know
all
the
nodes
in
your
network.
G
G
So
that's
that's
an
option,
but
it
again
goes
to
yet
another
protocol
in
the
mix
and
as
you're
sort
of
hitting
as
a
point.
Yes,
this
is
a
dump
dump
truck
protocol.
It's
intended
for
who
knows
what
it
has
a
use
case.
I've
given,
but
the
interesting
challenge
is
going
to
be,
I
think,
is
the
key
one:
the
ecosystem
problem.
If
I
have
a
bhp
implementation,
that's
probably
where
I'm
going
to
want
to
put
the
stuff
if
I'm
doing
igp
work,
maybe
that's
where
I'm
going.
To
put
it!
So
that's
why
I
leave
that.
G
G
So
I
feel,
like
the
questions
are
slowing
down.
This
was
not
intended
to
be
a
comprehensive
thing.
This
may
turn
into
something
like
a
buff.
If
we
decide
it's
a
worthwhile
problem
to
solve.
This
is
mostly
to
draw
your
attention
to
you,
know,
being
a
potentially
interesting
thing
and
you'll
go
from
there.
A
A
A
You
know
whether
it's
for
manageability
or
whether
it's
needed
form
from
a
security
perspective,
to
limit
how
or
to
limit
the
attack
surface
or
that
kind
of
stuff.
So
that's
as
a
contributor
and
then
got
me
thinking
as
a
you
know
whether
as
a
co-chair
or
you
know,
for
the
whole
area.
Is
that
a
question
we
should
be
asking
for
each
document?
Should
we
be
encouraging
it
or
do
we
not
care
or
that's?
Basically,
the
question
to
the
group.
A
H
H
I
know
a
lot
of
you
have
done
mostly
ietf
for
your
careers,
but
if
you've
ever
worked
for
a
vendor-
and
you
know
about
this
people
who
don't
do
any
commits,
they
keep
putting
additional
criteria
to
commit
a
change
or
a
feature,
and
all
these
things
and
the
thing
is,
everybody
ends
up
getting
exceptions
anyway,
because
they
don't
have
the
skills
to
do
that.
It's
too
big
a
it's
too
big
a
thing
rather
than
you
know,
dividing
it
and
conquering
it.
H
A
A
G
Idea
is
not
quite
to
the
point
of
having
its
first
full
version
done
for
the
bhp
model,
but
it's
getting
darn
close
once
that's
done.
It's
still
only
going
to
cover
a
core
set
of
the
features,
and
I
think
that's
pretty
much
true
for
most
of
the
big
protocols
that
we
got
modules.
For
you
know
I
don't
care
which
module
you
pick.
It's
probably
not
100,
covering
all
the
different
incremental
features
that
are
in
there.
G
So
this
partially
goes
to
the
question
of
what
do
we
do
about
all
those
gaps
now?
Is
it
expected
at
some
point,
the
working
group
picks
up
and
sticks
those
all
the
models,
optional,
extensions
and
that
moves
into
the
carry-through
piece
that
you're
asking
about.
If
you're
writing
a
new
feature,
should
you
require
them
to
actually
do
that
incremental
bit
of
no
work?
A
B
Alvaro
thanks
rashad,
so
I
you
know
it's
hard
to.
You
come
up
with
one
answer
that
is
going
to
fit
everyone
of
course.
So
you
know
there
are
requirements
that
we
have
with
with
drafts
and
rfcs
where
we
need
to
have.
You
know
security
considerations,
and
you
know
things
like
that.
We
can't
not
do
security
if
we're
going
to
do
something.
B
At
least
we
need
to
consider
security
right
when
we're
doing
something
to
me,
your
question
is
more:
should
we
consider
management
a
requirement,
not
necessarily
a
requirement
in
terms
of
you,
can't
publish
your
extension
unless
you
have
management,
because
I
agree
with
ac
in
that
you're.
Putting
too
many
requirements
is
gonna
delay,
it's
gonna
not
have
the
feature
come
out.
Maybe
the
functionality
is
more
important
in
the
short
term.
B
As
long
as
there
is
some
work
that
is
coming
right
as
long
as
the
module
is
is,
is
going
to
come,
and
you
know
some
approach
like
that
right
in
in
requiring
management,
just
like
we
require
other
things,
but
allowing
publication
in
a
staggered
way
is
what
seems
appropriate
to
me.
Of
course
it
depends
on
the
working
group
right.
As
you
know,
jeff
just
said
you
know:
bgp
hasn't
published
the
main
module,
there's
a
lot
of
catch-up
to
be
done.
B
A
Yep
makes
sense,
I
mean
I
agree,
there's
no
one
answer
for
everything.
You
know
it's
just
what
my
concern
was
that
it
being
yang
you
know,
we've
done,
I
mean
itf
routing
area,
we've
done
so
much
effort
spent
so
much
cycles
on
doing
yang
for
the
past
few
years.
That
it'd
be
okay,
we've
done
it,
let's
move
on
and
then
we're
going
to
have
this
huge
gap
again.
You
know
this
growing
gap.
That
was
my
concern
and
that's
why
I
wanted
to
bring
it
up.
A
H
You
know
you
know,
and
I
think
I
know
you've
reviewed
a
lot
of
them
and
you
know
what
what
the
models
in
routing
look
like
and
a
lot
of
them
are
pretty
complex.
You
take
the
bgp,
the
ospf
or
the
multicast
ld
mldp
model
there.
They
are
not
for
the
phoenix
part.
Now
I
don't
think
everybody
who
wants
to
submit
a
proposal
is
gonna
be
able
to
modify
them.
I
mean
this
is,
are
we
gonna?
Are
we
gonna
keep
them
from
doing
it?
H
I
don't
think
we
can
do
that
like
alvaro,
says
they're
just
too
much,
and
the
last
thing
I
want
to
say
about
this
is
we
have
started
doing
augmentations
to
pick
up
some
of
the
features
we
missed
either
because
they
weren't
they
weren't
far
enough
along
or
we
were
too
far
along
in
the
review
process
for
the
main
module.
So
some
of
us,
some
of
our
some,
a
subset
of
the
offers,
have
some
augmentations
for
features
that
we
miss,
and
will
we
ever
be
right
in
step?
B
So
see
that
yeah,
it
seems
to
me
that
your
question
is
important
and
you
know
what
I
would
like
to
to
propose.
I
think
we
all
agree
that
you
know
one
size
doesn't
fit
all
and
it
it
depends,
and
the
other
working
groups
are
at
different
places
of
the
of
the
cycle
of
getting
the
module
trying
to
catch
up
of
working
some
recommendations.
B
I
I
would
suggest
that
we
need
to
you,
know,
take
the
take
yank
seriously
and
and
have
a
plan
or
or
be
aware
of
the
potential
need
for
something
and
every
working
group
is
going
to
be
different.
So
what
I
want
to
ask
each
pair
or
or
group
of
chairs
is
to
think
about
what
this
means
in
your
working
group
and
it
may
be
completely
different
from
what
a
different
working
group
needs,
just
because
of
where
you
are.
B
But
at
least
you
know
consider
that
rob
wilton
in
the
isg
makes
the
point
of
asking
for
every
draft
that
is
produced.
What
about
management
and
where's
the
egg
module
and
many
times
the
answer
is
well.
We
don't
have
one,
sometimes
it's
nice,
that
we
can
actually
point
to
something
that
it
is
going
moving
as
fast
as
the
main
draft,
but
you
know
that
at
least
we
know
the
working
group
is
working
on
something
he.
The
fact
that
he
asked
is
just
you
know.