►
From YouTube: IETF109-MBONED-20201116-0730
Description
MBONED meeting session at IETF109
2020/11/16 0730
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
C
C
A
B
A
A
B
A
D
B
A
Okay,
all
right,
so
let's
get
started.
Here's
the
note!
Well,
please
note
it!
Well,
it's
been
up
for
a
while
standard.
No
well
all
right!
Here's
our
agenda!
We
have
a
packed
agenda
today,
probably
the
busiest
agenda
we've
had
in
years
so
and
not
a
lot
of
time.
So
these
are
the
items
we
plan
to
cover.
Anybody
want
to
bash
this
agenda.
Any
anything
to
add
subtract
multiply
divide,
okay,
all
right.
Let's
move
on
to
the
status
of
active
working
group,
docs.
A
So
since
last
we
met
since
108
the
deprecate
asm
draft
has
become
has
been
published
as
rfc
8815,
so
we're
happy
to
have
that
there
and
it's
you
know
it's
been
actually
applied
as
a
bcp
in
internet
2
already,
so
that's
having
an
impact,
the
multicast
problems,
draft
that
was
sitting
that's
been
sitting
in
ietf
last
call
for
a
while.
There
were
several
discusses,
and
it
looks
like
mike
just
updated
that
mike
do
you
want
to
give
a
very
brief
mention
about
what?
What
on
the
updates
on
that
one.
E
Yeah
so
alyssa
and
a
couple
other
actually
ads
mentioned
a
whole
list
of
things
that
we
needed
to
change
there.
It
kind
of
was
a
depressing
amount
of
discusses.
Actually,
so
we
kind
of
just
working
on
it
for
for
quite
a
while,
but
recently
got
motivated
to
just
get
it
done,
and
so
I
addressed
all
of
alyssa's
comments,
we're
just
waiting
for
her
response.
E
She
said
she'll
get
next
week
and
then
the
next
two
sets
of
discussions
are
actually
manageable,
so
we'll
get
them
done.
We
are
proud
of
this
draft
and
we
keep
being
told
that
it's
a
good
draft,
but
we
just
need
to
make
it
so
that
the
different
areas
like
transportary
and
others
are
satisfied
with
things
that
are
confusing
to
them.
So
we're
we'll
get
it.
E
A
E
A
E
What
do
you
think?
That's
right
that
should
that's
that's
correct!
It's
just
a
lot
of
people
are
not
familiar
with
multicast.
A
lot
of
people
are
not
familiar
with
wi-fi,
and
this
draft
addresses
both,
and
so
we
have
to
just
kind
of
not
make
assumptions
that
people
know
what
certain
things
mean,
and
so
we
have
to
expand
it
and
just
explain
things
a
little
bit
more.
A
Gotcha
all
right
cool
thanks
mike
the
yang
models
draft,
is
active
sandy's,
going
to
provide
an
update
on
that
one
later.
The
other
active
drafts
are
the
multicast
of
the
browser
drafts
nbc
back
in
dorms
jake's,
going
to
cover
those
and
other
docs
jake
has
a
mnat
draft
which
he's
gonna
cover
as
well,
and
the
ingress
failover
draft,
and
that
will
be
covered
as
well
today
so
and
by
yishong.
A
E
G
E
G
G
G
We
have
several
trials
in
progress.
The
the
browser
api
implementation
is
coming
along,
not
everywhere.
We
want
it
to
be
yet,
but
but
getting
there
doc
status
and
next
steps
for
a
few
things
where
I
think
the
docs
are
ready
to
take
some
actions
and
then
I'll
be
spending
probably
about
half
the
time.
G
G
We
were
aiming
to
to
wrap
things
up
this
year,
which
I
think
with
a
couple
of
the
partners.
We
might
do.
Who've
already
started
with
some
of
the
ones
that
are
still
waiting
to
start.
We
are
extending
into
into
the
next
quarter
that
that
might
be
going
as
late
as
march,
but
we're
hoping
to
be
all
done
with
our
with
our
sort
of
initial
examination
trials
by
then
the
the
structure
of
the
trials
at
least
phase
one
is
lab
testing.
G
G
At
the
access
router
point,
which
is
which
would
be
just
deploying
the
the
ingest
platform
at
access
routers,
where
they,
where
they
want
the
the
traffic
to
be
multicasted
across
that
access
so
depending
on
on
their
deployment
plans
for
this,
if
it
if
it
serves
their
needs,
then
they'll
be
testing
it
in
both
of
those
ways.
The
traffic
that
we'll
be
running
is
we
have.
G
The
the
question
we're
looking
to
get
answered
is
whether
the
isps
would
actually
deploy
this
if
we
were
running
production
traffic
that
could
be
reached
in
this
way
and
had
it
had
it
deployed
at
scale,
and
that
will
inform
our
decision
of
whether
to
you
know,
commit
all
the
resources
to
this
to
to
turn
it
into
a
real
production
system.
Right
now,
it's
it's
all
still
kind
of
prototype.
G
It's
not
it's
a
little
questionable
to
call
it
suitable
for
production,
but
but
with
that
said,
we
we
are
looking
still
to
do
possibly
an
a
b
production
test
using
using
some
real
traffic
from
from
a
real
content
provider.
If
we
have
any
content
providers
that
end
up
signing
on
to
this
and
network
operators
that
that
think,
it's
reasonable
enough
to
try
it.
We
think
this
is
somewhat
plausible,
because
our
our
our
our
video
system,
that
we've
got
will
transparently
work
over
unicast.
G
G
Our
log
line
are
our
logs
of
of
the
actual
traffic
that
we
send
in
production
to
try
and
estimate
like
how
much
of
the
gain
are
we
going
to
get
out
of
this
and
that
that
should
hopefully,
in
some
anonymized
sense,
will
will
try
to
present
the
results
of
that
analysis
at
an
upcoming
meeting,
probably
in
march
or
july,
but
that's
sort
of
the
outline
of
what
we're
doing
with
the
trials
and
how
they
stand.
Now.
G
G
Now,
there's
still
a
whole
lot
of
work
to
do,
though,
and
so
it
won't
be.
We
won't
be
able
to
do
an
origin
trial,
probably
like
if
we're
in
that
position
by
july.
I'd
be
really
happy,
but
it
might
even
be
it
might
take
longer
than
that,
because
we're
definitely
get
before
we
can
do
an
origin
trial.
We're
gonna
have
to
to
solve
ambi
and
probably
do
the
do.
G
I
added
I
added
the
missing
ayanna
stuff
and
checked
it
against
the
yanguide
lens
that
resulted
in
some
changes.
So
right
now
from
the
working
group,
we're
looking
for
a
yang
doctor
review
to
begin.
I
think
it's
a
reasonable
and
appropriate
time.
If
there's
changes
that
come
out
of
that,
then
it
would
be
good
to
get
that.
G
You
know
as
soon
as
quick
as
soon
as
we
can
not
clear
whether
the
changes,
if
they
happen,
would
go
into
into
our
trials
or
whether
they'd
be
sort
of
follow
up
afterwards
and
just
make
a
claim
that
we
believe
that
can
it
can
be
equivalent
we're.
Also,
we
think
it's
a
good
time
to
do
an
a
request
for
early
allocation
of
the
service
name
dorms
for
ianna.
G
If
we
think
this
is
the
the
way
it'll
go,
and
I
also
had
a
question
about
whether
to
request
a
cluster
for
the
dorm,
seaback
and
ambi
drafts,
which
are
seaback
and
envy
are
built
on
top
of
dorms
as
an
extension
so
and
then
the
sea
back
updates.
Likewise,
most
of
the
tbds
are
finished.
There's
there's
a
couple
remaining
that
are
there
in
the
drafts
in
that
draft,
but
we
one
of
the
things
we
had
was
to
to
request
a
review
from
the
transport
area
about
the
circuit,
breaker
behavior.
A
A
G
H
Yes,
I
don't
see
warren
here
either,
but
in
terms
of
the
young
doctor
review,
I
would
suggest
it'd
be
easier
to
put
them
through
together
and
request
the
same
personal
review,
both
of
them
assume,
there's
quite
a
lot
of
context,
content
and
context
shared
between
the
two
you'll
make
it
an
easier
job
for
the
reviewer
to
understand
both
of
them
at
the
same
time
and
give
more
appropriate
feedback.
So
that's
my
recommendation.
G
G
Yeah
so
they're
doing
review.
I
put
a
link
in
in
this
in
the
slides
to
the
page
that
describes
what
the
request
looks
like
there's
a
so
yeah,
please.
I
guess
if
you
can
take
a
look
at
that
and
and
let's
follow
up
with
any
questions,
you've
got
for
me
about
it
like
I'm,
I
don't
have
anything
to
add
to
to
what
that
document
says
for
how
we
should
do
the
yang
doctor
request.
G
G
G
G
There
are
several
different
cases.
There's
been
some
discussion
of
that
on
the
list.
Thank
you
lenny.
I
hope
that's
helped
to
clarify
some
of
these
issues
and
I
am
aware
I'll
try
to
get
that
into
the
draft
if
we,
if
we
do
anything
with
this
draft
about
amna,
so
hopefully
that's
reasonably
clear
about
the
problems
that
I
encountered
and
one
the
the
reason
I
went
with
mnat
is
that
I
noticed
that
all
the
problems
that
that
I
did
encounter
could
be
addressed
by
this
one.
G
You
know
by
this
one
neat
trick
of
just
putting
my
multicast
traffic
into
different
addresses
into
a
different
address
space,
while
it's
within
the
network
that
has
some
special
restrictions
right.
So
so
that's
really
what
drove
the
the
work
on
this?
The
way
that
it
works
is
written
up
in
in
the
draft.
I
hope
a
couple
of
people
have
gotten
a
chance
to
read
it.
Hopefully
I'd
be
happy
to
take
comments
and
stuff,
but
the
basic
idea
is
that
there's
an
ingress
and
an
egress
at
the
ingress.
G
G
G
G
Of
those
groups
that
are
local
within
the
network
is
managed
by
an
external
service
and
that
service
is
essentially
located,
http
api
essentially
and
the
egress
and
the
ingress
are
both
talking
to
that
service
to
find
out
what
that
mapping
looks
like
and
then
the
ingress.
Just
you
know
at
the
ingress
point,
there's
a
translation
of,
because
we
know
that
that,
within
this
network
we
have
subscribers
to
an
external
global
sg.
G
We're
going
to
you
know,
do
something
to
propagate
the
ingest
of
that
traffic
into
the
network
and
then
we're
going
to
change
it
into
the
addresses
that
that
are
appropriate
for
this.
For
this
network,
according
to
whatever
the
mnat
service
told
us,
and
likewise
at
the
egress,
we're
going
to
be
taking
information
about.
G
We
know
that
there
are
clients
that
want
to
do
a
join
of
the
global
sg.
I'm
going
to
report
that
to
the
mnat
service
and
ask
them
if
there's
a
translation
that
should
be
performed
and
then
we'll
be
signing
up
to
receive
the
the
locally
mapped
addresses
that
are
that
are
appropriate
for
within
this
network
and
then
turn
that
back
into
the
the
global
sg.
G
That's
based
on
the
the
global
sg
that
is,
you
know,
looked
up
in
the
global
sg
according
to
the
the
dns
that
comes
from
the
global
source
and
apply
those
that
authentication,
for
example,
to
the
payloads
that
it's
receiving
in
the
locally
assigned
star,
g
or
or
whatever
it
is.
That's,
that's
been
locally
assigned,
and
one
of
the
key
reasons
I'm
trying
to
do
it.
This
way.
G
I
think
there
might
be
a
few
other
ways
to
approach
it,
but
this
seemed
the
simplest
to
me
and
one
of
the
things
that
you
get
out
of
this
is
that
there's
not
a
an
upgrade
to
the
cbe
devices,
which
is
quite
expensive
for
some
of
the
isps
like
in
general.
They
are
willing
to
do
things
that
improve
their
efficiency,
but
they're
not
willing
to
do
like
a
major
sort
of
greenfield
rollout
right
and
which
makes
perfect
sense.
It's
in
line
with
with
how
their
finances
are
are
run
right.
G
So
by
running
something
potentially
as
deep
as
inside
the
app.
You
can
really
dodge
a
lot
of
a
lot
of
the
need
for
new
equipment.
All
you
need
to
deploy
is
a
new
service
somewhere,
that's
discoverable
within
the
network,
and
then
that
new
service
needs
to
be
standardized
enough,
that
you
can
that
you
can
communicate
all
the
signaling
about
what
this
translation
for
the
local
network
should
be.
The
way
I
propose
to
do
the
discovery
in
the
draft
is
with
dnssd.
G
And
my
real
question
is
whether
this
is
suitable
for
mbondi
adoption
and
whether
the
mbod
participants
think
that
we
should
do
so.
There's
one
caveat
about
suitability
that
maybe
I
should
raise.
I
looked
at
the
charter
for
mbud
and
it
did
say
that
group
management
protocols
are
out
of
scope.
I'm
not
sure
whether
this
qualifies
as
a
group
management
protocol,
because
the
egress
does
report
to
the
central.
G
G
B
A
B
I
think
this
is
a
great
piece
I
mean
it's
clearly
part
of
the
puzzle
and
the
feedback
you
got
directly
from
operators
showing
these
the
gaps
and
you
solve
them
with
a
single
clever
tool
is
fantastic,
so
I'm
I
I'd
support
adoption.
We
need
to
take
it
to
the
list
here
or
the
room
here
right
now,
I'll,
try
the
tool
see
how
this
works.
B
A
B
B
G
A
B
B
F
F
F
The
next
I
will
introduce
the
redundant
ingress,
router
failover,
a
multicast
source
connected
to
irs
in
order
to
avoid
the
single
node
failure
in
this
draft.
The
single
node,
the
the
irs
failure,
means
that
the
ir
node
failure
and
the
ir
to
er
part
failure
and
the
two
irs
are
all
umh
candidates
for
the
ers
in
case
the
ir
who
is
in
charge
of
forwarding
flows
or
it
when
it
fails.
F
F
F
F
F
By
means
that
er
signals
both
the
irs,
both
ir,
send
the
flow
to
the
er
and
the
er
must
discard
the
duplicated
flow
and
in
this
situation,
ir
does
not
distinguish
the
sr
or
bro
for
the
three
type
of
the
mode.
We
can
have
a
compilation
of
that.
The
first
is
the
iro
for
the
code
standby,
the
iron
forward,
the
flow
according
to
the
request
from
the
er
and
for
the
worm
standby.
F
F
It
doesn't
need
to
know
about
the
sr
or
bir
for
the
same
role
so
scene,
router,
the
code
standby
and
the
warm
standby
mode.
No
duplicated
flow
is
forwarded
and
maybe
in
some
situation,
duplicated
flow
may
maybe
forwarded
in
the
same
router,
and
we
have
some
consideration
about
the
three
types
of
the
mode,
and
that
is
the
coder
standby.
F
G
G
A
A
F
A
F
D
A
A
D
A
D
A
D
D
Okay,
this
is
the
major
update
of
the
chapter,
and
the
later
is
wanted
to
recall
some
memory
or
attention
on
this
structure.
The
time
limit.
We
I
wanted
to
present
this
content,
but
you
can
read
it
from
it.
Okay,
that's
all
thanks,
we'd
like
to
request
more
comments
and
the
reviews
before
walking
ghouls
of
king
group
last
call
thanks.
D
D
G
D
We
have
the
implementation
for
it,
and
this
project
is
open
for
everyone
and
because
it's
in
open
daylight
and
in
our
controller
product
it
can
also
be
used
to
manage
the
multicultural
service
yeah.
So,
but
we
know
that
they
are
only
partial
of
the.
Only
part
of
the
drug
model
has
been
verified
and
maybe
some
late.
Some
some
part
of
the
young
model
has
not
been
verified,
so
we
would
like
more
review
on
it.
Yeah.
G
Can
you
identify
which
parts
are
which,
like
which
parts
are
like
really?
Could
you
maybe
send
something
about
that
to
the
list
like
sort
of
which
parts
have
been
exercised
in
you
know,
in
production
or
by
the
way
it's
used
in
products
extensively
and
which
parts
really
need
more
digging
or
more
examination.
D
And
so
yes,
because
you
see
the
this
there's
many
parts
parts
in
this
model
and
some
we
know
that
there's
many
options
for
the
multicast
deployment,
such
as
overlay,
your
vlc,
european,
european,
bdp
or
something
else,
and
in
transporter
we
may
choose
beer
ping
or
other
things.
So
we
needn't
define
the
detail
of
this
model,
because
this
model
has
a
mature
model
here.
D
We
just
like
to
organize
them
and
make
them
mix
them
together
to
help
the
multicultural
service
deploy,
but
something
in
some
parts
of
the
draft
we
made
some
such
as
backup
tunnels
or
something
else,
because
when
we
talk
the
issue
with
our
customers,
they
think
it's
important.
So
I
also
added
them
into
the
model,
so
we'd
like
more
review
on
it.
If
you
think
it's
reasonable
or
available,
and
it's
good
for
us
yeah.
A
A
A
E
Yeah,
I'm
kind
of
hoping
that
we
take
it
to
the
end
to
see
if
we
really
do
get
kicked
off
five
minutes
after
I
never
got
that
question
answered,
but
we'll
see
so
hopefully
you
can
see
my
screen.
This
presentation
has
been
given
in
mbd
a
year
or
so
ago,
and
also
in
pim
we've
been
focusing
on
this
draft
within
ippm
working
group,
ip
performance
measurement
working
group,
because
it
it
is
calling
for
some
modifications
to
some
protocols.
E
And
as
what
happened
we
we
discussed
this
briefly
with
warren
and
as
what
happens,
oftentimes
with
oam
related
documents,
especially
when
it's
multicast
related,
is
that
there's
there's
not
much
interest
or
understanding
of
multicast
related
technology,
so
it
just
kind
of
gets
ignored
and
that's
kind
of
where
we
are
with
this
draft,
and
so
we,
our
new
strategy,
is
to
revisit
it
with
an
mbondi
as
well
as
pim
and
we're
kind
of
thinking.
Now,
if
I
can
just
skip
to
ahead
real
quick,
this
is
the
very
last
slide.
Then
I'll
go
back.
E
E
So
what
we
are
thinking
about
doing-
and
we
did
discuss
this
when
we
presented
this
last
time
in
mod-
is
to
have
a
more
general
problem
statement
exist
in
mbo
and
d
having
to
do
with
oam
and
multicast
and
then
have
the
proposed
protocol
modifications
done
in
pin
since,
as
far
as
I
know,
that's
not
something
that
we
do
in
mbondi.
So
that's
kind
of
our
strategy
right
now,
and
so
that's
why
we're
here
and
how
you
and
greg
are
both
on
the
call
they
understand.
E
Ippm
related
protocol,
especially
iom
and
other
protocols,
very
well,
and
so
of
course
multi.
You
know,
monitoring
multicast
traffic
is
is
important.
It's
it's
helpful
to
be
able
to
reconstruct
and
then
visualize
that
multicast
tree,
using
telemetry
data
and
being
able
to
monitor
the
performance
troubleshoot
find
out
where
jitter
is
where
drops
were
occurring
and
things
like
that
and
so
conventional
oem
techniques
are
not
sufficient
and
there
are
some
good
on
path.
E
Telemetry
techniques
such
as
I
om
and
post
guard
base
tree
and
hybrid
two-step,
that's
being
done
in
ippm
and
again
how
you
and
greg
are
leading
some
of
those
that
protocol
work
and
what
the
iom
anyway
has
to
do
specifically
with
is
adding
telemetry
data
to
the
packet
itself.
Instead
of
doing
an
out-of-band
mechanism
for
telemetry
data,
operational
data,
it's
it's
put
in
the
packet
itself,
and
so
you
get
real-time
information
and
you
can
send
that
information
where
you
want
to
do
some
analysis
on
it.
E
But
the
the
current
on-path
telemetry
techniques
do
have
some
flaws
for
multicast
with
iom
every
packet
can
cont,
carries
the
entire
data
trace
and
so
there's
a
lot
of
redundant
data
that
occurs
when
you
have
entire
paths.
Multiple
paths
from
end
to
end
that
are
being
captured
and
sent
to
telemetry
engines,
and
so
that's
there's.
E
There's
got
to
be
some
good
ways
and
we've
proposed
some
to
to
make
it
so
that
there
isn't
that
redundancy
at
wasting
bandwidth,
particularly
when
you're,
adding
additional
fields
to
packets,
which
is
what
you
do
with
iom
and
then
with
something
like
a
postcard
based
type
tree.
There's
no
branch
identifier.
So
when
you're
correlating
these
postcards
and
postcards
I'll
show
you
in
just
a
second
here
when
you
correlate
them,
there's
no
way
to
tell
when
you're,
quoting
where
the
branches
exist.
And
so
we
are
again.
E
The
objective
is
to
to
propose
some
modifications
to
allow
the
tree
to
be
correctly
reconstructed
without
unnecessary
replication
of
telemetry
information
and
so
just
very
quickly,
because
we're
going
to
just
discuss
this
in
pin
and
just
the
next
meeting
is
there's
there's
a
couple
solutions.
One
is,
if
you
see
in
the
bottom,
there's
we're
proposing
a
branch
identifier.
E
A
B
G
E
E
The
pym
chairs
worked
with
the
spring
chairs
and
they
said
yeah,
please
pim,
take
it.
We
don't
have
the
time
or
interest
or
expertise
to
deal
with
it,
and
so
we
did
I'm
anticipating
something
similar
happening
here.
So
this
will
be
adopted
in
pim.
You
think,
well,
that's
yet
to
be
determined,
but
I
think
ideally
in
my
mind
we
would
have
a
problem
statement
draft
being
done
here
in
mbondi.
E
A
E
E
Yeah,
I
think
what
we'll
do
and
again
I'm
just
using
the
example
we
did
with
the
spring
and
point
of
multiplying
is
we
would
kind
of
discuss
this
and
right
we're
doing
it.
So
right
now
we'll
discuss
in
a
pim
and
then
we'll
ping,
the
ippm
chairs
and
tell
them
what's
going
on,
and
this
is
what
we
prefer
to
do
and
if
they
agree,
then
we'll
do
it.
If
the
working
group
decides
to
bring
on
the
work.