►
From YouTube: IETF100-IDR-20171113-1330
Description
IDR meeting session at IETF100
2017/11/13 1330
https://datatracker.ietf.org/meeting/100/proceedings/
B
B
B
This
is
the
IDR
meeting
we're
only
meeting
once
we're
running
until
three
o'clock:
3:30.
Okay,
so
folks
we
don't
have
a
real
packed
agenda.
You
can
come
to
the
mic
and
discuss
things.
I
am
going
to
note
that
there
is
the
note
well
that
you
may
have
read
this
before,
but
please
read
it
again
that
everything
that
is
said
here
that
you
say
in
a
working
group
or
any
buff,
if
you
say
it
at
the
mic,
it's
tender,
the
IPR
rules
and
these
contributions
are
subject
to
our
c-53
78
and
RFC
81
79.
B
Now
I
am
going
to
go
over
RC
81
79,
because
we
had
a
little
hiccup
in
our
one
of
our
working
group
processes
this
last
month.
That
was
the
late
IPR
discussion.
So
I'll
go
through
in
case
someone
missed
how
to
do
that.
It's
always
good
to
refresh
RFC
81
79,
and
all
of
these
contributions
should
adhere
to
the
best
practice.
So
let's
go
through
the
IDR
agenda
and
do
our
agenda
bashing.
That
means
don't
come
up
and
bash
the
chair.
That
would
be
not
nice,
but
everything
else.
B
Our
agenda
John,
is
not
here
this
week.
Ji-Dong
is
kindly
helping
me
Ignace
is
kindly
providing
scribing.
Thank
you
to
both
of
them.
She
is
our
secretary.
We're
going
to
do
a
gender
bashing
and
chair,
slides
part
of
the
chair,
slides
is:
did
we
get
all
the
drafts
sent
forward
that
you
asked
for?
Have
we
missed
anything
so
pay
attention
in
case
your
draft
needed
to
go
forward
and
we
missed
it
and
then
I'll
go
through
the
IPR,
because
we
had
a
late
discussion
and
then
we're
going
to
go
through
existing
drafts.
B
Günther
congestion
control,
bgp
extensions
for
PC
discovery,
then
we're
going
to
go
through
new
work,
which
is
a
BGP
model,
the
link
state
and
some
segment
routing
was
there
anything
else
that
we
should
add
to
this
notice.
This
is
a
light
agenda.
You'll
probably
end
up
with
extra
time,
so
don't
have
a
problem
with
comments.
Okay,
comments,
questions,
bashing,
Samuel
and
working
groups
are
great
after
lunch.
Okay,
this
is
a
Mia
Copa
from
your
chairs.
We
have
been
swamped
by
life
outside
John
and
I
are
both
encountering
some
unusual
things.
B
Usually
we
trade
terms
and
John's
a
very
good
co-chair
with
me.
He
usually
picks
up
the
slack
or
I
pick
it
up
with
him,
but
we're
in
the
most
most
in
the
midst
of
waves
and
G,
and
other
people
are
helping
us,
but
if
we've
missed
something
John
and
I
humbly
apologize,
but
tell
us
what
we've
dropped,
we're
trying
to
catch
things
up.
Okay,
these
are
the
drafts
that
are
past
working
group.
Last
call.
B
My
understanding
is
that
Alvaro
was
also
having
one
of
his
transitionary
times
with
having
switched
jobs,
so
he
has
two
of
the
drafts
of
the
rsd,
which
have
been
there
for
over
a
hundred
and
twenty
days.
So
they
went
to
him
before
last
ITF
and
they're
still
sitting
there
Mia
Copa
on
Alvaro's
part.
He
promises
that
when
he
returns
he
will
work
on
it.
There
are
five
dress
awaiting
Shepards
report.
It
is
my
intent
to
sit
down
in
the
bar
and
just
get
through
the
Shepards
reports
these
next
couple
days.
B
There
is
one
Shepherd
report
we
could
really
use
some
help.
One
of
these
are
my
RFC
5575.
This,
probably
if
you
would
like
to
be
a
shepherd
on
any
of
these
drafts,
that's
a
position
to
which
your
chairs
will
buy
beer
thanks
and
very
good
things,
but
otherwise
we'd
really
like
help
and
I'll
try
to
clear
these
Shepherd
reports
within
two
weeks,
John's
got
half
of
it
done
and
so
he's
really
prepared
a
lot
of
things.
Okay,
early
allocations:
these
are
the
ones
we
think
we
did.
I
checked
them
in
the
repositories.
B
Did
we
miss
any?
If
so,
send
a
note
to
the
chairs
and
we'll
try
to
get
those
done
again?
Send
it
to
me
today
and
I
will
try
to
send
it
to
the
I,
Anna
and
Alvaro
this
week
and
see
if
we
can
get
some
progress.
Please
read
it.
These
slides
are
all
online
thanks,
Gigi,
okay,
working
group
action.
We
have
two
working
group
last
calls
in
progress
both
of
those
were
requested
by
other
working
groups.
The
trill
is
in
progress,
there's
some
people
who
said
they
wanted
to
comment
this
week.
B
So
we've
left
it
open
the
BGP,
extended
messages,
I
just
started
off
today
that
fell
between
the
time
when
John
and
I
both
got
overwhelmed
by
stuff,
so
Thank,
You,
Randi
and
other
co-authors
care
for
the
patients.
I
don't
have
any
adoption
calls
John
went
through
the
adoption,
calls
and
asked
people,
and
they
all
said
well
we're
going
to
make
a
little
change.
B
B
These
are
the
thought
things
that
last
time,
that's
the
pointer
to
the
last
ITF
action
list.
These
are
the
following
that
adoption
calls,
but
they
didn't
seem
to
get
any
further
response
if
you
still
want
them-
and
there
are
a
couple
there
that
are,
we
ready
for
last
call
John
checked
on
this
segment,
routing
ones,
and
they
said
they
were
going
to
work
on
it.
If
there's
something
we've
missed,
please
let
us
know:
do
you
have
any
questions.
B
B
So
let
me
go
through
the
basic
IPR,
proper
rules,
the
problem
and
then
solutions
that
other
working
groups
of
taking
John
and
I
tend
to
trust
you
all
you've.
You
know
you
guys
run
them
Internet.
You
do
a
really
good
job
and
we
tend
to
trust
so
I'd
like
to
continue
in
the
trust
model
and
not
the
model
that
other
working
groups
may
take.
So
let
me
go
through
the
RFC,
81
89
and
hopefully
I've
not
transposed
that
number.
B
It
was
the
one
you
saw
earlier
has
IPR
disclosures
that
can
either
be
made
by
the
author,
someone
contributing
or
knowing
that
someone
else's
technology
is
impinging
on
their
patent
voluntary
disclosures
of
well,
they
told
me
there
were
some
IPR
there
and
that's
how
it
gets
put
in
now.
There
is
an
RFC
that
specifies
if
you
don't
behave
well
in
disclosing
IPR,
there
can
be
sanctions,
so
look
at
RFC,
7001,
again,
John
and
I
would
prefer
not
to
him.
But
those
sanctions
include
taking
an
author
off
a
draft.
B
If
it's
an
author
base,
they
include
taking
a
draft
out
of
Internet
standard
and
moving
it
someplace
else.
So
it's
all
about
timing.
The
the
phrase
that's
used
is
reasonably
possible.
After
the
contribution
is
exhibition,
when
the
technology
has
changed,
and
you
add
a
pan
I
PR
or
when
the
the
whole
purpose
behind
of
this
is
to
make
sure
that
people
are
informed
when
they
agree
to
a
standard.
Do
you
know
that
has
IPR?
If
you
know-
and
you
agree
wonderful
working
group
and
many
times
IDR
will
say
that's
great.
B
B
B
Lastly,
here's
our
problem
draft
ITF,
IDR,
BGP
optimum
route.
Reflection
had
a
late
IP.
Our
discussion
when
I
come
to
working
group
last
call
and
we're
two
weeks
into
working
group
last
call
and
about
to
close
it.
That's
a
very
late
IP.
Our
discussion
that
almost
borders
into
the
cases
in
the
RFC's
for
some
sort
of
action,
but
the
good
news
is,
we
asked
all
of
you
and
this
mail
message
and
said:
do
you
think
it's
a
problem?
Nobody
responded
and
John
and
I
will
often
said,
say
something
if
you
think
it's
a
problem.
B
The
duty
of
an
oven
chair,
one
of
my
wonderful
duties,
I'll,
make
a
face
at
that
is
to
say
in
a
working
group
that
you
did
this
and
that
nobody
really
said
anything.
If
you
think
there's
a
problem
with
this.
Please
come
talk
to
myself
and
G
as
John's
a
person
or
talk
to
Ignace
and
he
will
Fordyce
to
us,
because
this
is
part
of
the
call
that's
referenced
in
all
of
these
RFC's
okay.
B
The
time
that
you
get
asked
is
when
you
have
working
adoption
of
an
individual
contribution
and
working
group.
Last
call
you
know,
and
we
also
don't
do
what
other
working
groups
do
and
they
do
an
IPR
call
before
they'll
start.
The
last
call,
mostly
you
all,
are
really
good
about
coming
to
IPR
responses,
and
so
we
tend
to
do
it
in
parallel,
because
it
saves
us
time.
B
B
B
E
D
Try
this
one
not
a
problem,
so
the
reason
actually
I
asked
this
particular
slot.
Here
is
because,
once
you
know,
when
we
create
this
document,
we
went
from
a
certain
assumption
that
the
readable
label
depth.
You
know
the
main
use
case
was
actually
to
you
know
to
actually
use
it
for
entropy,
and
that
is
a
fundamental
assumption
we
actually
made
so
just.
D
D
You
thank
you
so
now
over
time
you
know
it
looks
like
there
may
be
other
use
cases
that
can
use
you
know
the
readable
label
depth
so
something
when
I'm.
You
know
trying
to
assess
with
this
particular.
You
know
slot
here
is
to
understand
that
the
simplification,
what
we
have
made
by
contracting
and
putting
and
both
of
them
together
into
a
single
you
know
signaling
BGP
LS.
Is
you
know
if
the
simplification
is
good
enough?
You
know
to
justify
the
restriction
which
is
imposed,
so
let's
have
a
quick
look
into
it.
D
So,
at
the
end
of
this
session,
what
I
would
like
to
you
know
a
shave
is:
do
you
know
to
learn
from
you
on?
You
know
to
separate
you
know
the
entropy
label
capability
again
from
the
readable
label
depth
so
that
we
can
actually
allow
more
use
cases
towards
the
future
or
that
we
will
keep
the
eld.
You
know
entropy,
readable
layer.
You
know,
label
depth
itself.
Let's
have
a
quick
look,
so
the
concept
is
simple,
and
so
the
adult
did
readable
label
depth
is
something
that
you
signal.
D
The
router
signals
to
you
know
in
BGP
LS
to
say,
like
a
you
know,
you
know
if
I
get
a
packet
in
these
are
the
amount
of
labels.
I
can
actually
read
and
do
something
with
the
entropy
label
capability.
You
know,
is
a
router
signaling,
you
know
through
you
know,
it's
mechanisms
say
like
okay:
I
can
do
entropy
and
I
understand
entropy
label
from
it.
So
that
is
it
so
the
way
they
are
be
used
in
IAS
and
in
OSPF
you
know
in
the
IDPs
is
they're
like
two
independent,
you
know
indicate
it's
a
so.
D
The
readable
label
depth
is
sent
independently
from
the
interview
label
capability.
So
they're
like
two
different
signals
here.
So
what
we
have
done
with
the
beach
pls?
Is
we
set?
Okay?
You
know,
you
know
if
the
only
use
case
for
the
readable
label
depth
is
to
you
know,
have
awareness
of
that
for
entropy,
then
why
do
we
need
to
have
these
two
signals,
so
we
can
sort
of
like
put
them
together.
D
So,
instead
of
signaling,
you
know
independently
the
aroldi
and
signaling
independently
the
entropy
label
capability,
we
sort
of
gluten
together,
and
we
said:
okay,
if
you
actually
receive
you
know
the
the
entropy
cable,
readable
label
depth,
then
you
know
that
the
amount
of
labels
you
read
and
at
the
same
time
you
know
that
is
what
you
can
use
for
entropy
also.
So
that
is
the
assumption
we
made.
That
is
what
is
in
the
document
right
now
and
even
though
the
document
you
know
is
in
a
fairly,
you
know,
fine
state.
D
We
have
not
actually
asked
for
any
earlier
locations
or
whatever,
because
I
was
you
know,
I
wasn't
really
sure
that
was
the
right
thing
to
do.
So
what
I'm
actually
verifying
here
is
you
know
if
the
assumption
we
make
is
the
correct
one,
because
if
you
look
into
you
know
how
technology
has
progressed,
there
seems
to
be
like
another.
You
know
use
case
emerging
here
which
has
to
do
with
like
alternate
marking
where
you
start
using
some
of
these
potential.
D
You
know
MPLS
labels
and
you
use
them
not
for
entropy,
but
we
you
actually
use
them
for
passive
performance
measurements.
So
that's
a
different
use
case.
So,
knowing
that
know
is
the
assumption
we
made
that
we
actually
know
signal.
You
know
entropy
and
readable
label
that
in
a
single
parameter
it
is
still
valid,
yes
or
no.
So
that's
actually
what
I
would
like
to
ask
you
know
and
any
thoughts
on
this
particular
you
know
element
so
itself.
Yes,.
F
So
so
initial
use
case
was
indeed
entropy
levels,
so
what
I
see
being
published
for
accounting
and
some
other
things
would
require
additional
pair
of
labels
being
pushed
and
not
only
pushed
on
ingress
but
also
read
in
the
transit.
So
I
think
this
work
is
becoming
more
relevant,
more
important
to
be
able
to
figure
out
if
accounting
is
mandatory,
how
deep
should
it
go
so
I
wouldn't
say
it's
really
belongs
in
PC
computation,
but
awareness
of
how
deep
I
can
go,
read
and
create
forwarding
state
and
counter
associated
with
it.
It's
quite
important
so
so.
D
F
D
So
just
to
confirm,
then
so
what
you're
saying
is
that
you
have
a
preference
for
signaling
the
readable
label,
depth
and
then
have
like
independent,
like
you
know,
big
parameters,
kind
of
thing
like
you
know,
this
can
be
used
for
entropy
labels.
This
can
be
used
for
marking
this
can
to
segment
it
up
like
that
or
hard.
Or
how
do
you
see
this
and
it.
F
F
D
So
but
the
thing
is
that
you
know
you
can
actually
signal
the
readable
space,
but
at
the
same
time
you
signal
the
capability
of
the
router
to
do
something
with
it
and
have
to
do
something
with
it
is
you
know
to
actually
use
for
entropy
to
use
the
passive
marking
to
use
it
for
something
which
maybe
it's
not
being
documented?
Yet
in.
F
G
Stephanie
from
Orange
speaking
Escoto
of
the
mpls
spring
and
hopi
label
draft.
So
based
on
the
discussion
we
had
in
Chicago,
so
we
concluded
that
this
aroldi
notion
that
we
first
defined
was
not
enough
because
we
did
not
add
the
knowledge
about
the
ability
of
the
router
to
really
read
the
entropy
label
within
visceral
Gianna's.
That's
why
we
concluded
that
this
energy,
which
became
now
the
entropy
aroldi,
is
something
that
includes
the
ability
to
read
the
entropy
label
within
this
amount
of
label.
G
D
G
G
H
Thank
you,
I
trying
to
chill
cool
I
was
gonna.
Just
say
that
conceptual
you
can
imagine
in
the
spring
use
case
that
the
controller
can
make
more
intelligent
traffic
engineering
optimizations,
depending
on
the
readable
way
to
Google
death
and
not
require
the
deployment
of
entropy
levels.
So
it
seems
that
having
there
was
separate,
signaling
mechanisms
might
be
useful.
I.
D
H
D
Interesting
so
I
heard
like
two
different:
you
know
positions
here
and
I
still
don't
know
how
to
progress.
So
any
indication,
maybe
from
the
chairs
on
on
how
to
tackle
this
one,
to
keep
it
as
aroldi
like
we
have
right
now
and
then
the
document
is
nearly
complete
and
we
can
go
further
with,
like
you
know
earlier,
tasking
early
code
requirements
or
we
actually,
you
know
plate
it
up
again.
You
know
it's
relatively
easy
to
do
the
progress
you
know
to
make
the
modifications,
but
only
I
would
desire
to
do
them
only
once
vinter.
F
G
B
I
F
I
E
B
B
Asked
me
was
to
uplevel
that,
as
far
as
when
he
could
go
to
a
drafted
option,
I
said
when
he's
checked
things
and
he's
ready,
send
me
and
we'll
we'll
do
that.
The
other
question
was:
how
does
he
get
input
from
the
rest
of
the
world?
Please
float
this
to
the
mailing
list
because
we
don't
have
everyone
here
this
ITF
because
of
the
distance,
so
they
make
sure
he
gathers
all
the
right.
But
so
you
heard
personal
opinion
process
how
to
get
in,
pin
right
and.
K
L
E
E
M
M
D
E
B
F
F
The
authors
of
the
IGP
drafts
are
in
the
room:
each
should
take
as
long
as
15
minutes
to
do
the
job,
but
besides
it
so
as
part
of
talking
on
behalf
of
MSD
authors,
we've
created
separate
I
on
a
registry
for
MSD
types.
So,
rather
than
creating,
and
we
discuss
proposal
before
rather
than
creating
separate
registry,
it
could
cause
MSD
subtype
and
reference
it
from
this
document
and
I
mean
it
would
be
logical
to
me.
But
it's
really
up
to
you.
G
Stefan
again
regarding
the
mpls
document,
so
there
was
a
last
call,
walking
or
plastic
or
without
one
year
ago,
which
failed,
but
we
normally
fixed
all
the
issues.
So
I
expect
a
new
working,
hopeless
coal
to
be
to
be
sent,
and
maybe
the
good
idea
is
to
wait
for
all
this
working
group
last
call
and
ensure
that
we
are
working
up
concerns
to
to
ensure
that
we
can
hog
I,
see
a
GP
and
send
bgp
documents
is.
N
N
The
link
congestion,
severe
stators,
includes
the
link
band
well
and
if
utilization
egress
here
engineering
using
BT
be
labeled,
unique
health
protocol
needs.
This
kind
of
information
to
eight
am
just
draw
trust
to
to
do
traffic
engineering.
Our
interests
beings
in
constraint,
multiple
passes
across
from
France
télécom
I,
wanted
to
use
the
link
congestion
information
as
a
metric
to
select
the
appropriate
path
among
motivated
passes
their
purpose.
What
to
do
proactive
reaction
to
the
congestion
events
to
aid
a
router
to
perform
an
equal
cost
load
bars?
N
Let
me
use
this
paper
to
show
the
general
benefit
of
knowing
the
congestion
theaters
for
the
big
via
speaker
within
one
is
a
router,
seven
and
Roger
age.
Here
are
their
internal
BGP
peers
in
autonomous
a
of
system,
a
the
congestion
status
of
the
Earthlings.
The
peers,
in
turn,
can
steer
some
outgoing
traffic
towards
the
last
loaded,
active
Inc
for
Big
B
speakers
across
multiple.
Yes,.
N
Si
should
steer
some
ASE
access
traffic
to
the
link
between
rod,
one
and
job
states
for
Fortune
mobile.
Our
province
networks
want
to
use
this
kind
of
information
to
do
a
South,
Korean
load
balance.
Our
network
quality
is
similar
to.
She
was
just
to
this
paper.
Si
is
our
province.
Network
SB
is
our
backbone
Network,
when
the
exceeding
an
ESD
is
the
the
network
operated
by
other
carriers.
N
According
to
the
comments
and
suggestions
in
the
Middle
East
and
in
the
previous
mediums,
we
provides
several
solution
alternate.
She
was
in
in
current
version
solution.
One
is
two
years
dependent
community.
We
need
a
new
tab
for
or
we
need
new
sub
tab
for
for
the
Octavia
community.
We
have
presented
this
this
delusion.
N
Sometimes
a
strawberry
is
the
size
over
the
bandwidth
field.
We
can
only
as
an
idea
for
this.
Do
you
choose
the
limited
space
solution
to
is
to
use
a
large
community?
It
seems
that
we
have
no
way
to
to
to
to
to
to
divan
a
sub
tab
of
large
community
to
be
the
congestion
as
the
virus
community.
So
this
this
Trojan
ship
to
be
invisible
and
for
a
solution
straight
to
your
community
container
community
container
it.
N
It
was
pair
with
flexible
encoding
format
at
present
own
and
help
one
is
defined
for
for
white
community,
and
we
want
to
give
out
another
one
for
the
congestion
status
community
with
the
38
encoding
formats
show
its
favor,
because
we
have
enough
space
so
in
this
Trojan
wouldn't
defend
the
bandwidth
field
as
as
for
obvious.
So,
as
unit
can
be,
millisecond
can
be
million
bits
per
second.
N
N
N
N
N
So
for
this
medium,
we
do
not
want
to
talk
more
about
the
details
of
the
solution.
What
we
want
is
to
justify
our
purpose
and
the
problem
and
the
final
solution
can
be,
can
be
computer
and
improved
after
this
world
is
an
object
by
the
working
group.
So
I
think
the
problem
we
want
to
solve
is
clear
and
some
corrosion,
our
alternatives,
are
all
right
there,
so
I
think
this
work
should
be
considered
to
be
accepted,
accepted
as
working
group.
D
Rubber
traffic
Bloomberg
I
have
a
question.
So
how
do
you
plan
to
deal
with
the
case
when
you
have
not
one
but
n
different
links
between
to
ASB
ours
and
single
ebgp
session?
Let's
say:
we've
disabled
connected
check
and
on
all
of
those
things.
Utilization
is
different.
One
is
twenty
percent.
One
is
eighty
percent
because
they
were
hashing
is
bad,
let's
say
so.
How
do
you
signal
this
particular
scenario
in
your
proposal?.
N
J
O
Kind
of
the
idea
of
having
some
indication
of
load
and
congestion
on
several
paths
to
be
an
important
input
for
routing
decisions
is
clear,
but
when
one
defines
a
specific
coding
scheme
to
signal
that
I
think
I
think
the
ideas
of
well
okay,
how
to
how
to
how
to
derive
well.
Okay,
that's
partly
done
in
the
in
the
draft
how
to
derive
the
actual
signal
from
observations
and
what
to
do
when
you
see
the
signaling
I
think
I
think
needs
to
be
done
and
while
okay,
the
considerations
on
oscillation
quite
certainly
are
kind
of
crossing.
O
That's
a
territory,
but
kind
of
that
does
not.
That
does
not
look
like
anything
that
allows
to
prove
that
oscillation
can
be
avoided,
cannot
happen
rather,
while
okay,
let's
see
and
observe,
and
then
and
then
and
then
fix
whatever
we
implementation
and
configuration,
is
in
the
complex
in
the
complex
interworking
of
bgp
systems.
That
does
not
look
like
real
convincing
approach
to
me,
though.
It
has
been
taken
in
the
past
once
in
a
while
I
have
to
admit
I.
B
Would
recommend
you
take
a
couple
of
these
examples
to
the
list
and
to
get
more
feedback?
I
would
recommend
you
take
a
couple
examples
like
Robert's
example
or
another
one
to
the
list
and
see
if
you
can
at
least
hear
what
people
are
are
saying
about
it.
So
I
would
recommend
you
provide
a
couple
examples
of
your
proposal
to
the
list
and
have
a
discussion
that.
I
So
the
idea
here
is
that
in
in
the
PC
architecture,
we
have
a
path,
computation
element
which
does
the
path
computation
and
you
have
the
client
which
requested
what
happens
is
we
would
like
the
PC
e's
to
be
discovered
by
the
client
automatically,
and
this
concept
has
been
there
in
the
PC
architecture.
For
the
longest
time
and
along
with
the
piece
of
protocol,
the
IGP
discovery
mechanism
was
published
long
ago.
I
Those
are
the
five
zero
eight
eight
and
five
zero
eight
nine
RFC's,
but
as
we
can
imagine
that
this
works,
when
they
participant
the
both
the
entities
are
participating
in
the
same
IGP.
So
of
course
the
PC
discovery
mechanism
does
not
work
in
some
of
the
cases
like
when
we
are
doing
inter
domain
path.
Computation
and
you
have
two
different
pcs
part
of
two
different
AAS,
and
there
is
difficulty
in
discovering
that
relationship
automatically.
Mostly,
this
needs
to
be
configured
within
the
PCE.
I
We
also
have
a
concept
of
Hirai
keys,
so
sometimes
the
top
level
PC,
which
is
the
parent,
PC
and
child
PC,
may
be
not
participating
in
the
same
ijp
or
they
might
not
be
even
even
be
nigp
at
that
layer.
So
how
do
we
discover?
Usually
you
have
stick
to
configurations
at
that
time
and
at
that
time
we
did
not
have
something
like
BGP
LS
as
well.
I
When
we
were
thinking
of
the
same
problem
now
we
have
a
BGP
LS
and
because
of
BGP
LS
there
is
a
relationship
between
the
PCC
is
exporting
the
topology
to
maybe
a
PC,
which
is
also
a
BGP
speaker
and
receiving
this
topology
information
via
BGP
LS.
So
now
the
question
also
answered:
can
we
reuse
the
same
relationship
that
exists?
The
same
BGP
session,
also
to
advertise
the
PCE
information
back
to
the
PCC?
So
that's
the
basic
motivation
and
little
bit
of
history
behind
this
work
in
the
PC
working
group.
I
So
basically,
there
are
two
modes:
either
the
PC
and
bgp
speaker
are
co-located,
which,
in
an
SDN
controller,
centralized
controller
world
is
pretty
common,
that
the
same
box
is
implementing
both
functionality,
so
it
can
use
the
bgp
session
to
advertise
or
to
let
people
know
where
the
pc
is,
what
is
the
characteristics
of
these
pcs
etc?
Now,
in
some
cases,
if
there
is
a
PC
and
bgp
of
are
two
different
entities
and
they
have
this
own
mechanism
of
how
they
are
learning
it,
the
main
idea
is
between
BGP
speakers.
I
Are
you
where
the
BGP
LS
session
exists?
We
can
also
advertise
the
PC
information
and
how
do
we
advertise
this
we'll
cover,
and
then
we
can
also
reuse
some
of
the
BGP
policy
mechanisms
to
say
on
which
session
should
be
advertised
on
which
session
is
shown
where
also
the
BGP
helps
us
much
better
than
a
simple
IGP
way
of
doing
this
right.
So
that's
the
over
overview.
How
do
we?
How
are
we
gonna
do
this?
We
propose
a
new
PC
and
lri,
and
inside
this
PC
and
lri
you
have
like
any
other.
I
You
have
the
protocol
ID,
you
have
the
identifier
and
then
the
descriptor,
which
is
the
address
of
the
PCE.
The
rest
of
the
everything
is
in
the
similar
bgp
LS
way
of
doing
things
that
you
have
tlvs
and
these
tlvs
are
kind
of
aligned
to
how
the
IGP
tlvs
are
defined
in
five
zero.
Eight,
eight
and
five
zero,
eight
nine.
I
I
That
is
what
kind
of
POD
computation
it
is
able
to
do,
and
this
semantics
is
already
defined
in
is
a
Sandoz
PF,
so
we
reuse
the
same
form
and
capability
is
what
is
the
capability
of
PC,
whether
it
can
do,
for
instance,
stateful
computations,
whether
it
can
do
multicast
in
P,
2
and
P
computations
things
like
that?
The
domain
information,
as
well
as
the
neighboring
domain
informations?
All
this
information
can
be
added
and,
of
course,
these
are
optional
information
as
well.
I
So
this
is
the
overall
like
encoding
part
of
especially
from
the
BGP
point
of
view.
This
data
is
completely
an
application
data.
It
doesn't
impact
DGP,
forwarding
or
forwarding
State
or
routing
State
in
any
particular
way.
We
would
expect
that
that
there
would
be
a
policy
that
will
play
an
important
role
in
deciding
when
this
information
can
leave
a
particular
domain,
whether
we
want
to
expose
it
and
that's
where
the
policies
can
help
quite
a
bit
and
overall,
if,
from
the
BGP
point
of
view,
do
we
thinks
that
this
information
will
have
any
operational
issue.
I
Ideally,
the
PCE
information
is
quite
stable.
It's
not
something
that
changes
that
much
in
a
in
a
network.
You
have
the
PC
address,
PC
capabilities.
Those
things
are
quite
stable
information,
so
adding
that
information
into
this
protocol
we
don't
see
operationally
as
a
too
much
of
a
make
a
constraint
on
the
BGP
protocol
overall
and
the
Bhairavi.
Basically,
we
feel
that
this
is
not
trying
to
replace
the
existing
mechanism.
I
The
5
0
88
5
0
89,
has
a
complete
place
within
the
domain
within
the
area
when
the
both
the
parties
up
are
part
of
the
same
I.
Gpi
GP
is
the
preferable
way
to
advertise
this
information,
but
when
that
is
not
the
case,
can
a
GP
be
used
specially
if
the
BGP
LS
session
already
exists
and
you
are
expecting
translating
some
traffic
engineering
and
other
related
information
on
the
same
session?
So
we
have
discussed
this
in
PC.
I
I
J
I
The
other
thing
is
the
solution
and
the
use
cases
scenarios
that
you
mentioned
in
your
slides.
This
is
not
really
covered
or
explained
in
the
draft,
so
I
think
it
will
be
good
if
you
could
describe
these
scenarios
and
the
use
cases.
Okay,
they'll
make
the
document
that
very
well.
It
comments
actually
one
of
the
reasons
why
we
did
not
be
in
PC.
We
have
a
document
which
gave
the
requirements
for
discovery
and
when
they
wrote
this
requirement,
I
don't
know
ages
ago.
I
At
that
time
also
they
said
that
IGP
is
the
one,
but
in
future
BGP
could
be
explored
and
when
it
can
be
explored.
These
are
the
these
are
the
higher-level
points
that
need
to
be
considered
and
we,
but
at
that
time
bt
pls
did
not
exist.
We
were
never
using
that,
so
did
not
make
sense
so,
but
I
kinda
I
agree.
I
We
will
revisit
refer
where
we
can
of
an
existing
document
and
if
some
things
from
BGP
LS
point
of
view
which
did
not
exist
back,
then
we
definitely
need
to
add
into
the
document
now
right.
So
what
the
ID
please
cover
was
you
know
within
a
specific
area
or
the
IGP
domain
wide
s
level,
but
now
we
are
getting
in
scenarios
which
are
interests,
and
things
like
that.
So
I
think
are
you
concerned
about.
B
Through
those
scenarios,
this
is
something
that
is
something
that
would
you
should
propose
the
scenarios
you're
concerned
with
on
the
idea
list.
You
should
respond,
that'll
teach
you
some
of
the
feedback,
also
going
through
some
of
the
scenarios
on
the
list
will
help
you
get
the
right
feedback.
Thank.
B
B
Otherwise
we
thought
the
square
would
be
a
little
crowded,
Kerr,
Patel
and
Mahesh
really
did
a
lot
of
the
heavy
lifting
here.
I've
done
a
lot
of
the
Senate
sanitation
checks
to
see
that
it
aligned
with
our
work
that
we've
done
over
the
last
three
to
four
years
on
BGP
modeling.
So
what
is
this?
This
is
the
draft
MKS
it's
Mukesh
here,
and
so
it's
really
a
revised
data
store
version
of
our
of
our
current
model,
which
was
based
on
open
config.
B
We
have
a
problem
in
the
ITF
they've
decided
to
move
to
revised
data
stores
for
new
data
models.
The
original
data
model
from
open
config
after
lots
of
discussion
discussion
in
the
net
mod
group
is
not
going
to
go,
be
adopted
and
when
we've
talked
to
the
open,
config
people
who
authored
the
structure
in
the
original
BGP
model
they've
got
a
lot
of
deployments.
B
Two
different
models:
two
different
decisions,
people
looking
at
at
different
ways
and
ITF-
has
gone
one
way
and
open
config
is
gone.
The
other
this,
of
course,
is
brings
me
to
angst
discouragement
whatever,
because
there's
a
lot
of
deployment
and
IDR
and
John
and
I
believe
in
deployment
learning,
and
we
always
like
to
interoperable
specifications.
Well,
the
open
config
have
10
or
15.
So
this
general
ideas
is
worked
out
fairly
well
on
the
data
models,
so
we're
honest
struggle
here.
B
We've
got
a
lot
of
deployment,
a
lot
of
good
thought,
a
lot
of
good
operator
input,
and
here
we've
got
two
in
non
workable
models.
Two
different
ways
to
look
at
state,
both
valid
but
different.
So
just
to
give
you
a
little
bit
of
input,
the
draft
on
that
mod
revise
data
stores
might
put
MTU
has
a
set.
Excuse
me
they.
Let
me
take
a
step
back.
B
Our
current
model
has
a
candidate
and
a
startup,
and
you
put
it
into
running,
and
that
goes
into
some
sort
of
intended
and
it
gets
installed
in
operations.
The
revised
data
stores
allows
for
dynamic,
config
data
stores,
and
that
could
be
done
in
VMs
and
it
can
be
a
ephemeral
like
the
IR
2's
has
been
working
on
it
can
bring
in
system
state
it
can
bring
in
other
things.
This
revised
data
stores
allows
all
that
to
happen
and
is
a
good
thing
to
go
forward
with
with
VMs
or
a
ephemeral
state
or
other
things.
B
We
know
we
want
to
do.
The
open
config
model
has
config
and
config
state
where
you
actually
denote
inside
the
variables,
therefore
they're
just
not
going
to
mix.
That's
just
a
little
explanation
of
why
they're
different
same
information
different
way
to
lay
it
out.
So
here's
a
proposed
solution,
we're
going.
This
is
okay,
chair
hut,
on
with
proposed
solution
there.
This
is
most
of
that's
been
a
discussion
as
a
co-author
on
both
drafts
what's
different
and
why
I
could
be
happy
with
both
drafts.
B
I
care
and
I
have
reviewed
the
models
to
see
that
they
contain
the
same
information
they're
in
different
formats,
but
we
wanted
them
to
be
equivalent,
not
the
same
but
equivalent.
The
word
movement
is
important,
so
our
thought-
and
this
is
something
I've
had
long
discussions
with
our
routing
ad
alvaro-
is
not
here,
but
we
you,
you
can
talk
to
them
or
myself
for
alia
or
Deborah
about
this
as
well,
is
to
actually
publish
the
open
config
model.
B
It
won't
go
as
standard
but
to
provide
it
as
an
informational
draft,
because
there
are
a
lot
of
people
are
using
it
and
it's
a
good
piece
of
work
and
then
to
move
the
revised
data
store
model
Ford,
because
that's
the
only
one
that
we're
allowed
to
that
that
our
ADEs
field
should
go
forward
and
that's
what
the
net
mod
working
group.
So
we've
created
this
draft
with
Mahesh's
help
and
cares,
help
and
my
review
that
does
that
this
has
the
idea
that
we'd
like
to
publish
it.
B
Well,
then
I
ran
into
the
problem
that
Lu
hi
Lu
mentioned
this
morning,
that
we
have
want
to
publish
both
models
simultaneously.
Well,
because
we
don't
have
versioning
Lu,
we
can't
say
version:
one
of
BGP
model
was
the
old
one
we
adopted
and
the
next
we
have
to
rename
them.
So
we've
got
to
deal
with
that
particular
piece,
but
other
than
that
we
could
rename
them.
We
could
rename
the
old
one
to
bgp,
ITF,
bgp
OC
for
open
config
and
the
other
one
to
ITF
bgp.
B
Now
this
is
the
thing
that
we're
sort
of
stepping
stone
before
we
do
any
additional
features
again.
Chair
hat
on
it
seemed
fair
and
respectful
to
the
open,
config
people
to
give
them
an
equivalent
ITF
revised
data
store
model
that
they
could
go
and
work
with.
In
their
environments,
we've
tried
to
keep
most
of
the
variables
the
same.
However,
they
can't
be
totally
the
same,
because
there's
this
state
requirement
in
open
config
at
that
point
still
chair
hat
on
would
be
the
time
we
would
derivate
and
you
would
allow
upgrades
now.
B
I,
don't
know
how
the
ADEs
will
handle
upgrades
to
open
config,
but
it
is
an
open
value.
It
is
hopeful
that
we
could
create
an
ID,
our
github
repository
and
put
the
gang
up
there.
For
both.
This
is
just
one
way
to
go
forward.
It
is
just
a
way
you
can
get
the
github
for
open,
config
openly,
and
the
revised
datastore
would
go
by
the
way.
The
reason
I
mentioned,
putting
it
up
and
github.
This
was
an
encouragement
from
Benoit
to
have
working
groups
put
their
yang
models
up
in
github.
P
Wilson
Cisco,
so
just
one
comment
about
the
namespace
issue
that,
given
that
the
sorry
Isabella
so
go
to
the
namespace
issue,
given
that
the
open
conflict
models
that
people
implementing
actually
use
the
open
coffin,
namespace
it
sort
of
doesn't
matter
what
namespace
you
use
for
the
open
confi
models
in
terms
what
you
put
in
that
draft,
because
that's
not
what
people
actually
implement
they'll
actually
always
implement
the
open,
config
namespace.
So
if
you
do
use
a
different
name
for
that,
you
don't
have
any
versioning
issue,
you
just
split
them
automatically,
because
there's
no
issues
there.
P
P
Q
B
R
So
that's
what
there's
a
couple
of
different
points.
The
first
is:
if
they
have
different
names,
you
don't
have
a
versioning
problem.
They're,
not
related,
you
have
you,
you
don't
have
a
name,
you
don't
have
a
versioning
problem,
they
have
different
paths,
there
are
different
models
or
modules
they're,
just
not
related.
The
other
question,
which
is
a
little
more
concerning
to
me
is,
is
the
point
that
was
made.
R
B
F
R
P
R
L
So,
okay,
patel
Arcis,
I,
think
to
answer
Rob
and
Lou's
question.
There
are
implementations,
but
they
are
purely
open,
config
based
and
if
you
take
open
configs
model
as
they
are
and
you
compile
them,
there
are
no
compilation
issues
right.
So
if
you
take
them,
then
I
I
think
I
know
Wenders.
We
have
implemented
it.
Maybe
a
variant
of
that
part
along
so.
B
B
They
pick
some
really
I'm,
not
talking
about
the
model,
but
the
BGP
content.
The
choices
they
made
in
BGP
are
wise
and
that's
the
piece
that
I
want
to
make
sure
we
have
a
copy
to
be
respectful
of
where
we
got.
The
IP
are
from
that
made
these
wise
bgp
choices,
and
then
we
have
the
other
otherwise
I
feel
like
we're
taking
their
work
without
credit,
and
that's
that
would
be,
in
my
estimation,
non
respectful
of
all
the
contributions
they
have
made.
Yes,.
P
Okay,
so
so
one,
but
then
in
that
case
it
might
be
better
rather
than
publishing
actual
the
models.
Yeah
models
in
that
informational
draft
to
publish
references
to
the
particular
version
of
the
open,
confi
model,
you're
saying
is
people
should
adopt
and
use
and
standardize
or
or
implement
effectively.
Would
that
not
be
better,
rather
than
creating
a
third
model
in
a
different
name
space?
It
creates
more
confusion.
Okay,.
P
H
Had
the
same
comment:
I
just
wanna
agree
like
there's
no
I,
don't
understand
why
we
would
publish
a
new
name
space
in
the
ITF
space
if
we're
progressing
in
informational
drafts
and
can
just
reference.
The
open,
config
model
directly
I'm,
not
sure
what
the
purpose
would
be
to
be
in
the
IETF
name
space.
If
it's
in
okay.
B
R
One
flew
again:
one
modification
to
Rob's
proposal
is
to
publish
the
work
but
not
publish
it
as
a
full
model
say
these
elements
were
very
important
for
us
at
building
our
model.
So
here's
the
here's,
the
structures
that
we're
using
the
containers,
the
portion
and
just
publish
that
as
informational,
but
not
as
a
compilable
module,
and
then
that
way
you
one
recognize
the
work
that
was
done
to
ensure
that
you
don't
have
all
the
reference
problems
that
we're
still
grappling
with,
because
it's
a
it
was
an
IETF
contribution.
R
L
R
B
O
B
O
O
However.
However,
after
talking
with
people
recently,
I
learned
that
some
vendors
have
their
own
models
that
they
implement
and
then
they
are
doing,
mapping
or
transformation
of
models
and
I,
wonder
I,
wonder
whether
the
stuff,
yet
you
want
to
publish
actually
you
are
going
as
far
as
explaining
how
the
mapping
and
the
transformations
actually
work,
if
not
well.
Okay,
it's
nice
to
have
a
publication
and
make
sure
and
make
sure
that
the
audience
of
the
documents
don't
get
too
much
confused
about
the
various
models
that
are
in
the
space.
Okay,.
B
I
you've,
given
me
even
more
information.
Thank
you
very
we'll.
Take
it
under
advisement,
both
within
the
discussion
to
here
with
the
authors
and
other
people,
whether
it's
reasonable
to
publish
the
open
config.
We
will
go
forward
with
an
adoption
call
for
the
MKS
draft.
Since
that's
a
revised
datastore
and
you
will
stay
stuff
on
the
list,
once
I
get
enough
advice
on
the
publishing
of
the
old
document,
but
we
do
need
to
move
chair
head
on
to
this
revised
datastore.
B
S
So
I
have
a
question
mm-hmm,
so
this
is
a
manchu
from
siena
I
had
sent
you
an
email
about
some
attributes
that
were
not
covered.
The
poor,
neighbor
poor
address
family
and
you
said
you
will
look
into
that
and
that
because
I
think
I
believe
it.
There
was
one
of
the
draft
that
had
all
those
attributes.
Then
you
merged
with
the
yes
I.
B
S
S
B
D
B
B
You,
okay,
any
other
concerns
about
adopting
the
revised
datastore.
That
eight
seems
to
be
the
easy
path.
The
rest
I
will
work
with
John
and
all
the
rest
to
see
if
I
can
come
up
with
what
I
should
do
with
the
open
config
and
they
will
send
requests
out
to
the
list
any
other
questions
now.
The
final
thing
that's
in
here
is
once
we
settle
on
the
revised
datastore
model.
B
We
will
then
take
model
drafts
on
extensions,
the
revised
datastore
model
and
the
model
that
we
had
picked
up
with
ITF
BGP,
originally
from
the
open
config.
The
BGP
portion
took
a
subset
of
BGP
and
we
put
other
things
for
extensions
once
we
adopt
this,
we
will
adopt
extensions
and
for
the
best
working
group.
This
is
where
we
got
to
make
sure
that
we're
sort
of
in
alignment.
Okay,
any
other
questions
on
this.
Thank
you
for
the
excellent
feedback.
A
S
S
So
I'm
presenting
it
for
this
SRE
6vg
BLS
signal
routing
document,
just
reminder:
there
is
some
architecture
and
the
network,
programming
architecture
and
network
programming
guide,
which
is
out
there.
Please
read
that
it
gives
a
lot
of
good
information.
Also
right
out
of
this
I
will
be
presenting
the
service
training
draft.
So
you'll
get
an
idea.
What
are
we
trying
to
do
problem?
S
We
all
know
what
beach
pls
does
so
I
don't
have
to
go
into
the
details
of
it,
but
essentially
what
we're
trying
to
do
is
to
enable
a
way
for
the
controller
to
learn
about
my
local
sit
table
which
is
defined
in
that
network
programming
document.
What
it
is,
how
it
does
all
that
details
are
there
and,
of
course,
you
know
enable
the
topological
topology
in
the
segment,
routing
v6
and
also
the
services
like
self-service
functions
and
the
sub
paths
which
we
call
segments
and
again
those
details
are
in
that
programming
document.
S
S
The
first
TLV
is
a
node
attribute
TLV,
so
at
a
high
level
we
have
defined
the
tlvs
which
we
need
as
node
attributes,
and
this
is
again
in
RF.
The
base
BG
BLS
RFC,
but
the
the
node
attribute
are
attached
the
node
TLV
and
we
are
defining
two
more
node
tlvs,
the
capability
TLB
and
ideally
the
capability
TLV
is
responsible
for
announcing
the
capabilities
of
the
router.
What
it
can
do,
the
supposed
support
for
the
SRH.
These
are
the
sub
tlvs,
which
are
defined
the
IGP
draft,
which
we
have
published
for
segment
auditing
v6.
S
We
are
encoding
safe
information
in
BG
pls,
instead
of
going
in
IGP
you're,
sending
it
from
the
node
to
the
controller.
So
nothing
fancy
there.
All
the
details
are
in
the
draft,
so
you
know
if
there
any
questions
we
can
discuss
another
list
or
please
feel
free
to
send
me
an
email
I
can
I
can
now
I
can
help
answer
that
city
LV
is
essentially
how
do
you
encode
the
CID
or
segment
identifiers
like
end
and
D
function
and
DX
6
and
signal
it
from
the
node
to
the
controller.
S
So
simple
link
attribute
TLV
is
the
TLV
which
we
are
defining
again
to
encode
the
agency
information.
It
could
be
a
peer-to-peer
link
or
the
land.
You
know,
cross
connect,
direct
link
to
attributes
are
defined
for
the
link
attribute.
We
have
the
p2p
cross
TLV
and
the
LAN
cross.
It
clearly
ETP
as
a
and
as
we
know
it's
just
to
define
the
the
p2p
information.
S
So
we
are
having
a
CID
size
which
defines
how
many
sets
are
encoded.
The
set
value,
some
ITP
information,
those
extensions
are
defined
in
the
eius
eius
eius
eius
raft
and
the
last
slide
I
have
so
this
slide
is
is
about
the
the
same
information
similar
information
in
a
LAN
LAN
TLV.
The
only
difference
here
is
the
neighbor
ID,
whether
it's
a
no
SPF
or
the
neighbour
ID
or
system
idea.
Ss
system
ID
is
encoded.
S
Cid
size
and
set
value
is
encoded.
The
last
one
is
a
function
to
LV,
so
once
we
have
defined
the
CID,
which
needs
to
be
sent
from
the
node
to
the
controller,
we
also
need
to
signal
a
sub
T
LV,
which
tells
for
which
function
this
set
is
associated
with.
So
we
tagged
that
information
in
a
sub
T
LV
and
send
it
to
the
controller
and
that
next.
L
L
S
Right,
so
we
can
clarify
that,
but
the
way
we
the
BGP
LS
is
being
used
right
now
for
the
discovery
of
the
nodes
and
services.
That's
the
standard
way
V
naught.
We
don't
know
of
implementations
which
are
doing
or
using
the
tunnel
n
cap
attributes,
but
we
can
discuss
that.
You
know
offline
as
well
just.
T
T
F
If
you,
if
you
build
both
software
and
hardware
I,
might
agree
and
give
the
related
wall
when
you
need
your
hardware
to
signal,
what's
supported
and
believe
me,
it's
difficult
enough
to
get
brought
common
other
to
implement
this
API.
If
you
start
creating
variety
of
them,
if
you
confuse
everybody,
you'll
introduce
new
bugs
and
no,
but.
S
T
Is
the
the
the
the
the
a
the
way
it
works?
Is
that
it
gives
you
the
the
information
in
whatever
format
it
has,
depending
on
the
API
you
encoded
in
a
different
place.
The
way
you
encoded
this
protocol
dependent
the
way
they
give
it
you
as
Hardware
dependent.
These
are
two
separate
things,
but
if
they
give
you
this
information,
SSR
basics
information
in
once
in
one
piece
and
you
divide
it
at
half
of
it
in
one
TLV
and
another
half
and
a
different
year,
I
think
it's
much
other
implementation,
wise.
M
In
action,
so
I
have
a
automation
that
there's
another
craft.
It's
also
different.
Similar
function
like
this
one
I
have
different.
So
I
can't
hear
you
there's
a
lander
craft,
also
different
similar
extensions,
but
there
has
some
different
definition
about
the
terrible
example.
The
type
and
the
lands
field,
dance
and
some
other,
but
but
I
saw
is
similar.
I
think
can
discuss
offline
sure.
P
I
J
S
Okay,
I'm
speaking
for
the
next
one,
so
we
are
in
this
particular
document.
We
are
proposing
a
service,
chaining
architecture
with
using
segments
routing.
What
we
are
asking
for
IDR
in
this
particular
document,
is
the
BGP
LS
extensions.
I
am
presenting
note
that
both
drafts,
one
is
the
BGP
LS
extensions
for
service
chaining
and
the
segment
routing
service,
chaining
data
plane
document
just
to
complete
the
CIM.
You
know
have
the
full
picture
of
what
we
are
trying
to
do
all
right.
S
So
just
as
a
reminder
again,
the
network
programming
is
the
again
the
main
document
we
have
defined
all
these
functions,
which
we
will
be
talking
about
this
document.
Some
of
the
functions
are
defined
in
that
service
chaining
document,
which
I
mentioned
in
the
first
slide.
Also,
it
will
be
good
to
review
how
the
SRS
header
and
gos
the
information.
How
do
we
do
the
overall
architecture
with
service,
chaining,
topology,
nodes
and
other
stuff?
Those
are
details
are
in
the
SRS
document,
the
segment
routing
header
document
problem.
S
What
do
you
want
to
do?
We
want
our
neeps
enabled
service
chaining
and
also
have
other
attributes
of
the
traffic,
because
you
know
we
are
seeing
there's
a
lot
of
discussions
and
talks
about
how
do
we
do
segment
routing
which
solves
one
problem?
How
do
we
do
second
service
chaining
which
solves
another
problem?
This
solution
is
just
trying
to
integrate
all
of
that
into
one
solution.
How
do
we
discover
these
services?
How
do
we
discover
the
Associated
sets
or
services,
as
we
call
it
with
those
services?
S
S
We
have
different
proxies,
which
we
have
defined
based
on
what
their
role
is
and
how
we
are
how
those
proxies
are
implemented.
We
have
you,
know
s
static
proxy,
which
is
similar
to
what
we
do
today.
You
you
configure
something
and
I
have
a
slide
which
covers
that.
We
have
dynamic,
proxies
shared
memory
and
masquerading
I'm,
not
covering
all
of
them
today
in
the
presentation,
but
they
are
undefined
in
the
in
detail
in
that
service
chaining,
our
data
plane
document.
So
if
there
is
any
questions
or
comments,
you
know
those
are
welcome.
S
We
can
discuss
it
in
the
on
the
thread.
So
what
is
the
static
proxy
static?
Roxy?
Is
your
it's
it's
today's
solution?
How
you
do
today,
where
you
are
configuring
up
the
static
information
about
the
function
or
services
on
a
particular
node
and
it's
a
pre
configuration
the
pre
configuration
in
this
particular
case
says
you
have
a
cid
associated
with
that
pre
config.
S
You
have
an
output
at
output,
outbound
interface,
going
from
a
VPP
to
that
service
function
and
you
have
an
inbound
interface
where
some
policies
and
attached
so
when
the
when
the
packet
comes
in
and
it's
hard
to
read,
but
I'll
try
to
explain
so.
In
this
particular
case
you
have
an
SR
H
header,
where
you
have
us
a
segment
list
which
is
associated
there.
You
have
a
segment
which
is
e1
e1,
:,
:
a
when
the
packet
comes
to
VPP
with
E
one
column
column,
a
the
VPP
knows.
S
This
is
something
which
I
have
configured
over
here
and
it's
a
static
proxy.
It
does
a
lookup,
it's
d
caps.
S
This
solution
is
fully
flexible
to
be
able
to
do
that,
we
do
maintain
a
person
static
configuration
just
the
nature
of
it.
This
is
how
its
deployed
today,
what
you
achieve
with
this
static
proxy
is
that
you
can
integrate
with
the
segment
routing
where
you
can
have
some
SLA
requirements
like
delay
or
latency
or
jitter
a
delay
and
latency,
and
you
can
you
can
combine
that
with
the
services
which
you
want
to
configure
on
in
your
network.
So
it's
it's!
S
It's
just
enabling,
on
the
current
functionality,
apparent
solutions
with
segment
routing
dynamic
proxy
is
little
bit
more
flexible,
so
you
have,
and
in
this
solution
again,
is
for
both
SR
MPLS
and
for
sr
v
6.
So
we
have
acid',
which
is
associated,
which
is
e1
:,
:
B,
and
that
has
the
packet
comes
in
with
even
:
:,
be
the
VPP
looks
at
the
packet
and
says:
oh,
this
set
is
mine.
I
need
to
do
something
it
it
D
caps,
the
outer
header
caches,
that
information
locally
sends
the
packet.
S
The
inner
ipv4
packet
to
the
to
the
service
comes
back
from
the
service,
and
then
it
puts
the
header
back
and
sends
it
out
to
the
on
the
wire
by
copying
the
nest
next
segment
ID,
which
is
c2
into
the
destination
address,
and
it
goes
out
in
this
particular
case.
We
are
not
doing
any
static
configuration
in
fact
again.
S
This
is
this:
is
dynamically
configure
the
main
goal
of
enabling
these
proxy
functions,
whether
static
dynamic
masquerading
shared
memory
is
to
is,
is,
as
we
are,
developing
the
nodes
which
are
fully
capable
of
segment
routing,
and
that
work
is
also
ongoing.
This
is
this
is
the
way
to
to
be
able
to
enable
these
services
and
integrate
them
with
the
segment
routing
and
all
the
benefits
with
segmenting
provides
again.
The
inner
header
can
be
ipv4,
ipv6
or
an
Ethernet,
so
the
solution
is
fully
flexible.
S
Sorry,
all
right,
so
from
idea
point
of
view,
we
are
requesting
some
bt
pls
extensions
to
be
able
to
discover
these
services.
We
are
also
proposing
some
sub
tlvs
to
encode
the
service
information,
which
is
the
service
services
based
it
data
model
and
signal
it
from
the
node
to
the
to
the
controller
service.
S
Chaining
attributes
of
TLV
is,
is
requested
in
this
draft,
where
you
have
a
service
type,
which
is
a
new
registry
which
is
also
requested
in
this
draft,
which
defines
the
kind
of
service
it
is
whether
it's
a
classifier
firewall
DPI
any
kind
of
those
services.
It
also
requests
what
the
traffic
that
service
is
capable
of
handling
so
and
it's
in
our
operation.
So
it
can
be
one
or
both
on
many,
so
you
can
have
an
ipv4
ipv6
Ethernet
any
of
those
as
in
ur
headers.
S
This
is
just
for
the
controller
to
know
what
that,
when
it's,
when
it's
creating
this
SRS
header,
you
know
whether
it
should
include
this
particular
service
node.
As
its
as
one
of
the
node
in
the
SRS
header,
opaque
metadata.
We
realize
that
there
will
be
a
lot
of
information
which
is
very
service
specific.
We
do
not.
We
that's
why
we
created
some
opaque
metadata
sub
TLB,
which
can
encode
information
like
vendor
specific
information
like
brand
version
other
data,
any
extra
information
can
be
encoded
in
it.
S
S
Implementation
status,
so
whatever
we
have
talked
about
so
far,
we
have
already
implemented
the
proxy
functions
on
the
open
source
hardware.
We
have
implemented
the
the
on
Linux
and
on
FDI
o
VBB
software.
We
have
also
implemented
the
static
proxy
on
Cisco
hardware
and
and
that
particular
demo
will
be
out
there,
and
you
know
in
the
end,
on
the
on
Cisco's
web
side.
S
L
Kayuu
patel
arcus
I
have
actually
question
for
a
chair
for
chairs
couple
of
IDF's
back
Robert
and
I
presented
a
draft
called
vector
routing
which
was
based,
which
is
intended
for
service
aning
I
I
have
a
faint
recollection.
I
might
be
wrong,
but
back
then
the
working
group
had
said
that
service
chaining
work
was
not
within
the
Charter
of
this
working
group.
Has
that
changed.
B
A
B
B
S
B
B
You
thank
you
folks.
Okay,
we
try
to
do
this.
As
we
talked
about
earlier
with
the
BG
you
pls,
we
are
really
trying
to
be
collaborative
and
make
sure
we
check
that
everything's
working
in
one
working
group
before
we
do
the
GLS.
So
this
is
not
a
no
it's
just.
Let
me
figure
out
how
it
works.
Okay,
that
comes
to
the
end
of
our
agenda.
B
Have
one
working
group
adoption
and
one
I
didn't
do
an
allocation?
If
there's
somebody
else
that
hadn't
sent
me
one,
it's
a
reminder:
if
I've
missed
your
allocation,
John
and
I
are
I've
had
a
life
storm
where
we're
sort
of
bailing
water,
if
you
miss
getting
your
allocation,
if
you
miss
getting
your
working
group
call
do
not
feel
shy
about
sending
John
and
I.
Several
messages
will
apologize
ahead
of
time,
but
we'll
try
to
get
through
all
of
them
and
if
you
would
send
it
today,
I'd
appreciate
it
I'll
summarize
to
the
list.
That's
it.