►
From YouTube: IETF100-RTGWG-20171113-0930
Description
RTGWG meeting session at IETF100
2017/11/13 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
And
it's
also
described
on
the
wiki
page
they're
clean.
We
are
ttwz,
you,
it's
all
be
changed
process
to
help
notice
possible.
So
we
require
the
dominant
authors
and
contributors
state
whether
or
not
they're
aware
of
any
IBR
elephant
in
question-
and
we
do
this
at
that-
the
two
main
gates
in
the
workings
of
document
process,
at
least
the
main.
B
A
A
That's
all
so.
If
you
have
administrative
past
and
I,
don't
be
blue
sheets
are
circulating.
At
this
point,
that's
one
of
the
administrators
take
care.
Please
sign
these
new
sheets
because
they
determine
what
size
of
room
to
get
next
time.
It's
not
silence
can
be
granted
smaller.
Obviously,
don't
have
that
problem.
This
confidence
way
so
I
want
to
thank
you,
no
takers
for
this
being
our
literary
inkjet
achoo
and
he
must
announce
our
bouquet.
It
was
a
tribute
to
the
Venice
we
are
living
for
a
garis
drive.
A
A
A
A
A
A
So
now,
I'm
moving
on
to
the
documents
that
are
that
have
been
part
of
the
working
group.
These
documents
already
passed
working
group
last
call
and
we're
sent
to
the
iesg
for
publication.
The
micro
loop
delay
draft
and
the
routing
types
draft
and
they're
basically
ready
to
be
published.
The
yang
models
for
rip
and
brrp
are
also
believe.
They've
made
it
through
through
the
isg.
A
They
had
some
modifications
to
be
nmda
compatible
that
is
making
them
compatible
with
the
new
data
store
architecture,
so
that
that
took
a
lot
of
you
know,
pick
some
work
to
to
modify
them,
but
thanks
to
the
authors
for
being
tolerant
of
those
changes,
so
these
documents
are
in
working
group
last
call
they
they
basically
competed
work
completed.
Working
group
last
call
we
yeah
and
they
also
had
changes
as
well,
but
so
anyways
will
I
need
to
discuss
it
with
yes,
Jeff,
but
we'll
probably
be
you
know,
sending
out
an
email
soon.
A
You
know
acknowledging
that
that
there's
consensus
to
to
pass
those
on
to
the
IAS
G
for
publication,
the
you
know
there
wasn't
a
lot
of
vocal
support
but
I
think,
given
that
this
was
a
design
team
that
was,
you
know,
housed
in
in
the
working
group
and
they're
doing
sort
of
thankless
work
and
it's
it's
part
of
a
you
know,
general
project
for
for
the
IETF
to
publish
yang
models
for
IETF
technology.
I.
A
There
are
a
couple
of
documents
that
are
existing
working
group
documents,
the
micro
loop
problem
statement,
document,
BGP
pic
and
two
other
documents
that
sort
of
I,
grouped
together
the
desk
source
routing
document
and
the
enterprise
PA
multihoming
document.
There
was
discussion
after
Prague
related
to
kind
of
bringing
these
into
alignment.
There's
some
changes
in
the
PA
multihoming
document
to
to
clarify
and
actually
make
make
the
two
descriptions
of
the
routing
agree
and
I
think
Jen's
going
to
talk
about
that
in
more
detail.
A
Other
working
group
documents,
the
multihomed,
prefix
LF,
a
document
Jeff
and
I-
are
both
co-authors
of
that
document.
So
we
will
not
be
conducting
the
working
group
last
call
for
that,
but
engine
jus
will
be
in
the
case
of
the
RTG
WG
back-off
algorithm
I'm,
a
co-author
of
that,
so
Jeff
will
be
conducting
that
one
he'll
be
doing
it
soon.
A
The
last
status
was
that
it
needed
more
details
on
MPLS,
encapsulation
I
had
a
conversation
with
Stuart
Bryant
yesterday,
and
he
should
be
contributing
to
that
and
getting
that
kind
of
wrapped
up
recently
adopted
working
group
document.
Is
the
routing
timer
parameter
sync
document
as
well,
so
that's,
that's.
All
I
have
for
the
review
of
the
current
status
of
documents.
If
you
have
any
questions,
we'd
be
happy
to
take
them,
otherwise,.
A
A
D
B
D
B
B
B
B
And
so
here
is
the
proposal
so
that
we
can
use
ERP
control
messages
to
advertise,
be
if
the
discriminator
of
the
master,
because,
unlike
in
point-to-point
BFD
where
there
is
a
three-way
handshake
to
exchange
discriminators
between
peers
in
multi-point
BFD,
there
is
no
handshake
because
its
uses
demand
mode
from
the
beginning.
So
thus
the
remote
peer
are
the
tail
of
point-to-multipoint.
B
If
this
session
has
to
do
the
multiplexing,
not
on
your
discriminator
in
a
control
packet
which
is
locally
unique
for
their
receiver,
but
on
remote,
my
discriminator
source
of
the
message
and
source
a
address
of
the
message.
So
by
providing
information
in
the
RP
control
message,
we
enable
auto
discovery
of
existing
BFD
environment.
So
if
some
some
backup
router
comes
later,
it
doesn't
have
to
be
explicitly
provisioned
either
through
configuration
or
a
control
plane.
B
So
there
are
P
control
message
does
that
for
us
automatically
and
that
introduction
so
that
change
we
believe
offers
believe
that
creates
sufficient
divergence
from
existing
IP
R.
So
then,
there
is
a
way
of
implementing
this
without
really
discussing
the
IP
r,
so
in
red
that
you
see
that
our
proposal
to
add
to
extend
VRP
control
message
by
adding
optional
master
discriminator
information
that
will
be
received
by
the
backup
router,
and
so
that
can
help
to
do
the
multiplexing,
and
that
includes
that
included
in
each
and
every
control
message
that
send
by
the
master.
B
B
That
text
explains
the
mechanics
and
read
is
what's
been
introduced
in
the
current
version,
so
that's
an
update
next
steps.
We
appreciate
your
reviews,
comments,
questions,
suggestions
and
we
just
wonder
if
working
group
will
consider
adoption,
because
now
we're
not
really
changing
anything
in
BFD
and
all
the
change
is
in
the
air
RP
protocol.
So
probably
the
RP
protocol
now
belongs
in
RTG
VG
or
if
it's
not
the
case,
then
appreciate
your
suggestion
where
to
anchor
this
work.
A
B
A
A
Don't
need
to
disclose
it
I
think
I
think
you
know
one's
always
very
careful
when
discussing
IPR,
but
I
think
the
rules
are
weak.
The
working
group
can
take
that
into
consideration,
but
it
still
needs
to
be
disclosed
so
that
the
working
group
again
okay
decide
whether
or
not
the
the
workaround
is
acceptable.
Okay,.
B
A
C
Morning,
everyone,
my
name,
is
uncle
the
way
I
work
with
VMware
and
today
I'm
going
to
talk
about
using
BFD
to
achieve
active
standby
redundancy.
When
there
are
multiple
set
of
services
running
you
know,
some
set
of
services
are
in
reverte
mode,
while
some
set
of
services
could
be
in
non-relative
node
mode.
C
So
let's
see
what
that
means.
You
know,
let's
straight
jump
into
the
use
case.
So,
as
you
can
see
here,
there's
a
you
know:
the
diagram
is
showing
three
nodes
over
there.
Each
node
is
having
a
PFD
session
with
the
other
node
and
there
are
the
control
and
the
Network
Controller
is
provisioning
a
set
of
services.
C
So
essentially,
what
we
are
trying
to
do
is
that,
if
a
certain
node
when
it
goes
down
the
other
node,
which
is
taking
over
the
non
revert
of
service,
it
needs
to
indicate
the
the
node
that
it
went
down
that
you
know.
I
was
alive
and
I
have
taken
over
the
non
revert
of
services
so
that
that's
a
that's
sort
of
the
requirement
there,
and
you
know
some
of
the
details
regarding
how
we
can
do
this
is
in
the
next
slide.
C
So
essentially,
what
we
are
proposing
is
the
you
know
this
two-step
solution
that
you're
proposing
one
has
to
simply
use
a
dye
code
which
is
used
by
the
node.
You
know
that
went
up,
for
example,
in
this
diagram.
If
no.2
went
down
the
node
one
is
going
to
set
the
dye
code
to
set
to
say
I
outlived
you
and
there
is
going
to
set
that
dye
code
in
the
Beauty
session
between
node
1
and
node
2.
C
So
no
two,
when
it
comes
back,
it's
going
to
know
that
okay,
note
one
has
taken
over
me,
so
I
should
not
claim
for
the
non-derivative
services.
The
node
1
will
be
acting
as
the
active,
so
that's
part
one
of
the
solution.
The
part
two
is,
if
you
have,
you
know
a
bunch
of
services
where
some
are
non-relative
and
some
are
revolted.
C
You
probably
want
to
do
granular
level
failover,
which
means
that
you
know
certain
services
or
node
one
could
be
active
which
are
non
derivative,
but
certain
services
on
node
two
could
be
active,
which
are
you
know,
non
reverter.
So
how
do
we
do
that
is?
Is
is
basically
the
controller
it's
going
to
set
is
going
to
create
a
unique
bitmap
which
in
which
every
bit
is
identifying
a
unique
service
and
the
same
bitmap
is
pushed
to
all
the
nodes.
C
So
the
node
that
is
setting
the
die
code
is
all,
can
also
use
a
bitmap
and
it
will
set
those
bit
positions
which
will
identify
the
services
that
are
running
is
active
on
that
node.
So,
by
doing
this
you
can
you
can
achieve
you
know
the
active
you
can
you
can
tell
the
peer
node
that
which
set
of
services
are
active
on
me.
C
D
G
Moaning,
so
it's
a
quick
update
on
enterprise,
multi-home
and
graph,
just
a
quick
refresh
in
case
you
have
forgotten.
What's
all
about
we
trying
to
solve
problem
of
enterprises
network
using
p
address
space
from
multiple
providers
without
using
this
quadruple
technology
called
not,
and
the
main
problem
is
there
how
to
send
a
packet
to
the
write,
a
plane,
because
providers
might
lose
a
good
think
and
implement
BCP
search
aid.
G
So
there
are
two
parts
of
it
is
how
to
send
packet
to
the
right
uplink,
which
is
perfectly
in
scope
for
routing
group,
and
the
solution
is
to
use
source
address,
dependent
routing
when
next
hope
is
chosen
based
not
on
just
on
the
destination
as
in
traditional
and
inference,
but
also
based
on
the
source
address.
And
then
there
is
a
second
part
of
solution
which
is
more
related
to
ID,
v6,
Astrakhan,
host
and
stateless
out
the
configuration
which
I'm
not
going
to
talk
about
because
there
is
no
changes
there.
G
So
the
main
change
that
should
only
change
my
attends
0
1
version-
is
that
there
were
trumpeter
brought
to
attentions
effect
that
that
if
we
have
two
routers,
which
one
one
of
them
is
implementing
source
address,
dependent,
radical
and
another
one
is
using
destination
source
routing.
Then
we
might
see
routing
loops
in
some
cases
and
it's
related
to
the
fact
how,
as
ad
our
router
populates
forwarding
tables.
So
let's
look
at
the
example
ecology.
G
Let's
say
we
have
router
B
which
implements
as
idea
and
entrance
to
scoped
forwarding
tables
and
one
on
scope,
forwarding
tables
for
everything
and,
let's
say
it
advertised
to
scoped
prefixes
to
router
a
and
received
her
and
called
default
from
router
a
so
far
so
good,
then
the
old
text.
It
was
the
last
step
of
how,
as
ad
our
router
populates
forwarding
table.
Basically,
basically,
what
we
do.
We
take
prefixes
from
unscoped
table
and
if
those
prefixes
do
not
exist
in
scoped
forwarding
table,
we
put
them
there.
So
basically
my
those
tables
consistent.
G
So,
for
example,
in
the
above-mentioned
scenario,
let's
say:
router
B
has
to
scoped
forwarding
tables
1
scoped
for
blue
prefix
1
for
green,
and
please
note
that
in
this
case
those
prefixes
actually
overlap.
Blue
prefix
is
more
specific
to
red
one.
It's
exactly
scenario.
When
we
can
see
some
interesting
side
effects,
then
blue
routing
table
will
have
one
route:
scope,
2,
blue
prefix
red
one
also
has
one
route,
and
then
we
populate
both
forwarding
tables
with
default,
which
is
coming
from
unscoped
forwarding
table
because
we
do
not
have
default
initially
in
those
called
forwarding
tables.
G
Relation
to
red
one,
but
blue
forwarding
table
doesn't
have
any
a
next
hope
for
less
specific
prefix.
If
router
a
receives
a
packet
which
is
has
a
destination
in
the
blue,
prefix
and
source
is
also
in
scope
of
the
blue
forwarding
table.
It
obviously
will
send
it
to
router,
be
ok,
but
then,
when
router
B
receives
a
packet,
it
looks
in
the
scope
and
scope
is
and
based
on
the
packet
source.
G
First,
we
look
in
the
ants
code,
forwarding
table
and
pop
in
adding
default
to
read
table,
but
then
we
also
look
in
the
raped,
read
forwarding,
table
and
find
there
is
a
entry
4/32
which
do
not
exist
in
blue
table,
so
we
populate
blue
table
there,
and
now
we
have
a
forwarding
country
in
blue
table
which
allow
us
to
route
packets,
choose
a
read
destination
and
in
this
scenario,
forwarding
route
and
groups
do
not
exist
anymore.
So
we
have
consistent
behavior
between
serve
destination
as
a
dr.
G
G
D
G
E
E
E
And
first
at
first
there
are
some
basic
principles
and
backgrounds
need
to
be
introduced
like
SWAT
is
serious
operation
BMG
and
the
why
we
needed
a
serious
operation.
Bmg.
Well,
as
you
know,
with
rapid
development
of
new
services
such
as
okay
LT,
the
number
of
broadband
service
subscribers
increased
by
ten
times.
It
also
causes
a
lot
of
challenges
for
traditional
BMG,
the
most
serious
issues
we
confront
as
our
even
resource
huge
and
complex
management,
ensuring
the
left
figure,
the
traditional
BMG
acts
as
a
gateway
for
user
access,
authentication
and
IP
networks,
Larry
edge
it
tightly.
E
E
Problem
is
the
traditional
bng
is
difficult
to
manage
and
maintain
due
to
the
last
number
of
traditional
Benji's.
We
must
config
each
device
one
by
one
at
a
time
during
during
deploying
a
global
service
policy.
Obviously
it
brings
difficult
management
and
maintenance,
and
it
also
means
that
any
new
earth
service
has
to
heavily
rely
on
the
multiple
PNG
devices,
which
should
be
updated
or
synchronized.
This
wrath
in
long
service,
TDM.
E
Too,
solve
these
problems
we
set
up,
we
propose
the
serial
separation,
BMG
protocol
architecture
and
protocol.
Briefly,
the
sale
separation
P&G
is
made
up
of
a
centralized,
cloud-based
the
city
and
set
of
a
set
of
high
performance
distributed
ups,
the
city.
It's
the
user,
control
and
management
component
weights
supposed
to
manage
UPI's
resources
such
as
you,
lunches
and
IP
addresses.
E
E
There
are
three
interfaces
between
the
city
and
yupi
that
it's
the
service
interface,
the
control
interface
and
a
management
interface.
The
servicing
surface
is
used
to
pass
the
pppoe
IPO
a
dollop
package
between
the
city
and
yupi.
The
management
interface
is
used
in
sending
static
configurations
from
city
to
UV
and
the
control
in
her
face.
It's
used
for
deliver
user
forwarding
entries
from
city
to
UT
and
the
report
and
the
reporting
the
users
that
informations
from
yupi
to
CP,
and
we
have
some
ideas
about
the
service,
interface
and
management
interface
and
way.
E
How
propose
the
two
drafts
about
them?
Why
it's
in
the
own
way,
all
three
and
another
is
in
the
RTG
WG.
We
how
we
also
have
a
document
to
introduce
the
information
model
for
the
control
interface.
Our
there
isn't
a
standard
protocol
to
introduce
the
attributes
which
described
in
the
information
model
document
to
fill
this
void.
We
set
up
a
July
team
cui
speedy,
write
him
to
prepare
the
CSP
protocol.
E
E
E
The
SIL
estilo
garments
include
words
in
negotiation,
have
a
be
little
port
city,
primary
backup,
car
ability,
the
city's
core
ability
to
stand,
the
unit's
information
table
to
you,
peace
and
you
end
notification.
You
liability,
secure
communication,
these
two
pages
briefly
Illustrated.
If
you
have
interesting,
please
review
the
document
and
the
provide
your
important
feedback
and
the
police
reveal
our
another
draft.
E
D
D
E
D
D
H
Okay,
can
you
hear
me
great
can't
move
too
far
here?
That's
I'm
actually
presenting
for
AC.
He
his
plane
was
delayed,
so
he
won't
be
here
until
this
evening.
Plan
was
for
him
to
present
and
then
Dan
to
follow
what
I'm
presenting
here
is
first
an
update
and
then
we're
going
to
go
a
little
bit
into
usage
of
the
LNT
model,
and
in
the
past
we
focused
on
ni
the
work
that
I'm
presenting
is
of
the
routing
area,
yang
architecture,
design,
team,
I.
H
H
Where
we
are,
is
we've
done
work
in
different
areas,
I'm
going
to
talk
about
each
of
these
before
we
go
into
the
example.
One
of
the
important
things
to
note
here
is
that
last
bullet.
We
think
we've
done
that
the
heavy
lifting
that
we
were
chartered
to
do,
and
so
we
are
targeting
sort
of
shutting
down
shutting
ourselves
down
with
the
80s
concurrence
before
the
next
meeting.
H
If
you
think
there's
a
piece
of
work
that
we
really
should
be
paying
attention
to
bring
it
up
on
the
list
like
the
working
group
list,
so
that
we
can
figure
out
whether
we
do
it
or
it's
just
done
in
the
working
group.
So
first
document
we
have
which
one
is
this
okay,
so
we,
as
I
mentioned,
we
have
a
bunch
of
documents.
H
And
I
don't
have
much
more
to
say
on
that.
As
I
said,
these
are
AC
slides,
I'm
going
over
here.
The
next
one
that
we're
in
good
shape
on
is
the
logical
network
elements.
This
document
is
dependent
on
some
work.
That's
been
going
on
in
that
mod.
That's
also
gone
through
last
call
that
scheme
amount
and
the
version
that
we've
most
recently
published
really
had
some
minimal
changes.
After
last
call
we
noted
that
the
Shepherd
asked
for
a
change.
Oh,
we
identified
one
change.
H
There
was
just
something
missing:
it
was
in
the
body,
but
not
in
the
appendix
so
we're
going
to
copy
it
into
the
body
we've
we
made
that
change
on
github.
If
you
look
watch
what
we're
doing
on
github,
the
other
change
it
that's
been
requested
is
to
be
nmda
to
show
an
nnm
be
a
compliant
model
for
LNA.
One
of
the
things
that
we
intentionally
wanted
to
make
sure
that
we
supported
was
not
an
NMDA
implementations.
Why
do
we
care
about
that?
H
There's
been
so
much
talk
about
off
state
solutions
and
NMDA
yeah,
that's
important,
but
we
also
have
things
that
are
being
built
today
in
the
field
that
don't
have
all
this
work
for
NMDA.
So
we
want
it
to
work
both
for
a
non
NMDA
and
NMDA.
So
we
can
add
another
example
if
the
Shepherd
wants-
and
so
we
have
both
an
NMDA
and
non-nba
but
I
think
it's
important
that
we
not
lose
the
not
NMDA
one
I'll
look
to
the
shepherd
who's
sitting
right
there
do
you
want
both
the
you
think.
I
H
Answer
we're
gonna
have.
We
should
have
both
versions,
nmda
and
non
MBA.
Examples
will
do
that
and
once
that's
done,
we
think
we'll
be
ready
to
for
the
Shepherd
to
submit
for
publication
request,
so
that
was
elleny.
We
also
have.
The
anti
document
turns
out
it's
basically
in
the
same
state.
Everything
that
I
just
said
for
lne
applies
also
for
and
I.
H
H
But
what
it
meant
is
is
that
we
took
a
document
that
we
thought
was
gonna,
be
really
important,
said
hey.
This
is
just
informational
and
it's
not
it's
not
clear
how
important
this
construct
is
to
be
able
to
to
identify
routing
protocols
as
routing
protocols,
control
playing
other
control
playing
protocols
is
control,
plane
management
protocols
as
management
protocols,
and
we
sort
of
let
that
draft
sit
around
because
we
didn't
have
a
good
mechanism
to
represent
it.
Chris
came
up
with
the
idea.
We
lost
Chris
came
up.
The
idea
is
hey.
H
We
just
use
like
hashtags
to
to
model
the
different
to
represent
the
function
of
the
different
modules,
and
more
than
that,
we
should
give
the
user
of
control
of
it.
So
while
we
may
define
what
we
think,
the
sort
of
attribute
of
a
model
is
and
a
vendor
may
think
something
else,
it's
actually
the
user
and
Chris
represents
a
user
user
provider.
H
These
are
should
have
control
and
he
came
up
with
the
hashtag
and
that's
the
first
graph
that's
listed
here.
So
in
order
to
support
sort
of
this
device
organization,
we
now
have
its
new
mechanism,
that's
running
through
the
process
in
that
mod
and
hashtags.
So
we
have
that
first
document,
it's
going
through
the
process
we're
now
back
to
the
device
model.
What
do
we
do
with
this?
If
hashtag
gets
accepted
as
a
working
group
document
in
that
pod
and
it
progresses?
H
We
think
we
could
do
something
with
it,
but
we
also
think
this
is
just
informational,
not
so
important
right
now
we're
just
letting
it
sit
there
see
what
develops
with
tags.
If
tags
go
through,
we
get
accepted,
they
progress,
we'll
revisit
the
device
model.
By
the
way
you
don't
have
to
know
the
answer
before
the
next
meeting.
The
authors
can
still
work
on
it.
Even
if
the
design
teams
not
around.
H
One
of
the
topics
that
we
spent
a
lot
of
time
on
but
didn't
author
any
documents
on
was
an
MBA,
so
we've
been
tracking
those
treating
making
sure
that
the
work
that's
going
on
there
will
line
up
with
with
the
area.
That's
happened,
we're
still
watching,
what's
going
on
making
sure
now
the
protocol
document
support
that,
but,
more
importantly,
we're
also
looking
at
the
documents
produced
in
the
area
and
making
sure
that
the
art,
those
RFC's
line
up
well.
Well,
it
turns
out.
H
We
really
only
have
one
routing
config
and
also
turns
out
it
wasn't
produced
by
this.
This
working
group,
it
was
produced
in
another
working
group,
but
we
still
have
the
right
people
in
the
room
who
care
about
this.
We,
so
we
made
sure
that
that
work
was
taking
place
of
updating
that
and
we
have
it
RFC
8022
bists
now
in
the
net
mod
working
group.
Ac
is
a
co-author
on
that
youko
exams.
H
Also-
and
there
was
some
nice
discussion
on
how
we
handle
yang
revisions,
turns
out
yang,
doing
versions
and
obsoleting
old
versions
is
something
that's
still.
We
haven't
really
figured
out
as
an
organization,
and
that's
gonna
be
a
hot
topic
in
that
Mott.
We
do
think
that
that's
something
that
this
group
should
pay
a
little
attention
to.
H
H
The
other
documents
that
we've
been
involved
with
and
have
really
been
outgrowth
of
the
design
teamwork,
but
haven't
been
driven
formally
by
the
design
team
or
include
scheme
amount.
We
know
that's
the
new
mechanism
to
allow
yang
models
to
mount
another
yang
models.
So
a
yang
model
excuse
me
so
that
if
you
have
a
module
that
needs
to
repeat
the
same
information
from
another
module,
you
don't
have
to
right
now,
just
it
or
really
list
the
whole
thing
you
can
just
say:
go
use
it
import
it
right
here.
H
So
if
you
have
a
module,
you
want
to
make
changes
to
it.
The
only
changes
you're
allowed
to
make,
while
keeping
the
name
the
same
is
to
add
things
to
it.
You
can't
go
remove,
you
can
obsolete
it.
You
can
mark
it
as
no
longer
used,
but
you
really
can't
remove
it.
It's
there.
The
sort
of
guidance
on
you
know
really
don't
need
to
implement
or
you
should
not
implement,
but
it's
not
gone,
and
if
you
want
to
make
something,
that's
not
an
incredible
change.
H
H
We
think
that
that
is
now
come
to
the
as
a
top
issue
in
that
mod
that
it's
going
to
be
work
they're
that
they're
the
right
people
to
solve
it
as
long
as
there's
a
solution
to
it
will
be
good
so
again,
something
that
the
design
team
doesn't
really
have
to
spend
a
lot
of
time
on
other
than
just
make
sure
it's
going
along.
Well.
Is
that
enough
to
keep
the
design
from
around?
J
I'm,
sorry,
it
am
I
not
swallowing
the
mic
far
enough.
Okay,
so
here's
IDR
co-chair
in
this
case
so
I'm
facing
some
of
the
questions
of
model
revisions
in
IDR.
With
the
base
BGP
model.
Did
you
have
any?
Could
you
just
review
the
current
thinking
from
net
mod
and
provide
a
little
insight
on
that?
Thank
you
sure.
H
So
when
do
you
stay
there,
cuz
I'm
gonna,
probably
end
up
asking
a
question.
The
the
current
guidance
is
was
first
documented
in
the
yang
one
auto
specification.
It's
been,
it's
repeated
I,
don't
think
with
any
really
substantive
changes
in
yang
1.1.
So
if
you
want
to
look
at
what
the
hell,
what
the
guidance
is
about
module
updates,
that's
the
right
place
to
go.
H
Look
and
basically
what
it
says
is:
if
you
make
a
change
that
is
non
backward
compatible,
you
have
to
change
the
module
name,
so
you
have
to
basically
say
it's
a
whole
new
module.
That's
what
it
currently
says,
oh,
and
by
the
way
it
identifies
exactly
what
an
on
a
non
backward
compatible
change
will
be
so
it
it
helps
you
out
to
understand
what
it
means,
the
that's
what
it
says.
The
problem
people
are
running
into
is
that
let's
say
I
do
routing
config.
H
How
do
I
know
that
routing
config
replaces
routing
config
the
original
one,
just
routing
fake
eighty
to
RFC
eighty
twenty
two
version
in
in
our
documents.
We
have
a
document
header,
which
is
provide
some
metadata
that
says
it
obsoletes,
the
old
one.
So
we
have
that
that's
good,
but
yeh
models
are
designed
to
be
consumed
by
computers,
not
by
people.
H
So
the
document-
header,
that's
in
an
RFC,
doesn't
do
a
whole
lot,
so
we
need
something
there
there's
a
couple
of
different
versions
there,
a
couple
different
approaches
to
solving
this
problem
that
are
being
discussed,
I'm
more
focused
on
here's,
the
problem.
What
the
actual
solution
is?
That's
something
that's
going
to
be
worked
through
the
community.
So
there's
a
proposal
out
there
to
use
revision,
numbering
sort
of
what
you
would
see
in
software.
H
H
Of
IDR,
if
you're
talking
about
versions
of
drafts,
that's
not
really
envisioned
in
this
part
of
compatibility
between
versions
of
interim
draft
internet
drafts.
That's
not
really
part
of
this
problem
space
because
that's
viewed
as
sort
of
those
are
working
things
and
you
make
it
not
make
a
non
compatible
change!
That's!
Okay,
because
that
was
just
a
work
in
progress.
It
wasn't
a
final
thing:
yeah.
J
K
Yeah
Atlas,
so
one
of
the
pieces
which
relates
to
how
do
we,
which
is
correlated
to,
but
not
the
same
as
how
do
we
handle
yank
module
revisions
is
how
do
we,
as
the
routing
area,
continue
to
update
and
extend
yang
modules
and
what
that
management
process
looks
like
and
I.
Don't
think
that
piece
has
been
really
nailed
down,
yet
we
probably
should
be
talking
about
it
at
breakfast
on
Wednesday
a
little
bit,
because
that
might
come
and
inform
some
thoughts
on
what
the
module
revision
process.
If
there's
any
impact
there.
Okay.
L
F
L
F
Then
bogdanovich
so
from
be.
It
will
be
very
good
if
the
routing
working
group
to
specify
the
use
cases
for
what
modeling
should
be
done
instead
of
working
on
the
actual
models,
work,
work
on
the
use
cases
and
the
workflows
that
have
to
be
done,
because
then
we
can
come
much
faster
to
an
agreement.
What
has
to
what
has
to
be
implemented,
and
then
the
implementation
you
know
can
be
done
in
a
much
more
rapid
way.
L
H
I
think
so
what
I
interpret
from
Dion
is
that
we
as
a
group
have
to
make
sure
we
inform
net
mod
of
our
requirements
for
handling
revisions.
So
the
fact
that
we're
thinking
about
having
a
model
that
our
module,
that
it
replaces
another
one
we
should
handle
that
we
have
suze
case.
We
should
handle
that
the
mechanisms
by
which
it
is
handled,
I,
don't
think
belong
in
this
working
group,
I
think
belongs
over
a
net
mod
I
think
that's
what
Dan
was
saying.
I
hope
that's
consistent
been
well
with.
L
H
So
I
feel
that
I've
gone
through
most
of
these
updates
already
there's
a
couple
of
important
points,
though,
at
the
bottom
of
the
slide.
At
the
last
meeting,
we
had
talked
about
trying
to
make
sure
that
the
users
of
our
ni
model
were
gonna,
be
aligned
and
actually
use
the
construct
that
we've
come
up
with
in
this
working
group,
so
the
first
user
we've
looked
at
was
in
best
the
l3
VPN
yang
model.
H
We
worked
with
them
at
the
last
meeting
and
got
good
alignment
on
how
that
would
be
handled,
and
we
talked
about
a
little
bit
in
this
working
group
and
more
inside
best.
What
didn't
happen
was
the
end
and
the
l3
VPN
model
has
been
published
and
is
well
aligned
with
the
NI
model
and
it
in
fact
augments
it
as
we
in
exactly
as
we
envisioned.
So
that's
great.
What
didn't
happen
is
we
that
we
didn't
do
a
similar
process
for
the
l2,
VPN
Andy,
VPN
documents
and
again
these
are
documents
and
bests.
H
So
we
wanted
to
make
sure
to
take
the
opportunity
this
meeting
to
get
that
alignment
turns
out.
Those
authors
didn't
travel
here,
so
instead,
we
met
last
week
in
just
the
informal
conference
call
with
some
of
the
authors:
it's
not
all
of
them,
just
some
of
them
to
get
the
ball
rolling
and
we
feel
we've
made
good
progress.
There's
still
some
confusion
on
how
to
use
this.
What
we've
defined
like
what
is
goes
inside
and
I
type
and
what
goes
inside
the
root
we
now
and
we
have
some
slides
later.
H
H
H
So
what
are
we
doing
next
so
as
a
design
team?
Well,
the
question
is:
what
do
we
do
with
revisions?
We've
talked
through
that
at
most
we'll
try
to
document
some
requirements,
I'm
not
sure,
there's
anything
unique
to
the
area,
as
benoit
just
said,
although
it
would
be
good
to
talk
with
su
and
understand
if
ID
r's
requirements
are
a
little
different
than
what's
already
being
talked
about
in
that
mod.
That
is
we'll
try
to
coordinate
how
that
those
requirements
are
brought
in.
H
The
next
thing
we
really
are
focused
on
disbanding
as
a
formal
group,
but
that
doesn't
mean
the
work
stops.
We
still
have
to
make
sure
that
the
documents
that
we
authored
contributed
to
our
tracking
that
those
have
progressed
through
the
process
and
get
published
as
RFC
s,
but
we
can
do
that
as
individual
authors,
you'll
see,
there's
a
good
list
there,
so
I
think
we've
been
busy.
H
So
the
next
that
that's
the
design
team
update
we're
now
going
to
go
into
what
that
area
that
the
chairs
asked
for.
Is
that
provide
a
little
more
background
on
how
we're
actually
using
things
so
Dan
is
going
to
go
through
an
example
of
an
early
implementation
of
villanies
and
just
as
a
refresher
to
people.
H
What's
in
lne
logic,
it's
a
logical
network
element,
it's
a
way
of
partitioning
a
system
into
partitioning
its
resources
to
be
used
by
multiple
logical
systems,
logical
routers,
VMs,
whatever
you
want
to
call
it
and
if
v's,
but
it's
a
way
of
managing
what
essentially
are
multiple
independent
routers
living
on
the
same
physical
device.
Now
one
of
the
interesting
things
is,
we
actually
made
sure
that
the
model
was
recursive,
so
you
can
have
some
bare
metal.
H
That's
the
ll,
any
part,
that's
what
we're
going
to
go
through,
just
as
it
for
context
and
I.
That's
all
about
births
and
BS
is
what's
the
big.
What's
a
big
difference,
there
is
sort
of
the
management
structure
with
a
virtual
router
logical
system.
You
always
do
full
partitioning
with
a
ver
fin
v
si.
That's
always
managed
within
a
single
context.
H
H
That's
what
the
root
is
all
about:
yell
any
root,
but
that's
only
Matt
and
that's
only
accessible
when
managed
equals.
True,
if
you
were
building,
let's
say
NFV
style
routers,
where
they're
running
in
VMs,
you
would
just
set
it
to
false
because
it
wouldn't
be
able
to
manage
it
from
the
top
and
that's
going
to
be
a
pretty
common
use
case.
We
also
have
some
air
events
to
deal
with
late,
binding
problems.
D
F
Dan
Bogdanovich,
so
this
is
a
work
that
Raymond
and
I
did
and
we'll
share
some
of
the
experiences
and
some
of
the
problems
you
might
be
facing.
If
you
try
to
implement
this
so
this
the
example
we
are
covering,
essentially
where
you
have
an
L
any
spanning
on
two
physical
devices
as
well,
when
you
are
doing
and
Elleni
on
another
physical
device,
the
some
of
the
problems
that
you
will
run
into
that
will
be.
F
They
cannot
be
managed
outside
of
the
you
know,
outside
of
the
scope
of
the
potential
in
this
case
is
the
virtual
router.
So
we
an
interface
naming
when,
when
you're,
defining
that
you
have
to
come
up
with
a
pretty
good
schema,
how
you
want
to
name
them,
because
you
can
have
an
interface
on
a
device
one
and
an
interface
on
the
device.
Do
they
have
exactly
the
same
name?
And
the
question
is
now:
how
will
you
name
those
interfaces
when
there
will
be?
F
You
know
essentially
bound
to
your
virtual
rather
one
and
virtual
rather
two,
which
are
the
two
instances
of
an
Elleni,
and
essentially
you
have
you
know
you
can
have
now
two
ways
in
the
schema
that
you
just
use
the
device,
the
physical
device
name
with
interface
name,
and
for
that
one.
So
we
had.
We
were
thinking
bit
between
both
options,
but
we
went
which,
with
enough
that
doesn't
requires
changes
in
Yanks.
So
in
this
case
it
is
pretty
easy
to
find
out
which
physical
interface
is
on
which
physical
device.
F
But
you
know
the
whole
point
here,
is
that
you
also
have
to
figure
out
how
you
can
take.
You
know
the
multiple
leaf
wraps
in
order
to
get
you
know
to
the
new
value,
because
it's
a
whole
panniers,
but
how
can
they,
you
know,
combine
the
physical
device
ID
with
the
ports
on
the
other
part,
when
you
are,
you
know
having
a
essentially
one
Elleni
across
multiple
physical
elements.
F
There
is
a
question
if
you
want
to
have
capabilities
like
an
aggregated,
Ethernet
interface
and
the
questions
are
rising
when
you
have
different
capabilities
of
a
data
point.
So
how
do
you
want
to
support
the
that,
when
your
capabilities
and
the
resources
of
a
data
plane
are
not
heterogeneous
or
you
will
just
go
essentially
with
the
same
types
of
Asics,
then
you
can
easily
track
the
capabilities
and
resources.
So
this
is
something
that
you
have
to
think
upfront.
F
F
There
we
were
thinking-
maybe
you
know
dynamic-
that
might
do
the
work
as
well,
but
for
some
reason
you
know
we
have
decided
to
go
with
the
setting
up
here
is
a
specified
pool
of
addresses
with
you
have
to
know
how
many
you
know
Ella
needs
you
have
to
address
upfront
and
then
essentially
take
it
from
there
from
a
performance
and
the
scaling
point
of
view.
This
works
pretty
well
for
us,
so
we,
you
know,
had
a
pretty
good
experience
with
this
one.
F
F
M
Rick
Taylor
I'll
give
you
an
answer
at
the
mic
to
why
we're
using
Ellen
YZ
and
it's
to
reduce
complexity.
The
hardware
is
getting
increasingly
complex
and
it
means
that
the
end
users
who
were
actually
having
to
use
this
kit.
It
becomes
much
simpler
to
talk
about
logical
constructions
and
then
they
don't
really
care
about
which
model
they
bought
and
how
many
internal
back
planes
and
stuff
it's
it's
in
there.
So
it's
it's
really
ease
of
use.
We
found
some
real
advantage
to
going
down
the
LME
model.
N
Stephan
caste
from
a
range
I
mostly
agree
with
what
has
been
said
here.
We
are
not
using
logical
system
now,
because
we
don't
have
the
exact
separation
that
we
want
so
especially
on
some
specific
cultures
that
are
supporting
logical
system.
Today,
it's
we
are
only
separating
the
routing
path,
but
not
the
management
and
all
the
other
processes,
but
we
are
looking
for
this
kind
of
full
separation,
including
all
the
processes
of
within
a
router.
N
So
we
are
doing
some
testing
on
new
features
today,
because,
yes,
we
want
to
reduce
the
complexity
of
our
routers
because
running
a
lot
of
services
and
VPN
layer,
2,
VPN
layer,
3
VPN
on
the
same
device
is
really
complex
today
and
it's
not
really
maintainable
over
time.
So
we
need
to
split
so
it's
clearly
interesting.
It's
not
doable
now
it
may
be
doable
in
future.
So.
F
N
Not
only
a
question
of
configuration
management,
it's
just
a
question
and
when
you
have
a
router
one
engine
but
tons
of
features,
it
does
not
work,
because
there
is
a
lot
of
bugs
and
one
bug
and
one
particular
service
will
prevent
you
to
install
a
version
how
to
say
that
yeah.
Let's
say
that
I
have
a
router
running,
VPN
layer,
2,
VPN,
a
of
European
Internet
services,
and
you
want
to
great
business.
N
F
H
At
the
request
of
the
chairs,
we
brought
back
some
material
that
has
been
presented
a
pre
or
private
previous
IETF
s.
We're
happy
to
go
through
this
at
the
level
that
makes
sense
for
the
room.
If
what
we're
saying
people
feel
like
we've
done
it
already,
I
don't
need
to
say
it
again,
so
we
can
get
some
time
back
for
an
early
lunch
or
we
can
spend
the
rest
of
the
time
going
through
these
few
slides.
It's
really
the
chairs
call
your
call.
H
So
what
that
means
is
ask
questions
and
if
I'm
just
talking
to
a
quiet
room,
everyone
just
typing
away
and
no
one's
really
interested.
We
should
stop,
but
your
call,
so
most
of
these
slides
are
taken
from
that
discussion
that
took
place
the
last
meeting
in
the
l3
VPN
context.
In
the
best
working
group
there
are
one
or
two
other
slides
at
the
very
end
which,
from
other
or
from
other
meetings.
H
So
generally,
when
we're
talking
about
how
do
we
do
VPN
support?
We
want
to
look
at
our
logical
network
element
model
behind
me,
so
you
can
find
that
in
graphed,
ITF
routing
Network
instance
model.
The
version
here
is
wrong,
because
this
is
from
the
last
ITF
there's
a
new
version
on
it,
but
there's
not
anything
really
major
chain,
just
a
couple
of
syntax
changes,
but
those
aren't
material
for
understanding.
H
What
we're
doing
the
key
thing
that
we're
doing
is
we're
creating
a
list
to
represent
each
birth
or
vsi,
and
we
soever
every
layer,
3
VPN
layer,
2
VPN.
We
call
that
generically
a
network
instance.
We
also
recognize
that
some
instances
or
bridge
router
instances,
so
they
do
both
layer,
2
and
layer
3,
and
we
cover
that
case
as
well.
H
When
looking
at
how
to
model
a
VPN,
we
have
some
set
of
information
that
ends
up
actually
most
of
the
information
for
controlling
that
VPN
ends
up
inside
the
core
instance
really
think
about
it,
as
it
belongs
to
the
PE
alone.
It
doesn't
have
any
information
that
ends
up
at
getting
communicated
to
a
seee,
so
think
of
that
as
your
Artie's,
your
RDS,
some
of
your
label
management
policies,
those
those
types
of
things
are
really
belong
to
the
PE.
Where
do
those
go?
H
H
It's
just
existing
information,
for
example.
If
we
want
to
run
BGP
to
between
this
as
Darcy
eep-eep
protocol,
we
need
a
whole
BGP
model
and
we
need
a
place
to
put
it.
If
we're
running,
let's
say
an
l2
VPN
and
we
want
to
instantiate
I,
don't
know
some
I
Triple
E
model
that
supports
the
ce2
PE
communication.
We
need
a
place
to
instantiate
that
and
we
it's
that
we
place
that
underneath
are
different
types
of
routes.
H
H
So,
what's
the
ni
type
for
l3
VPN?
Well,
it's
just
like
in
a
new
container
which
is
augments
the
anti-type
and
has
all
the
information
that
is
specific
to
configuration
of
an
l3
VPN.
If
you're
interested
in
what
that
actually
looks
like
we
can
actually
bring
up
the
individual
and
bring
up
the
draft.
That's
now
published
as
draft
IETF,
best
l3,
VPN,
yang
and
I.
Don't
remember
if
it's
yang
model
or
just
yang,
it's
just
yang
and
that's
you'll,
see
that
that
draft
actually
does
that.
H
So
we
have
all
the
PE
information
sitting
here
and
then
for
within
the
context
of
the
l3
VPN.
We
just
mount
a
new
instance
or
per
anti
instance
of
existing
models.
The
same
thing,
the
same
models
that
you
would
see
for
the
core,
but
now
you
have
data,
that's
instantiated,
just
for
that
specific
VPN
and
there's
no
modification
there
to
those
models
at
all.
H
In
the
rare
case
that
you
actually
have
a
modification
and
we
haven't
figured
out
one
of
those
yet
by
the
way
we
keep
thinking,
we're
gonna
have
them
and
then
we
know
we
go
through
the
details.
But
if
you
do,
you
could
just
look.
You
can
just
augment
the
model
that
you
have,
as
as
you
need
and
instantiate
it
only
for
the
l3
VPN.
H
H
So
in
this
case
the
mount
point
called
ver
fruit
and
we
need
a
way
of
doing
that,
because
a
new
way
of
doing
it,
cuz
laying
library,
doesn't
have
it.
The
mechanism
that
we're
using
is
something
now
called
schema
mount
so
in
schema
mount
you
can
identify
a
mount
point.
The
way
you
do
it
is
you
identify
the
model.
Well,
the
model
is
missing
here,
but
that
we
have
our
model
name,
which
is
the
network
instance
name,
and
then
the
mount
point
within
it
called
were
fruit.
H
And
then
you
list
exactly
the
same
information
you
would
list
for
the
top-level
in
that
lot.
Yang
library,
in
fact,
yang
library,
defines
a
grouping
and
we
just
scheme
them
out
just
reuses
that
same
group,
so
you
describe
on
the
router,
describes
exactly
what's
going
to
show
up
here.
So
it's
an
implementation
time
decision
how
you're
going
to
how
a
router
is
going
to
represent
its
verse
or
vs
is
to
its
to
the
clients
of
the
network
manager.
H
So
most
of
what
we're
talking
about
here
is
a
framework
for
implementation
and
giving
implementers
vendors
the
tools
they
need
to
go
represent
the
the
logical
partitioning
of
the
system,
the
verbs
in
a
way
that
is
consistent
for
operators
or
vendors
of
network
management,
software
to
go
use,
I've
talked
so
far
about
where
PE
information
goes.
That's
per
network
instance
I've
also
talked
about
where
si
EPE
information
was
there's,
actually
a
third
class
of
information,
which
is
because
you
are
a
core
router.
H
There
are
some
system-wide
configuration
parameters
that
are
specific
to
the
fact
that
you
run
VPNs.
Where
does
that?
Go
doesn't
make
sense
to
put
it
anywhere
on
this
page,
because
this
is
per
instance.
That's
it's
perverse,
but
what
I'm
talking
about
here
is
a
third
class
of
information
that
is
box
Y.
Where
would
that
go?
It
actually
doesn't
belong
in
our
model.
It
belongs
in
either
an
augmentation
to
an
existing
protocols
such
as
BGP
or
in
the
case
of
like
pseudo
wires.
It's
actually
a
new
model
completely,
and
that's
what
we're
gonna
see.
H
H
H
On
I
have
two
slides
on
Elleni:
this
is
what
the
model
that
Dan
was
talking
about.
The
difference
between
what
I'm,
showing
here
and
what
Dan
showed
is
Dan
actually
built
a
early
implementation
based
on
our
work.
This
is
theoretical,
so
you
know
this
is
sort
of
more
generic,
it's
more
applicable
to
anyone.
His
is
an
actual
example,
but
which
one
is
more
applicable
to
you.
Maybe
whether
or
not
it
depends
on
whether
or
not
Dan's
example
is
close
to
your
example
or
not.
H
H
We
think
that
there's
a
multiple
pieces
that
are
going
to
be
important
like,
for
example,
if
you
had
QoS
resources,
we
think
that's
going
to
be
an
important
thing
to
partition,
but
we
had
we
don't
have
any
really
good
standard
models
that
identify
resources
today
inside
the
ITF
other
than
interfaces.
So
the
only
thing
that
we
worry
about
partitioning
at
the
moment
is
interfaces,
so
we
have
the
ability
of
taking
an
interface
and
basically
assigning
it
to
a
logical
network
element.
We
do
that
through
an
augmentation
that
was
on
the
previous
slide.
H
The
other
thing
we
think
is
important
to
be
able
to
support
is
the
ability
to
support
different
management
models
that
we
have
in
logical
systems
in
a
vert
based
approach.
Sorry,
a
vm
based
approach,
typically
there's
no
way
for
let's
say
the
hypervisor
or
the
host
to
manage.
What's
going
on
inside
the
VM,
there's
no
visibility
across
there.
H
So
we
represent
that
with
the
man
in
flag
being
set
to
false
in
a
more
traditional
router
based
system,
the
top
level,
the
core
router,
for
instance,
actually
can
look
in
and
change
things
that
belong
to
the
logical
system.
We
support
that
as
well.
We
support
it
using
two
P
two
items
use
that
MANET
equals
true,
and
then
you
have
a
route
mount
point
in
that
roof.
Mount
point
like
we
talked
about
in
the
NA
case.
That
route
mount
quite
could
be.
H
So
what
we
have
here
is
an
example
of
that
think
of
it
as
the
metal
device
the
base
device.
It's
got
a
piece
of
hardware,
it's
got
some
interfaces
and
it's
got
a
list
of
logical
network
elements.
In
this
case
we
instantiated
two
logical
network
out,
actually
sorry,
three
logical
network
elements,
the
blue,
logical
network
element,
the
Red
Lodge
element
and
the
green
one
inside
from
the
top
level.
You
can
actually
in
the
manage
true
equals
case.
You
can
see
all
the
information
you'd
fold
less
on
the
left
side
of
the
page.
H
So
if
you're
coming
into
the
core
manager,
you
can
see
everything,
but
if
you're
within
the
instance,
let's
say
I'm
inside
the
red,
I'm
customer,
red
and
I
have
I
come
into
the
network
management
interface
in
the
red
space
through
an
interface
that
belongs
to
red.
This
is
the
management
channel,
but
Dan
was
talking
about
earlier.
You
wouldn't
see
everything,
but
only
the
pieces
that
belong
to
red
and
likewise
vice
customer
green
and
only
get
to
see
greens
information.
H
So
we
would
start
out
from
a
top
level
where
you
have
a
system
that
has
a
full
set
of
resources:
the
full
stand,
ident,
understanding
of
full
set
of
resources
in
and
also
a
full
set
of
all
the
parameters.
And
then
we
have
customer
specific
views
that
are
coming
in
through
the
system,
management
protocols
and
interfaces
that
are
configured
for
that
customer.
H
D
So
like
to
thank
you,
outing
young
design,
team
for
taking
diamond
effort
and
helping
everybody
to
better
understand
if
you've
got
any
questions
and
especially
does
that
we
are
going
through
implementations
and
you
could
provide
feedback
what's
working.
What's
not
working
would
be
extremely
useful.
You
know
and
I
have
you
request
to
design
team
for
the
next.
Eighty
eight
meeting
probably
talk
about
interacting
with
service
models,
so
another.