>Soooo.
>I was assuming
that you may need:
>- an OF to apply
to the set of synchornized requests
>- an OF to apply
to each of the requests
Yes
this is what we need. Maybe we need to clarify the terminology, here by "set of
synchronized requests" we mean the set of requests listed in a
SVEC.
>What you appear
to have is:
>- an OF to apply
to each synchronized request
> through
the OF in the SVEC-list
That is it
applies to the set of synchronized requests listed in an SVEC
object.
>- an OF to apply
to each of the requests
> through
the OF in the request
>It seems to me
that you do not have the ability to supply a meta-OF that applies to the whole
SVEC-list, but you have two separate ways
>to supply an OF for each
request.
We have the
ability to supply an OF for the set of requests listed in an SVEC
object, and to supply an OF for each request. This is what is
required.
>>
>>
This is already what we have.
>Well, I moved OF
next to metric-list.
OK, we will
do this
>Unclear whether you are
accepting my assumption that metric-list should be applied to the whole
SVEC-list. If so, how is this different from >the
OF?
Hi Jean-Louis,
Many thanks for agreement on so many
points.
I have cut this down to just the open
points. Please see in line.
Cheers,
Adrian
>> 4.2. Carrying the OF object in a
PCEP message
>> An OF object specifying an objective function
that applies to an
>> individual path computation request (non
synchronized case) MUST
>> follow the RP object for which it
applies.
>>
>> I don't like the fact that
the OF is sometimes here, sometimes
>> there.
>> You need
to facilitate several different cases.
>> a.
Message contains just one request with an OF to
apply
>> b. Message contains several unsynchronized
requests each with
>> an
OF
>> c. Message contains several synchronized
requests with an OF
>>
to apply to the set of computations
>> d.
Message contains several synchronized requests with an OF
>>
to apply to the set of computations, and the message
>> contains one or
more unsynchronized requests each with an
>>
OF to apply.
>> It seems to me that your handling of the
synchronized requests is
>> a problem because it appears that
you can have a separate OF for
>> each request in the set,
but have no way to say the OF that
>> applies to the whole
set.
>
> Not really.
:-)
>> So, I think you
need...
>> <PCReq Message>::= <Common
Header>
>>
[ [<OF>]
<SVEC-list>]
>>
<request-list>
>> No. Recall that
an SVEC comprises a set of synchronized requests.
> A SVEC list is a list of SVEC, that is a list of sets of
> synchronized requests.
> We need to be able to specify an
OF for each SVEC...
> So I think our proposed encoding is the right
one.
Soooo.
I was assuming that you may need:
- an OF to apply to the set of synchornized
requests
- an OF to apply to each of the requests
What you appear to have is:
- an OF to apply to each synchronized
request
through the OF in the SVEC-list
- an OF to apply to each of the requests
through the OF in the request
It seems to me that you do not have the ability to
supply a meta-OF that applies to the whole SVEC-list, but you have two
separate ways to supply an OF for each request.
>>
where:
>>
<svec-list>::=<SVEC>
>>
[<svec-list>]
>>
>>
<request-list>::=<request>[<request-list>]
>>
>> <request>::=
<RP>
>>
<END-POINTS>
>>
[<LSPA>]
>>
[<BANDWIDTH>]
>>
[<OF>]
>>
[<metric-list>]
>>
[<RRO>]
>>
[<IRO>]
>>
[<LOAD-BALANCING>]
>>
>
>
This is already what we have.
Well, I moved OF next to metric-list.
>> Now, you also
have...
>>
<metric-list>::=<METRIC>[<metric-list>]
>> This is
lifted from [PCEP] and is fine. But don't you also
>> need a metric
list for the synchronized OF?
>> This would
yield...
>> <PCReq Message>::= <Common
Header>
>>
[ [<OF>] [<metric-list>]
<SVEC-list>]
>>
<request-list>
>> Right, this will
be added
Unclear whether you are accepting my assumption that
metric-list should be applied to the whole SVEC-list. If so, how is this
different from the OF?
>> Now, suppose the request desires
(not requires) an OF, and
>> the response says No-Path. Shouldn't
the response also say
>> which OF was used to produce this
result?
>
> Strictly speaking the reason
for no path is never an
> objective function, the reason is a constraint.
Yes, that is very true.
But, nevertheless, isn't it helpful to report the OF
that was used?
