►
From YouTube: IETF113-MBONED-20220322-1330
Description
MBONED meeting session at IETF113
2022/03/22 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
I
think
the
there's
a
bigger
picture
than
what
I
worked
on.
I
did
some
some
interop
with
the
amd
which
I
can
go
over,
but
then
I
think
the
free
rider
people
did
some
beer
work
as
well.
If
I
remember
right
so
it
might
be
good
to
at
least
get
frederick
in
there,
but
I'm
happy
to
supplement
on
amt
as
well
right.
C
B
B
B
B
B
B
And
meeting
tips
you've
probably
seen
this
by
now,
though
not
in
purple
and
I'm
not
quite
sure
it
came
in
purple,
but
it
is
for
those
of
you
for
whom
it
is
very
early.
This
might
help
serve
to
wake
you
up
a
little
bit
more
effectively,
but
everybody,
even
if
you're
in
the
room
should
be
signed
into
the
meet
echo
tool.
That's
how
we
will
manage
the
mic
queue
and
remote
participants.
B
Okay,
here's
our
agenda,
we'll
go
through
the
word
group
items.
There'll,
be
a
brief,
very
brief.
Update
on
the
hackathon.
There
was
a
little
bit
of
work
done.
Most
of
it
was
not
related
to
multicast,
so
that'll
go
quickly.
Sandy
is
going
to
give
an
update
on
the
redundant
ingress,
failover
draft
and
then
jake
will
go
through
all
of
his
various
drafts,
as
well
as
a
w3c
update.
B
B
D
D
B
Yep
and
any
other
folks
who
are
interested
in
yang
models,
we
also
encourage
you
in
addition
to
gion
and
jake
the
telemetry
draft.
I
got
an
update
from
the
authors.
They
are
about
to
update
it
soon.
There
are
some
several
drafts
upon
which
this
document
depends
that
are
in
working
group,
last
call
and
other
working
groups,
and
that
should
be
completed
soon.
So
once
that
gets
done,
they
will
update
and
they
plan
to
present
this
in
ietf
114..
B
E
Yeah
that
other
working
group
is
ippm,
it's
ip
performance
group
and
performance
management
group
and
they're,
the
ones
that
are
handling
the
unicast
versions
of
this
draft,
and
so
those
are
the
drafts
that
this
draft
has
depended
upon.
So
as
they
progress
which
they
should
soon,
then
we
can
progress
this
one.
We
did
last
time
we
updated
this
added
a
couple
other
authors
and
they
made
some
good
contributions
and
the
once
the
other
drafts
do
progress
in
ipp
ippm.
E
We
probably
will
pretty
quickly
after
this
one
to
be
reviewed
and
progressed,
because
when
we
submitted
this
draft
it
was
actually
it's
one
of
those
rare
drafts
that
when
we
submitted
it,
it's
almost
ready
to
go
kind
of
a
thing.
So
anyway,
yeah
we'll
we
keep
it
alive
and
we
give
minor
updates
to
it
and
we
will
present
it,
as
you
mentioned
at
the
next
idea,.
B
Great
thanks,
then,
there
are,
of
course,
the
multicast
to
the
browser
drafts,
the
four
and
jake's
going
to
provide
updates
on
this
later
in
the
agenda
or
later
he's
next
up
the
ingress
redundant,
ingress
failover.
This
is
a
document
that
is
currently
has
an
adoption
call
underway
and
actually-
and
I'm
working
group
adoption
call
goes
through
this
friday.
So
so
far,
we've
had
a
number
I
haven't
counted,
but
there
has
been
some
responses,
but
we'd
love
to
have
more.
Please
it's
a
short
draft.
B
So,
let's
see
what
else
what's
up
on
the
agenda?
Okay,
next
up
on
the
agenda
is
a
hackathon
update.
So
frederick,
I
believe
you
said
the
component
of
the
hackathon
that
you
were
involved
in
was
not
multicast
related.
So
if
that's
the
case,
maybe
jake,
if
you
want
to,
if
you
want
to
speak
up
about
what
you're
aware
of.
A
A
I
don't
know
like
what
their
kind
of
commit
processes
like,
but
I
think
I
think
the
one
he's
running
now
is
has
a
quick
patch
in
it,
and
maybe
that'll
be
upstreamed
appropriately
anyway,
the
yeah,
so
the
the
the
amt
gateway
docker
container
and
the
mt
relay
d
now
are
both
confirmed
with
with
them.
You
know
each
of
those
talking
to
themselves
and
and
to
the
free
router
implementation
for
v6
and
v4,
I
think
with
with
one
set
of
tests
still
pending.
A
Yeah,
that's
that's
correct
those
those
just
worked,
so
this
is
of
course,
with
an
external
gateway,
not
the
embedded
gateway
inside
vlc,
but
with
the
external
relay,
then
those
those
just
work
for
for
both
v4
and
v6
ssm.
I
did
not
try
asm,
but
I
don't
care
so
gotcha.
I
I
will
try
if
somebody
else
wants
to,
but
I
haven't
tried
it
yet.
I
think
it'll
be
fine,
because
for
the
for
the
client
side,
it's
going
to
be
very
identical.
B
D
D
D
D
So
this
is
the
brief
introduction
of
this
dropped.
Usually,
two
increased
routers
are
deployed
for
avoiding
a
single
node
failure
and
the
two
ingress
router
can
forward
a
same
multicast
flow
for
the
egress
routers,
which
connect
the
receivers.
They
can
select
the
edge
for
multicultural
flow
forwarding.
D
D
D
Hey
seems
I
can
page
down
the
slides,
okay,
okay,
I
can
do
the
control
it
work
now.
So
this
is
the
update
of
version.
There
are
two
we
added
a
section
for
failure:
detection
according
to
jake's
comments,
thanksgix
and
in
order
to
achieve
the
successful
ir
switch
over
vfd
or
ping
methods
can
be
used
for
monitor
the
ir,
node,
fader
or
path
fader
between
ir
and
the
ers
for
vft
methods.
Vfd
fc5880
can
be
used
in
all
the
deployments.
D
D
D
As
soon
as
possible
or
er
can
get
the
flow
from
bir
in
advance,
when
bir
detects,
the
fader
of
sir
vrr
takes
over
the
sirs
responsibility
and
forwards
flow
two
years,
but
the
mistakens
which
over
may
occur
because
in
case
only
one
only
the
path
between
bir
and
the
s.
I
are
fierce
and
in
this
situation
yeah
I
may
receive
duplicate
flow.
D
D
So
this
is
the
during
the
adoption
call.
We
receive
many
useful
comments,
thanks
jk
and
again
we
plan
to
add
more
information
and
details.
In
future
version,
we
will
add
the
signaling
procedure
for
of
the
three
modes
between
ir
and
er,
to
make
it
more
clearly,
details
will
be
added
for
the
existing
optimization
method
used
in
failure.
Detection,
for
example,
for
example,
fc9026.
D
B
Okay,
thank
you
for
sharing
and
just
a
reminder
again.
This
is
still
in
the
adoption
call
until
friday.
So
please
love
folks
to
review
and
and
at
least
mention
whether
you
support
or
do
not
support
adoption
of
this
document
by
the
working
group
jake.
Are
you
ready
to
talk
for
your
next
or
you?
Do
you
have
a
question
about
this
draft.
A
D
D
Many
yes,
because
there's
many
technologies
included
in
this
structure
and
we
have
deployed
some
technologies
such
as
ping
and
the
beer
has
not
been
used
widely.
So
there
is
no
beer
deployment
for
it,
but
there's
many
pink
deployments
for
it.
So
we
usually
use
the
worm
standby,
also
the
hot
standby
mode
for
deployment.
So
for
hot
standby
mode
there
is
duplicate
flowing
the
network,
so
there
is
there
are.
D
B
A
Let's
see,
I
thought:
oh
there
we
go,
yes
share,
awesome,
okay,
and
I
think
I
have
that
excellent
okay,
hi
everyone
thanks
yeah
I'll,
be
talking
about
the
four
active
drafts
and
basically,
where
things
stand
in
terms
of
this,
this
project,
for
what
we're
doing
what
I'll
be
going
over
is
kind
of
progress
reports.
I
had
a
few
things.
I
talked
about
that.
A
Right
now,
I
would
say:
there's
a
number
of
things
kind
of
in
the
background
that
I
won't
really
be
touching
on,
but
the
the
sort
of
major
standards-based
pieces
of
it
that
are
that
I
know
of
that-
are
making
some
progress
and
then
I'll
conclude
with
my
requests
for
action.
So
I'd
like
to
people
to
consider
and
and
hopefully
take
going
forward
for
for
what's
like
kind
of
going
on
now
or
imminently,
so
the
the
follow-ups
from
iatf
112
were
kind
of
negative.
A
I
you
know
the
outcome
of
the
dispatch
discussion
was
that
the
discussion
on
on
the
multicast
security
document
was
dispatched
to
the
msec
list
I
sent
out
invites,
but
nobody
responded
to
anything
yet.
So
that
was
a
bit
disappointing.
I
think
it
indicates
there's
no
way
I'm
asking
for
a
buff
at
present.
A
B
Yeah,
so
maybe
this
is
a
question
for
for
warren
as
well
advice
here,
it
seems
like
we
have
a
lot
of
circular
dependencies
here.
We're
trying
to
bring
add
this
to
the
browser.
The
browser
people
are
saying:
there's
not
enough.
People
are
asking
for
this.
There's
not
enough
demand,
there's
not
enough
ietf
activity
on
this,
and
and
yet
we
seem
to
be
generating
atf
activity
and
interest.
B
So
how
do
we
kind
of
break
through
this
log
jam
and
is
there
something
we
as
a
working
and
so
maybe
a
question
to
warren
as
well?
Is
there
something
we
as
a
working
group,
can
be
providing
as
feedback
to
say,
hey
this
would
be
valuable,
there's
there's
we've
got,
operators
have
spoken
up
and
several
other
folks
have
spoken
up
that
this
is
interesting,
and
yet
you
know
there
seems
to
be
a
little
bit
less
agreement
from
others
on
that.
So
what
do
you?
A
A
All
right
great,
then-
and
I
I
do
want
to
say
it's
this
criticism-
that
it
requires
ietf
work.
First
is
not
necessarily
saying
that,
as
I
understand,
it
is
not
necessarily
saying
that
there's
no
ietf
interest,
it's
rather
saying
that
the
work
to
make
this
viable
for
web
transport
has
not
yet
occurred
in
the
ietf,
and
so
the
w3c
web
transport
cannot
reasonably
consider
it
so
that
that
was
my
take
on
it
now,
whether
that
will
go
forward
or
whether
we'll
hit
a
similar
wall.
A
When
I
try
to
take
this
to
quick,
that
is,
that
is
to
be
determined,
and
that's
where
I
was
going
to
to
go
with
that
question,
which
we'll
talk
about
a
little
bit
more
later
anyway.
So
in
light
of
these
kind
of
setbacks,
our
current
strategy
is
to
begin
some
we're
aiming
to
do
some
production
deployment.
A
That's
going
to
be
the
deployment
of
so
I
I
don't
know
if
it'll
be
inner
domain
in
the
very
first
run,
but
we
are
aiming
to
do
some
inner
domain
multicast
production
deployment
without
browser
support
under
the
understanding
that
in
the
long
term,
we
still
are
going
to
need
to
get
to
the
browser,
but
we
think
that
you
know
in
the
in
the
beginning.
I
was
kind
of
thinking
in
terms
of
if
we
can
get
some
browser
support.
A
That's
that's
there
on
the
way,
then
this
will
make
it
more
attractive
to
isps
which
I
think
is
true.
However,
I
think
the
other
way
also
goes
the
other
way
around
also
applies.
If
we
can
make
this,
if
we
can
get
some
traffic
running
in
some
real
isps,
then
it
will
make
it
more
attractive
to
browsers.
A
So
you
know,
as
always,
with
multicast.
We
have
a
chicken
and
egg
problem
and
we're
trying
to
address
it,
and
we
can
address
it
kind
of
on
either
side,
but
I
think
that
they
they
support
one
another
right.
First,
you
make
a
thing:
that's
not
quite
a
lizard,
but
also
isn't
yet
a
chicken,
and
that
lays
an
egg
that
has
it
that
grows
into
a
chicken
right.
So
anyway,
we
are.
A
We
are
not
abandoning
that
effort,
but
I
do
I
do
consider
this
a
a
minor
setback,
but
I
think
this
is
not
unexpected
when
encountering
security
feedback
for
the
first
time.
So
that's
that's
where
that
stands
so
in
terms
of
overall
project
status,
and
this
is
kind
of
the
you
know,
the
akamai
funding-ish
view.
A
You
know
I
ended
up
concluding
that
okay,
this
probably
is
worth
looking
at
in
in
more
detail
and
provided
we
can
get
some
partners.
The
intent
is
to
go
ahead
with
this
as
of
now
so
we
are.
We
are
in
talks
with
a
few
partners
and
and
looking
to
make
that
work
out
if
other
people
think
that
they'd
be
good
partners
for
those
two,
then
we'd
be
happy
to
to
engage
with
them
as
well.
So
anybody
here
that
wants
to
that
wants
to
ping
me
about
that.
A
A
A
So
we're
hoping
to
leverage
some
of
that
work
and
we're
also
hoping
that
this
will
actually
make
it
simpler
at
the
application
layer
because
it's
going
to
be
at
least
mostly
transparent
to
the
to
the
web
applications
that
would
be
making
use
of
it.
So
they
don't.
They
won't
have
to
do
anything
special,
except
maybe
like
enable
it
or
disable
it
at
the
high
level
and
sort
of
permit
the
underlying
stack
to
use
multicast
or
not
use
multicast,
but
that's
the
intent
the
intended
direction,
we're
going
as
a
rough
overview.
A
I
I
have
the
link
to
our
github
repo,
where
we've
posted
a
an
early
version
of
the
draft
that
doesn't
have
much
content,
it's
just
a
like
the
abstract
and
intro,
and
outline
and
a
few
consideration
a
few
security
considerations,
including
the
link
to
the
to
the
other
document.
So
none
of
this
is
adopted
and
there
are
many
ways
this
can
go
wrong,
but
this
is
our
current
plan
for
how
to
to
move
this
forward.
We'd
be
baking
it
into
quick.
A
They'll,
hopefully
match
up
with
our
with
our
security
considerations,
for
multicast,
insights
and
and
then
they'll
be
interpreted
as,
as
you
know,
just
just
another
unidirectional
data
stream
on
the
quick
side.
So
we
think
we
can
transport
or
we
think
it
makes
really
good
sense
to
transport
unidirectional
web
transport
streams
from
server
to
client.
A
Probably
h3
the
the
server
push
for
web
objects,
unfortunately,
browsers
are
removing
the
server
push
cache
and
the
server
push
feature
from
browsers
right
now.
However,
through
the
web
transport
unidirectional
streams,
it
still
should
be
possible
to
kind
of
implement
that
yourself
as
inside
your
web
app.
A
I
was
hoping
to
get
a
prototype
and
initial
spec
to
present
in
july
to
the
quick
working
group
we'll
see
how
that
goes.
This
could
be
superseded
by
the
by
our
if
I
have
to
spend
a
lot
of
time
on
the
on
the
partner
deployment
efforts
which
actually
would
be
even
better
than
than
this
in
terms
of
making
this
project
a
success.
A
So
this
could
slip,
but
I
am
hoping
to
have
something
coherent
to
present
in
july
and,
if
not,
then
then,
maybe
later
this
year,
yeah.
So
that's
that's
where
the
browser
effort
stands
want
to
say
thanks
to
max
for
a
bunch
of
feedback
and
pr's
on
the
ambi
draft
that
is
slowly
coming
into
shape.
I've
been
a
little
distracted
and
haven't,
haven't
done
a
whole
lot
on
actually
advancing
these
documents.
A
In
other
news,
the
we
have
still
been
meeting
regularly
at
the
w3c
multicast
community
group.
I
encourage
you
all
to
join,
there's
a
there's,
a
link
to
the
w3.org
community
multicast
here
and
even
if
you're,
just
on
the
mailing
list,
or
if
you
take
a
look
at
the
meeting
minutes
or
recordings,
then
you'll
be
getting
monthly
updates
on
this.
So
if
you're
interested
in
watching
then
then
keep
an
eye
on
it.
A
Meanwhile,
you
know
I'm
getting
some
code
contributions
from
some
of
the
some
of
the
multicast
community
group
members,
which
I'm
really
pleased
about.
So
thanks
in
particular
to
gavin
henry
for
some
of
his
work
on
live.
Mcrx
he's
he's
taking
a
look
at
adding
windows,
support,
which
is
great,
but
what
we've
already
upstreamed
from
that
was.
Was
integration.
A
A
A
I
think
it's
in
reasonable
shape.
If
I
remember
right
it's
I,
I
didn't
actually
read
it
all
the
way
through
last
month,
but
last
I
looked,
I
didn't
have
any
notes
left
on
it.
I
think
I
believe
I've.
I've
incorporated
all
the
comments
that
have
been
made
so
far.
Second,
is
I'd
like
to
make
dorm's
ambience
back
into
a
cluster
so
that
the
they
can
refer
to
each
other
and
get
handled
in
a
sort
of
clustering
way
for
the
rfc
editor.
A
A
A
Yet,
although
I
was
encouraged
by
the
people
who
did
respond
so
far,
so
that
was
that
was
good
and
then
the
other
thing
is
and
and
maybe
set
a
timer
to
reconfirm,
but
when
they
ask
for
conflict
avoidance
for
the
meeting
scheduling,
let's
make
sure
we
don't
collide
with
quick
next
time.
If
we
can
so
I
can
make
it
to
both.
If
that's
still
on
the
table,
like
I
said,
there's
a
chance,
this
will
slip.
A
I
guess
we
might
have
something
concrete
to
ask
about
with
the
with
the
security
considerations,
but
I
think
it
was
a
fair
point
that
that
they
want
to
have
an
actual
proposal
for
the
protocol
where
we're
proposing
for
transporting
web
traffic
over
multicast.
In
order
to
consider
and
that
that
is
like
it's
it's
hard
to
really
get
good
security
considerations
in
the
abstract.
A
B
A
F
A
A
D
A
So
amt
would
still
be
used
for
the
inner
domain
transport
wherever
there's,
not
a
multicast
capable
peering
that
that
does
the.
So
it's
so
the
way
that
the
the
amt
would
still
be
used
is
in
quick.
You
would
tell
the
client
that
hey
client,
please
join
this
multicast
group
and
then
the
client
would
join
that
multicast
group,
and
then
you
have
your
regular.
How
are
you
going
to
transport
that
multicast?
How
are
you
going
to
do
the
rpf?
A
A
You
know
it
should
work
just
fine
for
connecting
to
traffic,
that's
sourced
within
the
network,
but
it
also
would
work
with
the
dryad
extension
or
or
with
in
theory
with
the
well-known
ip.
If
there's
anybody
running
those
relays
to
ingest
the
traffic
from
outside
the
network,
so
we
still
intend
to
start
with
amt
access
for
inter-domain
transport,
but
it's
it
should
work
to
do
other
kinds
of
transport
as
well.
A
A
G
G
B
Yeah,
I
I
think
it's
worth
noting
that
we're
about
to
have
a
perhaps
an
inflection
point
for
this
topic
with
the
nfl
this.
This
fall
where
amazon
prime
has
exclusive
rights
to
streaming
of
thursday
night
football
games
and
you're
going
to
have
audiences
of
20
to
40
million
simultaneous
viewers
for
three
hours
a
week
for
16
weeks
a
year,
16
17
weeks
a
year-
and
you
know
the
other
doing.
B
A
I
think
we
may
have
passed
the
inflection
point
in
some
places.
There
was
a
similar
situation
with
the
zone
in
italy
that
really
began
last
year.
I
think
where
they
got
rights
to
syria,
a
which
is
the
you
know,
the
italian
football
most
popular
team
and
they
you
know,
there's
there's
been
a
lot
of
press
about
how
that
went
and
they
they
did
do
some
attempt
to
address
it
with
multicast.
As
I
understand
it,
but
but
it
seems
like
it
wasn't
enough.
A
According
to
the
statements
they
made
last
november,
multicast
helped
a
lot,
but
they
still
have
a
ways
to
go
because
it
was
only
in
one
network
and
and
they
needed
to
do
to
get
kind
of
more
to
really
meet
this,
make
it
satisfactory
to
their
end
users.
So
I
think
we're
past
the
inflection
point
really,
but
there's
still
open
questions
on
how
it's
going
to
land
anyway.
That's
that's
all
kind
of
not
really
protocol
work.
B
There's
always
the
the
one
person
who
spends
years
proactively,
trying
to
save
the
day
and
gets
ignored
and
in
the
end
does
save
the
planet.
So
I
think
we're
we're
following
that
script,
any
other
questions
for
anybody
else.
Anything
anybody
wants
to
add
before
closing
the
meeting
for
those
who,
for
those
wondering
why
we
only
well,
we
took
two
hours
every
time
I've
signed
up
for
one
hour
slots,
we've
blown
through
that.
So
we
took
two,
but
it
was
a
shorter
agenda
this
this
week.