►
From YouTube: IETF103-TEAS-20181105-1120
Description
TEAS meeting session at IETF103
2018/11/05 1120
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
B
We
have
both
audio
streaming
and
video
as
we
have
become
accustomed.
Please
speak
up
at
the
mics
we
need
to
discuss
and
when
you
come
to
the
mic,
please
start
by
stating
your
name,
so
those
that
are
remote
can
know
who
you
are.
That
also
helps
with
minute,
taking,
as
usual,
we're
doing
our
collaborative
minute,
taking
using
etherpad
I'll
pause
here
for
a
moment
for
folks
to
jump
on.
B
Please
help
out
by
capture
helping
the
capture
comments
that
are
said.
It's
particularly
good,
if,
if
you
say
something
to
a
go,
look
at
etherpad
and
make
sure
your
name
is
recorded
properly
and
that
your
comment
appropriately
captured.
That's
when
you
do
that.
It's
very
helpful.
We
also
are
using
jabber.
If
I
can
ask
a
few
people
to
jump
on
I'll
jump
on
in
a
moment
also,
and
that
way
folks
who
are
remote
are
able
to
ask
questions
so.
B
B
We've
had
four
recent
RFC's,
that's
really
what
we're
supposed
to
be
producing.
So
it's
good
to
see
when
that
we
we
have
some
products
coming
out
of
the
group.
We
have
one
document
that
is
in
the
editor
queue.
It
is
the
teehee
topology
document,
as
we
know
that
that
was
something
we
worked
on
quite
a
while
and
it's
it's
a
quite
a
significant
piece
of
work.
It
has
been
waiting
for
the.
B
What
is
the
types
module,
which
is
that
we
just
recently
passed
last
call,
so
we
should
be
able
to
move
this
out
of
last
rep.
Sorry
miss
ref
fairly
soon.
That
said,
a
couple
of
different
comments
have
come
in
on
that
document.
One
of
them
is
pretty
straightforward
is.
Is
that
there's
some
alignment
necessary
to
make
with
the
current
with
the
latest
te
types
document?
That's
pretty
much
a
no-brainer.
We
could
take
care
of
that
in
queue.
B
Being
issues
being
raised,
excuse
me
and
to
discuss
how
they
would
like
to
proceed,
because
what
I'll
still
a
little
of
their
thunder
by
saying
that
we
have
a
choice
and
the
choice
is
is:
can
we
do
something
that's
workable
with
the
current
document
and
go
forward
with
publisher
publishing
it
or
do
we
want
to
bring
it
back
to
the
working
to
come
up
with
possibly
a
more
optimal
solution?
So
it's
a
decision
of
of
optimality
versus
of
what
is
good
enough
and
we
certainly
don't
want
to
publish
something
if
it's
wrong.
B
B
This
font
is
way
too
small.
We
have
a
one-hour
session
now.
Basically,
we
had
requested
a
two
and
a
half
hour
session,
which
is
our
traditional
session
length
that
we
normally
sort
of
just
barely
fit
into.
We
with
the
experiment,
that's
being
run
this
week
with
not
having
Friday's
the
two
and
a
half
hour
sessions
were
done
away
with,
and
we
had
a
two
hour
session
and
we
were
hoping
to
squeeze
into
that
two
hour
session.
We
really
couldn't
and
that's
the
reason
why
we
scheduled
this
at
the
last
moment.
B
B
Nothing
new
here
in
terms
of
our
IPR
process.
We
do
formal
polling
both
before
adoption
and
before
are
as
part
of
working
group
last
call.
The
really
important
thing
here
is
is,
if
you
contribute
to
a
document,
please
respond
to
this
as
rapidly
as
possible
to
keep
our
documents
being
processed
efficiently.
B
We
continue
to
have
a
lot
of
discussions
that
happen
off
less
the
Hmong
authors
and
a
certain
amount
of
discussion
is
is
good,
but
I
do
want
to
remind.
We
want
to
remind
the
authors
in
particular,
but
other
working
group
participants
that
if
you
have
an
issue
with
the
document,
if
you
have
a
topic
that
and
particularly
on
a
working
group
document,
that
you
think
we
requires
a
decision
that
should
be
taking
place
on
the
working
group
list.
B
If
you
do
it
among
the
authors
and
come
to
a
decision
among
the
authors
and
then
present
it
to
the
working
group,
you've
actually
failed
the
process,
because
a
working
group
document
is
owned
by
the
working
group.
It's
not
owned
by
the
authors.
So
it's
really
critical
to
make
sure
that
when
we
want
to
make
a
change
for
working
group
document,
we
have
consensus
of
the
working
group
on
that
change.
Consensus
of
the
authors-
excuse
me,
does
not
matter.
Consensus
of
the
working
group
is
all
that's
important
there.
B
B
So
the
last
slide
here
is
is
that
we
did
have
a
work.
We
did
have
a
discussion
on
the
working
group
list
related
to
our
Charter,
so
we
had
a
number
of
sort
of
private
discussions
that
we
had
heard
that
there
were
some
questions
on
the
Charter
and
saying
that
it's
little
dated
and
we
wanted
to
do
an
update.
So
we
start
we
started
a
discussion
on
the
on
the
list
of
a
proposal
that
we've
come
up
with.
We
had
some
very
good
feedback
and
good
discussion.
B
We
did
updates
based
on
that
and
the
final
version
was
sent
around
and
was
accepted
basically
by
those
who
chose
to
participate
on
the
list
and
the
results
are
still
the
details
are
still
available
and
if
you're
interested
in
a
red
line
version
and
how
we
got
there,
that's
also
available
just
go.
Look
on
the
main
on
the
mailing
list
for
charter
and
you'll
find
a
link
to
it
as
well
as
find
that
the
the
current
text
charters
are
actually
owned
by
the
IES.
B
She
and
shepherded
are
managed
by
the
area,
director,
Deborah,
and
so
at
this
point
we
believe
the
working
group
has
done
the
job
provided
input
to
our
ad
on
how
we'd
like
to
see
the
Charter
change
updated,
and
it's
now
with
her
in
the
IAS
g2
to
basically
adopt
or
to
decide
whether
or
not
it
gets
put
in
place
and
I,
don't
think
you'd
ever
do
have
any
concerns
or
shaking
her
head.
No,
so
we
expect
this
processing
to
happen
over
the
coming
weeks.
If
you
have
haven't
looked
at
the
changes.
D
D
So
there
are
11
documents
listed
here.
These
are
not
on
the
agenda
for
this
week.
I'll
quickly
walk
through
the
status
of
each
of
those
in
the
next
few.
Slides
first
up
are
the
two
PC
and
native
IP
documents.
This
is
the
experimental
work
that
we
adopted
early
this
year.
The
authors
did
do
an
editorial
scrub
and
they
did
provide
revisions
for
both
the
documents.
So
please
do
go
or
the
changes,
and
if
there
are
any
questions
or
concerns
with
the
work,
that's
being
done,
please
do
bringing
that
to
the
list.
D
Next
up
is
the
PC
CC
use
cases
document.
We
have
a
new
editor
on
board,
for
this
drew.
Has
the
pen
on
this.
For
now
there
was
derivation
published
for
this
last
month,
and
the
authors
did
align
that
with
the
text
in
the
PC
CC
extension
stockman.
They
added
a
couple
of
new
use
cases
and
also
updated
an
existing
one.
If
there
are
any
concerns
with
the
direction
that's
being
taken
by
the
authors,
please
to
bring
that
to
the
list,
they
are
seeking
feedback
on
the
work
that's
being
done.
D
Next
is
the
RSVP
rmr
extension
document.
There
were
no
changes
made
to
the
draft
since
the
last
idea.
The
authors
are
currently
looking
to
looking
for
signalling
options
for
keeping
to
ring
topologies
with
Express
links.
If
you
have
any
review
review
comments
or
feedback,
please
bring
that
to
the
list
as
well.
D
Next
is
the
T
metric
recording
document.
We
did
not
receive
any
status
report
for
this.
There
were
no
changes
made
to
this
draft
since
last
ITF.
We
still
have
some
outstanding
comments
that
need
to
get
discussed
on
the
list.
This
job
has
been
around
for
a
long
time
now,
so
you
really
like
to
see
that
get
progressed
and
if
there
isn't
any
interest,
maybe
let
it
die.
If
there's
anybody
here
from
the
other
side
who
would
like
to
give
a
quick
status
on
where
things
are
that
abuse.
E
Yeah,
this
is
suffer
the
comments
I
with
you
last
time,
I
think
they're
from
long
time
back,
it'd
be
good
to
refresh
those
comments,
who's
willing
to
refresh
the
document
address
those
comments,
it
close
it
off.
They
are
the
archives.
Yeah
I
know
I
I
with
the
last
time.
Would
you
look
into
that
and
it
is
there?
We
are
willing
to
address.
F
E
D
D
B
B
Okay,
so
I'm
not
see
we're
not
seeing
any
hands
so
that
to
us.
That's
an
indication
that
there
people
are
interested,
but
not
all
that
willing
and
pushing
it
forward.
So
I
wear
at
the
point
where
either
you
have
to
close
get
this
done
by
the
next
IETF
or
we're
just
move
it
to
dead
state,
because
it's
going
on
too
long.
Okay,.
D
Next
is
the
tutorial
draft
that
discusses
how
the
various
key
models
that
we
are
putting
together
need
to
be
used.
There
was
a
revision
published
for
this.
A
section
on
handling
bi-directional
tunnels
was
added
there.
There
are
various
features
and
functionalities
for
which
sections
need
to
get
added.
There's
currently
no
hurry
in
getting
this
to
the
next
stage,
but
that
said,
please
do
review
this
as
and
when
you
can
and
reach
out
to
the
authors
on
the
list.
If
there
are
any
missing
pieces.
D
D
Next
is
the
l3t
topology
model,
they
was
a
revision
for
this
published
last
month.
The
authors
added
a
JSON
example
for
how
this
model
needs
to
get
used.
There
is
some
pending
work
in
terms
of
aligning
with
the
latest
version
of
the
key
types
module
once
that
gets
done.
This
should
be
ready
for
young
doctors
review.
G
Excuse
me
this
figure,
so
basically
just
one
poor
in
the
ball
tutorial,
there
was
one
big
request,
basically
saying
that
we
need
a
section
that
is
dedicated
to
packet,
only
T
networks
and
how
this
was
so.
We
need
a
volunteer,
basically
an
experiment,
packets
network,
to
do
that.
So
basically,
we
need
to
call
for
volunteer.
Is.
D
Next
is
the
SRT
topology
model
there
was
elevations
published
for
this
as
well.
The
scope
of
this
has
been
reduced.
Srm
pls.
There
are
a
few.
There
were
few
missing
attributes
for
prefixes
and
adjacent
sets,
and
for
MSD
as
well
that
those
were
added
they.
This
needs
a
round
of
review
before
it
can
progress
to
the
next
step.
D
This
is
the
last
slide
in
the
stack.
This
is
an
update
on
the
to
RSVP
models.
The
base
RSVP
model
is
ready
for
a
young
doctors
review.
As
far
as
the
authors
are
concerned,
the
recipe
key
model
needs
to
undergo
a
split
and
then
round
off
review
before
it
can
before
the
authors
can
claim
it's
ready
for
a
young
doc
distribute
that's
where
things
turn
it's.
B
My
understanding
that
this
next
version
can
be
done
very
quickly
and
if
that's
correct,
then
I'll
look
to
the
author.
Just
did
not
his
head,
so
Tariq
is
not
it.
Please
come
to
the
mic.
If
you
want
to
say
anything
else,
but
with
that
understanding
in
mind,
I
think
it
makes
sense
for
the
drafts
to
be
go
to
yang
doctor
review
together.
One
of
the
comments
that
we
got
as
far
as
the
te
types
is
that
it
was
a
little
difficult
doing
that
document
in
isolation
because
of
the
lack
of
context.
B
C
H
H
F
H
Two
standalone
documents
want
to
contain
the
common
tea
types
and
the
other
one
is
to
cover
the
MPLS
te
tunnel,
MPLS
technology,
specific
modeling,
and
for
this
purpose,
we've
created
these
two
drafts
that
I
have
up
there
for
the
tea
types
draft
it
progressed
and
it
has
undergone
a
working
group.
Last
call
as
well
as
we've
done,
a
review
from
the
working
group,
specifically
from
that.
We've
received
a
review
comments
from
from
Matt,
as
well
as
the
yang
doctor
from
yang.
H
H
So
we've
addressed
that
by
replacing
this
by
an
explicit
route,
it's
meant
to
be
an
explicit
route
object
or
hop,
and
it's
in
the
arrow
lists
or
explicit
route
lists
we're
using
an
index
to
identify
an
entry
in
this
list.
It's
not
a
leafless,
because
an
entry
can
be
repeated.
As
you
know,
we
can
have
multiple
node
IDs
in
the
same
euro
list,
so
we've
opted
for
having
an
index
as
the
key,
but
we
will
address
by
adding
text
to
describe
that
and
how
it's
used.
H
H
H
So
if
you
we've
used
a
specific
index
as
a
key,
but
they
are
IDs
that
identify
a
network
element
and
the
internet
work
itself,
so
we
still
want
to
call
them
xxx
ID,
but
it's
not
a
key
and
hopefully
the
and
ahktar
would
be
okay.
With
that,
the
last
comment
we
got
was
to
be
consistent
in
terms
of
the
identity
naming
lower
case
upper
case.
We
we
had
mixed
usage
and
we
will
align
the
varying
recommendation
of
lower
case.
H
In
this
slide,
I'll
go
over
the
comments
that
I
got
or
we
got
from
that,
and
we
thank
Matt
for
that.
There
was
a
missing
identity
for
one
plus
one
Alice
P
protection.
We
will
add
that
in
the
model
there
was
a
te
optimization
criteria
which
covers
two
metrics.
In
fact,
we
are
using
this
in
the
topology
model,
this
identity
and
we
have
a
similar
identity
which
encompasses
more
metrics.
It's
called
the
objective
function
type
and
and
we
will
replace
the
topology
model,
the
new
identity
and
retire
this
one.
H
There
was
a
comment
made
about.
We
are
using
a
normative
reference
to
the
other
models
in
the
types,
and
that
makes
those
dependencies
on
this
type
model,
and
we
wanted
to
avoid
that.
To
begin
with,
so
we
will
remove
any
reference
to
the
importing
models
and
that
e-types
my
draft,
so
that
it
can
progress
on
its
own.
H
H
H
So
in
terms
of
the
documents
and
how
they
stand
right
now,
we
we
have
the
main
document
yang
te
and
it
was
split
into
three
documents.
The
yang
te
will
contain
the
technology
independent
or
technology
agnostic
parameters,
and
we
have
the
second
document,
which
is
MPLS
specific,
and
the
stand-alone
third
document
is
the
common
te
types.
This
is
how
the
organization
of
documents
has
resulted
up
to
date.
H
One
slide
yeah,
that's
the
one.
So
in
terms
of
next
steps,
the
te
types
is
progressing
and
we've
addressed
the
comments
and
we're
following
up
on
the
resolution
with
reviewers
and
hopefully
to
progress
the
publication
with
respect
to
the
yang
te
draft.
It
is
ready
for
working
group
last
call
and
the
yang
dr.
review
to
follow.
And,
lastly,
the
last
document
still
needs
to
undergo
of
rounds
of
editing
and
review
before
we
asked
for
the
working
group
last
all
so
that
that's
our
plan
in
terms
of
progress
and
updating
ego
go
ahead.
G
So
there
was
a
comment
from
young
doctors
with
respective
defaults
right.
There
are
not
sufficient
number
of
default
set
in
the
types
and
I
think
it's
a
very
valid
comment.
Basically,
when
we
do
not
assert
a
default,
we
require
like
active
choice
right
this,
like
a
choice.
Architecture,
issue
and
active
choice
require
basically
good
understanding
of
all
options,
even
for
things
that
you
do
not
really
care
about.
G
So
I
know
ninety
percent
of
the
time
when
people
have
choices,
they
always
go
with
the
false,
and
this
is
a
good
way
to
basically
not
what
kind
of
relic
choices
we
as
co-authors,
expect.
Okay,
so
I
think
we
should
take
this
particular
comment
quite
seriously
and
put
defaults
like
a
reasonable
from
our
point
of
view
any
place,
we
think
so.
D
H
Have
a
small
comment
is,
if
I
mean
its
controversial,
setting
a
certain
value
on
a
parameter,
different
people
might
have
I
might
think
about
it
differently,
and
so,
if
you
think
we
have
to
have
a
consensus
on
the
value
and
probably
the
best
way
is
to
right
or
right
at
or
a
separate
draft
set
such
parameters.
If
you
think
that
they
should
be
set
as
default,
and
so.
G
The
point
that
I
was
trying
to
make
is
that
basically
no
default.
It
means
that
you
have
to
do
active
choice.
Okay,
so
the
models
are
usually
written
in
such
a
way
that
you
may
care
only
about
like
a
small
part
of
the
model,
and
you
just
like
when
you
set
up
a
software
okay,
you
always
go
normally
with
default
right.
You
do
not
pick
up
options
whom
you
do
not
understand
and
to
provide
a
customized
solution
right.
G
J
Here
so
I
think
for
the
defaults,
I
I
would
say
it's
it's
strictly
like
case
by
case.
So
in
the
past,
like
implementation,
the
interrupt
experience
I
would
view
some
of
the
defaults
might
be
necessary,
but
not
all
of
them
I
think
like
it
could
be
done
either
by
you
know.
If
you
really
care
about
the
defaults,
because
different
implementation
is
to
be,
you
know,
on
the
same
page
when
doing
intro,
it
has
to
be
explicitly
specified
or
you
could
use
a
policy
local
policy
to
define
the
defaults
I.
H
G
One
last
comment:
so,
basically,
when
you
said
defaults,
you
do
not
preclude
to
put
any
choice.
You
want
right,
it's
just
basically
a
what
would
be
normally
a
good
idea
to
set
in
this
case,
but
yeah.
If
you
do
not
have
any
defaults,
it
means
that
you
have
to
go
through
all
choices
and
it
could
get
confused
people.
D
So
now
that
you,
anybody
else
has
anything
on
that
topic
before
we
jump
wrap
it.
So
now
that
you
have
done
the
split
and
you
have
the
T
types
yet
module,
you
should
let
the
RSAF
just
know
that
there's
no
I
mean
they
can
fix
the
mistress,
and
they
were
also
a
couple
of
items
that
you
listed,
that
or
artists
as
part
of
the
young
dog
distribute
that
may
have
a
bearing
on
the
teeter
party
mode.
That's.
D
B
For
things
that
are
necessary
to
align
the
topology
document,
the
apology
document
with
the
finalized
version
of
te
types
right
that
I
think
is
sufficient
to
put
proposal
out
on
on
the
working
group
and
get
agreement
on
that
and
then
put
it,
give
it
to
the
RFC
editor
and
have
them
make
the
changes
in
edit.
In
editor
note,
so
that's
part
of
the
reason
why
we
block
we
have
this.
Miss
ref
state
is
to
take
care
of
to
ensure
we
don't
end
up
with
misalignment
between
documents.
I.
B
Actually,
take
we're
doing
exactly
recovering
exactly
the
case
that
Miss
ref
exists
for
so
that's
good.
There
was
I
know
there
were
some
other
right
now
off
list
discussions
about
more
substantive
changes
that
are
not
necessary
to
align
with
T
types,
but
based
on
some
implementation
experience.
That
is
that
that's
what
falls
into
the
category
of
one
of
those
things
it
has
to
be
discussed
on
the
list
and
we'll
see
where
we
want
to
go
with
that.
Okay,.
F
H
K
L
L
If
we
have
a
good
model
from
other
organizations
we
just
pointed
to
and
we
can
use
their
resource
extraction,
but
just
in
case
that
some
model
they
may
not
be
defined
by
SC
and
FP,
and
maybe
ITF,
can
future
or
defined
those
resource
model.
I
think
one
use
case
I
can
think
of
is
a
regenerator
model.
I
think
one
of
the
use
cases
regenerator
as
a
service
function
then
might
be
worked
on
in
T's
or
C
camp
working
group
down
the
road.
But
we
don't
have
that.
L
L
Yes,
so
if
you
look
at
the
model
that
we
augment,
basically
a
tunnel
termination
point
from
te,
our
topology
and
we
leave
service
function
and
turn
ultimate
terminations
and
and
we
use
a
service
function,
ID
that
reference
to
a
service
function
down
the
road
and
also
we
point
to
a
service
connection
point
which
is
kind
of
access.
Note
that
the
resource
is
located.
So
we
use
this
to
ID
to
reference,
but
abstraction
is
not
here
just
place,
a
pointer,
okay,
yeah.
L
B
L
B
Document,
yes,
okay,
yeah,
okay,
so
please
this
I
know
this
was
a
discussion
point
at
the
last
meeting.
So
this
is
how
the
point
that
was
raised
about
the
identifiers
and
the
other
groups
is
being
addressed.
So
it's
really
good
to
go.
Look
at
it.
We
had
talked
about
whether
it
made
sense
to
talk
to
the
SFC
group
at
all
about
this
yeah.
L
C
M
Okay:
first,
the
credits
to
all
the
people
that
is
working
was
on
this
draft
Karen
Francesco.
That
is
not
here
and
all
the
people
stack
and
the
guys
from
T
tunnel
for
which
on
which
we
work
together
to
document
that
is
aligned
with
the
eternal
model
and
thanks
for
all
the
discussion
about
the
clarifying
that
they
issue
for
the
pad
setup
and
the
suggestion
from
drew
about
the
verification
phase
that
has
been
added
in
the
document.
C
M
The
summer
the
changes,
so
we
have
added
text
to
clarify
the
point
that
has
been
discussed
in
the
Middle
East,
a
garden.
The
fact
that
the
path
being
set
up
is
not
necessarily
the
same
as
the
one
returned
it
in
during
the
path
computation
and-
and
we
add
the
text
because
a
new
phase
that
has
not
been
provided
in
the
the
old
version
of
the
path
computation,
that
is,
a
verification
phase-
is
needed
to
check.
M
If
that,
the
real
path
that
is
actually
being
set
up
meet
the
required
end-to-end
matrix
and
constraint,
then
we
have
updated
the
young
model
aligning
on
the
fact
that
the
path
the
model
is
able
to
return
the
matrixes
they
used
to
pack
to
make
the
path
computation,
but
now
is
also
the
possibility
to
allow
requesting
the
path
as
allergy
and
affinities
to
be
reported
in
the
feedback
of
path
computation.
And
then
we
corrected
bugs
and
issue
as
providing
the
our
github.
M
M
Regarding
this
issue
in
the
indica
tab,
Frankie
speaking,
there
is
not
clear
outcome
on
the
mailing
list
how
to
proceed
in
the
sense
that
if
we
need
to
assume
that
the
polity
is
not
needed,
and
so
we
can
select
our
subset
of
attributes
needed
for
part
computation
provide
that
the
set
of
attribute
has
not
been
disgusted
in
the
details.
So
this
is
our
some
clarification
would
be
needed
to
close
the
point.
B
M
F
B
G
Computation,
specific
so
and
the
whole
point
that
this
policies
may
not
be
known
outside
of
the
server.
That's.
Why,
basically,
to
make
simply
sure
that
we're
not
actually
compute
paths
were
basically
compute
for
the
tunnel.
We
set
up
a
tunnel
in
the
board
that
basically
only
computes
bus,
but
doesn't
go
beyond
that.
So
the
discussion
on
the
list
was
that
there
is
no
much
harm
to
keep
that,
because
those
parameters
are
what
you
know
anyway.
So
that
was
at
least
my
position
in
there.
H
M
The
problem
is
that
if
we
decide
to
stay
as
it
is
so
to
use
just
a
subset
of
attributes-
and
not
all
is
one
things
in
the
scientist
is-
is
like
it
is
the
young
model
if
we
need
to
have
a
complete
align
on
the
on
the
articles.
These
imply
some
modification
I'm,
proposing
that
you
use
the
full
set,
although
there,
but
they
can
be
ignored
on
the
server
side,
can
be.
K
M
Already
a
grouping,
the
point
is
that
the
fact
we
we
asked
whether
actually
we
use
a
for
a
solution
with
our
grouping
with
the
subset
of
this
is
our
situation
is
as
soon
as
this
politician
policy
is
not
defined.
We
do
not
know
why
to
change,
because
we
don't
know
how
to
justify
to
have
the
list
of
our
taboos.
That
is
not
I.
B
M
G
So,
basically,
what
we
want
to
avoid
the
situation
when
you
ask
for
past
complication
for
tunnel
and
comes
up
with
some
path,
but
when
you
provision
the
tunnel
with
exact
same
parameters,
it
comes
with
a
different
path,
and
the
reason
for
that
was
that
because
say
there
was
something
in
the
tunnel
name
on
some
parameters
which
are
not
specific
to
path
computation.
The
words
basically
tweaking
in
path
constraints
that
were
set
internally,
and
if
this
happens,
it
means
that
path.
Computation
is
useless
right
because
it
provides
a
meaning,
meaningless
information.
G
O
Yes,
I
think
that
that
situation
is
difficult
to
avoid
and
we
have
another
option
that
we
are
starting
to
discuss
and
also
if
we
provided
our
at
the
attribute
and
the
user
doesn't
know
that
he
has
to
provide
an
attribute.
It
can
also
do
the
same
problem
you
create,
but
you
setter,
you
request
a
computation.
O
You
don't
provide
an
attribute
that
your
server
is
using
that
then
you
request
the
setup
of
the
ton
and
then
you
provide
is
a
to
do
because
you
need
a
tunnel
name,
a
tunnel
description
in
a
tunnel
setup,
and
then
you
get
exactly
the
same
problem.
So
it's
unavoidable
that
there
is
a
risk
that
there
is
no
congruence
and
in
the
nest.
Unless
you
have
added
a
thanks
to
Drew,
then
I
did
a
pad
verification
phase.
That's
the
only
way
you
make
sure
that
you
get
exactly
what
you
want
is
after
you
have
set
up.
M
O
O
M
G
I'm
sorry,
just
last
comment:
I
completely
disagree
with
Ito
law,
so
the
whole
point
is
that
all
we're
requiring
is
that
when
you
ask
for
past
computation
and
then
you
specify
exact
same
parameters
for
the
tunnel,
you
get
identical
pass.
Okay.
So
if
you
miss,
for
example,
certain
parameters,
then
you
will
get
the
same
response
in
both
paths,
computation
and
a
tunnel
setup
okay.
So
there
is
a
it's
not
like,
for
example,
the
user
need
to
know
or
doesn't
need
to
know.
G
So
the
point
is
that
if
he
knows
or
doesn't
know
there,
the
end
result
will
be
the
same.
Okay,
this
one
Coleman
right-
and
the
second
comment
is
that
we
do
not
need
explicit
policies
to
be
known
outside.
It
could
be
something
which
is
totally
proprietary
to
the
server
and
we
still
can
deal
with
that.
Okay,
just
because
we
will
provide
the
same
set
of
parameters.
B
There's
clearly
a
pretty
strong
difference
of
opinions
here,
I'm,
not
sure
if
those
who
would
like
to
see
voiced
the
opinion
of
bringing
in
all
the
parameters,
passing
all
the
parameters
of
notice,
but
there's
some
new
text-
that's
shown
up
in
section
33.
That
really
relates
to
this
on
the
on
the
verification,
phase
and
I'm,
not
sure
that's
gonna,
fully
discussed
on
the
list
and
I
think
maybe
have
you
talked
about
it
a
little
more
here
or
know
about
the.
B
So
that
that's
really
goes
to
the
heart
of
this
discussion,
and
it
is
important
that
you
know
authors
have
a
lot
of
discretion
on
how
to
make
sure
that
they're
documenting
consensus
of
the
working
group
and
there's
nothing
wrong
with
them,
publishing
putting
some
new
text
in
and
publishing
it.
But
then
you
have
to
make
sure
the
working
group
eyes
in
so
it
would
be
good
to
talk
about
those
those
changes.
The.
M
B
But
I
read
it
as
a
little
broader
and
basically
leaving
the
door
open
for
this
difference
in
policy
being
applied
or
the
the
centralized
path
being
computed
differently
than
what's
in
the
network
because
of
this
policy
problem.
So
it's
it
to
be
read
is
a
little
bit
biased
towards
one
conclusion
than
the
other.
G
B
M
M
M
M
H
So
setting
multiple
constraints
as
optional
it,
it's
not
clear
which
one
would
be
more
favorable
to
drop
on
the
server
side
if
you
have
multiple
of
them
that
contradict
so.
The
approach
that
we
took
is
if
an
example
would
be
you're
trying
to
include
links,
multiple
links
in
your
computation,
and
you
cannot
include
all
of
them,
so
you
fall
back
on
the
best
number
of
links
that
you
can
include.
H
So
what
we
said
is
optimize
the
inclusions,
so
if
you
can
include
all
of
them,
that
would
be
best
if
you
cannot
include
as
many
as
you
can.
So.
This
is
the
approach
that
we
presented
in
the
model
is
try
to
optimize
inclusion
or
optimize
exclusion.
If
possible-
and
it's
clear
then
that
you're
doing
the
best
effort
in
that
when
you're
setting
the
constraint
as
optional
multiple
of
them,
it's
not
clear
the
server.
How
will
they
interpret,
which
one
is
more
favorable
than
the
other
one.
G
G
Okay,
the
second
interpretation
could
give
that
you
still
use
this
constraint
but
treat
it
like
basically
gently,
so
you
do
not
refuse
the
path
selection,
but
but
you
basically
treat
it
as
not
a
very
stringent
constraint,
so
we
we
can
address
both
of
the
cases,
but
we
do
need
to
define
what
does
it
mean?
Consolidation
means
okay.
So,
as
Derek's
explained,
we
have
a
way
to
do
this
soft
constraints
right.
G
Okay,
we
also
can
drop
constraints
if
necessary,
because
we
have
multiple
candidates
when
we
request
past
computation
at
an
establishment
every
time
when
configure
a
tunnel,
so
whether
we
need
alignment
with
PCA,
it's
also
a
good
question,
so
why
it
has
to
be
this
way.
I.
Do
not
necessarily
understand.
P
Drove
from
Huawei,
in
my
mind,
one
thing
is
important
is
what
is
the
cost
of
alignment?
Is
it
too
much
because
it's
specially
in
this
case
the
way
if
you
every
leaf,
has
a
bit
now
a
science
which
says
whether
you
are
mandatory
or
an
optional?
That
will
just
make
our
whole
yang
model
kind
of
extremely
weird,
so
the
cost
is
too
high
to
align
this
thing.
P
If
we
can
come
up
with
a
very
good
way,
a
smarter
way
to
do
that
and
to
model
it
that
yes,
some
Leafs
are
because
in
encoding
you
have
a
bit,
you
can
easily
do
it
and
yang
it's
kind
of
difficult,
so
even
from
config.
We
rarely
do
that
like
when
you
are
configuring
configuring,
these
constraints,
you
don't
do
it.
You
might
have
some
policy
somewhere
which
might
trigger
your
P
sub
request,
do
not
set
the
bit
and
then
set
to
bit.
G
So
I
recommend
roof
to
take
a
look
into
this
model.
The
cursor
we
do
not,
we
do
not
actually
insist
on
mandatory
versus
optional
Leafs.
All
we're
saying
is
that,
for
example,
explicit
path
could
be
optimization
criteria
as
much
as
everything
else
and
just
like
you
can
optimize
on
the
shoulders.
We
can
optimize
on
how
you
follow
the
their
explicit
hopes
that
you
specify.
Okay,
if
you
can
do
all
of
them,
fine,
if
you
can
do
only
half
of
them.
G
P
In
my
mind,
drove
again
I
like
what
how
the
piece
F
has
specified
its
being
there
from
five
four
four
zero
and
it's
it's
the
best
we
have,
and
the
example
that
Eric
said
about
hops,
I'm
confused
by
that
because
that's
like
lose
hops
versus
strict
hops.
That's
not
exactly
whether
the
whole
object
is
mandatory
or
not
in
piece
of
used
to
either
the
whole
iro.
That
object
is
optional,
not
sub
objects
of
objects
are
you're
loose
bit
that
you
have
in
the
sub
object.
So
we
need
to
discuss
this
I,
don't
think
so.
Q
Generic,
so
I'm
not
sure
how
important
this
question
really
is.
I
think
the
way
I
would
think
about
this
is
to
say
that
the
user
of
this
network
going
all
the
way
up
to
the
operator
is,
is
gonna
want
to
set
up
the
path
with
some
kind
of
constraints
in
mind,
and
they
aren't
necessarily
gonna
care,
whether
that
set
of
constraints
is
translated
into
piece,
F
or
yang
or
or
whatever,
right
and,
and
the
important
thing
is
to
make
sure
that
we
can
translate
those
constraints
into
either
a
meaningful
piece
F
or
a
meaningful.
Q
They
can't
yank
encoding
and
make
sure
that
the
two
things
that
we
specified
are
functionally
complete
enough,
that
they
can
model
the
same
set
of
requirements
that
an
end
user
has
I.
Don't
think
we
have
to
say
that
they
must
work
the
same
way,
but
I
think
it
is
important
that
they
are
able
to
express
the
same
level
of
richness
in
terms
of
what
operators
want
to
have.
So
that's
why
I
would
look
at
it.
I
mean
to
take
your
your
example
here.
I
think
we
are
just
looking
at.
Q
Pisa
actually
can
do
the
same
thing
as
the
little
known
think
about
pset,
but
the
the
the
PC
can
con
can
return
a
list
of
candidate
paths
to
the
PCC
allowed
by
PCC
to
choose
from
what
it
likes.
So
it
you
know
it's.
It
looks
slightly
different,
but
it
does
the
same
thing.
I,
don't
think
we
have
a
difference
there.
Maybe
there
are
other
places
where
we
do
have
an
actual
literal
difference,
and
then
we
have
to
figure
out
how
to
address
those.
Q
Q
M
Just
one
thing
the
example
is
just
to
say
that
in
this
case
it
is
not
so
trivial
to
understand
that
is
clearly
the
same,
because
one
is
practically
a
variable
that
can
be
true
or
false
in
the
sense
that
it
is
mandatory
or
no
mandatory.
The
constraint,
the
other
one
is
a
mechanism
that
is
not
trivial
to
understand
how
to's
work.
N
L
M
B
Over
I'd
like
to,
if
possible,
you
know
this
is
exactly
the
type
of
discussion
that
is
perfect
for
the
working
group,
so
we'd
like
to
continues
exactly
where
we
are
when
we
meet
next,
which
biking
on
when
that
is
okay,
so
it's
to
tomorrow,
at
4:10,
so
you're
everyone's
good
resume.
The
same
positions.