Subject: RE: [Pce] P & I flags

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 14 Jul 2006 16:46:13 +0200

Hi Dimitri, 

> -----Message d'origine-----
> De : dimitri papadimitriou [mailto:[email-masked]] 
> Envoyé : vendredi 14 juillet 2006 15:44
> À : [email-masked]
> Objet : [Pce] P & I flags
> 
> the comments around the P and I flags are
> 
> o) we have two levels of optionality in listing the protocol 
> object and usage level of the protocol object - however it is 
> much more appropriate to be sure that mandatory constraints 
> have been taken rather than having the optional having been 
> taken into account

As clearly pointed out in the same setion of the draft, if a mandatory constraint cannot be handled the PCE replies with PCErr message

"If the PCE does not understand an object with the P Flag set or
   understands the object but decides to ignore the object, the entire
   PCEP message MUST be rejected and the PCE MUST send a PCErr message
   with Error-Type="Unknown Object" or "Not supported Object".

If the PCE can handle all mandatory constraints it replies with a PCRep message (either positive or negative if there is no path), else it sends a PCErr message.
Hence the PCC knows whether mandatory constraints have been taken into account.

> 
>     P flag (Processing-Rule - 1-bit): the P flag allows a PCC 
> to specify
>     in a PCReq message sent to a PCE whether the object must be taken
>     into account by the PCE during path computation or is 
> just optional.
>     When the P flag is set, the object MUST be taken into 
> account by the
>     PCE.  Conversely, when the P flag is cleared, the object 
> is optional
>     and the PCE is free to ignore it if not supported.
> 
> o) on the I flag issue is identical why include an object 
> which has not considered during computation ? 

I don't catch your point, the PCC may want to know the constraints that were not taken into account during path computation, this sounds quite important isn'it?

there are so 
> many things that the PCE has not taken into account during 
> computation so why bother ?

Hum I don't follow you here "there are so many things...", What do you mean?

> it is imho
>   more important to include the mandatory object not taken 
> into account

If a mandatory object is not taken into account, you cannot compute the path and you send an error message. I agree with you that this would be useful to include within the PCErr the set of objects not supported, this can be clarified in next revision.

> 
>     I flag (Ignore - 1 bit): the I flag is used by a PCE in a PCRep
>     message to indicate to a PCC whether or not an optional object was
>     processed.  The PCE MAY include the ignored optional object in its
>     reply and set the I flag to indicate that the optional object was
>     ignored during path computation.  When the I flag is 
> cleared, the PCE
>     indicates that the optional object was processed during the path
>     computation.  The setting of the I flag for optional objects is
>     purely indicative and optional.  The I flag MUST be 
> cleared if the P
>     flag is set.
> 
> o) the result of all these flags is that a PCC can be 
> wrapping around unknown constraints create processing churn 
> on the PCE;

OK, if you mean that we should include the unsupported object(s) within the PCErr, then we are in sync

Thanks for the comment

Regards

JL

> 
>     If the PCE does not understand an object with the P Flag set or
>     understands the object but decides to ignore the object, 
> the entire
>     PCEP message MUST be rejected and the PCE MUST send a 
> PCErr message
>     with Error-Type="Unknown Object" or "Not supported Object".
> 
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Jul 2006 17:14:14 +0100

> I don't catch your point, the PCC may want to know the
> constraints that were not taken into account during path
> computation, this sounds quite important isn'it?
>
>> there are so

I think the disconnect is that the I flag is only used in constraints 
*returned* to the PCC. I.e. in constraints that formed part of the original 
request, but were ignored. There is no requirement (or desire?) for the PCE 
to randomly report other things it did not take into account (such as 
weather, shoe-size of operator, etc.)

Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 14 Jul 2006 20:51:50 +0200

hi j-l

LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Dimitri,
> 
> 
>> -----Message d'origine----- De : dimitri papadimitriou
>> [mailto:[email-masked]] Envoyé : vendredi 14 juillet 2006
>> 15:44 À : [email-masked] Objet : [Pce] P & I flags
>> 
>> o) we have two levels of optionality in listing the protocol object
>> and usage level of the protocol object - however it is much more
>> appropriate to be sure that mandatory constraints have been taken
>> rather than having the optional having been taken into account
> 
> As clearly pointed out in the same setion of the draft, if a
> mandatory constraint cannot be handled the PCE replies with PCErr
> message

i restate you have two levels of indirection optional objects and 
optional usage of the constraint during pc

now the important thing is not that you have a "PCE deciding to ignore" 
but a PCC that performs a sort on constraint it wants to see as part of 
its comp request

p flag can be used when the pce can't compute with that constraint(s) 
and sends a negative answer with the P flag on the constraints that can 
not be taken into account

in the reply the P flag should be such that the requestor receives a 
confirmation of constraints taken into account during PCE pc - since 
this is the only thing PCC cares about and return an error if the object 
is not supported or decision with "Policy Control failure" or even "AC 
failure" in case of PCE overload

> with Error-Type="Unknown Object" or "Not supported Object".

my point is that you can not return "unknown object" from the P flag but 
from the unsupport of an object

> If the PCE can handle all mandatory constraints it replies with a
> PCRep message (either positive or negative if there is no path), else
> it sends a PCErr message. Hence the PCC knows whether mandatory
> constraints have been taken into account.

you have also a third level of indirection in the reply because one 
assumes that

>> P flag (Processing-Rule - 1-bit): the P flag allows a PCC to
>> specify in a PCReq message sent to a PCE whether the object must be
>> taken into account by the PCE during path computation or is just
>> optional. When the P flag is set, the object MUST be taken into 
>> account by the PCE.  Conversely, when the P flag is cleared, the
>> object is optional and the PCE is free to ignore it if not
>> supported.
>> 
>> o) on the I flag issue is identical why include an object which has
>> not considered during computation ?
> 
> I don't catch your point, the PCC may want to know the constraints
> that were not taken into account during path computation, this sounds
> quite important isn'it?
> 
> 
> there are so
> 

see adrian's reply

thanks,
- dimitri.

>> it is imho more important to include the mandatory object not taken
>>  into account
> 
> 
> If a mandatory object is not taken into account, you cannot compute
> the path and you send an error message. I agree with you that this
> would be useful to include within the PCErr the set of objects not
> supported, this can be clarified in next revision.
> 
> 
> 
>> ignored during path computation.  When the I flag is cleared, the
>> PCE indicates that the optional object was processed during the
>> path computation.  The setting of the I flag for optional objects
>> is purely indicative and optional.  The I flag MUST be cleared if
>> the P flag is set.
>> 
>> o) the result of all these flags is that a PCC can be wrapping
>> around unknown constraints create processing churn on the PCE;
> 
> 
>>  PCEP message MUST be rejected and the PCE MUST send a PCErr
>> message with Error-Type="Unknown Object" or "Not supported Object".
>> 
>> 
>> 
>> 
>> _______________________________________________ Pce mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/pce
>> 
> 
> 
> .
>

---

From: "Igor Bryskin" <[email-masked]>
Date: Sat, 15 Jul 2006 09:50:41 -0400

Hi JL,

I have a question. Suppose, a path computation request has two constraints:
link colors and link bandwidth. Suppose the path computation fails. The
question is how the PCE can figure out what is the reason of this
computation failure? As an implementer of  a Path Computation Engine I
always found it a difficult problem. Normally, presented with a path
computation request with link type constraints as in the example I am
describing, a PCE would prune out the arcs form the network graph associated
with links that do not satisfy at least one of the constraints, and after
that run some algorithm. If the algorithm fails the only thing is clear that
there are no links with proper colors that have enough bandwidth, that is,
entire set of constraints cannot be satisfied. But it is impossible to say
which constraint in particular has caused the failure. Even if you start
removing constraints one by one and rerunning the algorithm (which would be
very unpractical to do), you will find out that it does not help. The path
computation of the example may succeed in both these iterations because:
a) there are links with proper colors;
b) there are links with enough bandwidth.

The bottom line is that path computation fails because of the entire set of
constraints rather than because of one or several of them, and it is
unrealistic to think that PCE in its negative reply would mark constraints
which cause the failure.

So, I recommend to have two flags (say, P and I). One of them should be used
to mark mandatory constraints, while another - optional constraints.
Recommend to make an assumption that PCE will run path computation at most
two times:

1) trying to accommodate all constraints;
2) in case 1) fails, removing all optional constraints

PCE should return:

a)  successful response without flags when  1) succeeds;
b) successful response with flag I when 2) succeeds;
3) negative response with no flags when 2 fails.

Igor

----- Original Message ----- 
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, July 14, 2006 10:46 AM
Subject: RE: [Pce] P & I flags

Hi Dimitri,

> have been taken rather than having the optional having been

As clearly pointed out in the same setion of the draft, if a mandatory
constraint cannot be handled the PCE replies with PCErr message

If the PCE can handle all mandatory constraints it replies with a PCRep
message (either positive or negative if there is no path), else it sends a
PCErr message.
Hence the PCC knows whether mandatory constraints have been taken into
account.

> which has not considered during computation ?

I don't catch your point, the PCC may want to know the constraints that were
not taken into account during path computation, this sounds quite important
isn'it?

there are so

>   more important to include the mandatory object not taken

If a mandatory object is not taken into account, you cannot compute the path
and you send an error message. I agree with you that this would be useful to
include within the PCErr the set of objects not supported, this can be
clarified in next revision.

> wrapping around unknown constraints create processing churn

OK, if you mean that we should include the unsupported object(s) within the
PCErr, then we are in sync

Thanks for the comment

Regards

JL

---

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 16 Jul 2006 18:24:54 +0200

igor, j-l

to indicate optional/non-optional you need one flag like i indicate in 
my reply to j-l - let's say the P flag

in the reply - where you have a third level of indirection since you can 
send a positive or a negative answer you can have one of the following

a) positive response with both optional and non-optional
b) positive response with non-optional only
c) negative response

however, as far as my reading goes, ALL non-optional constraints MUST be 
taken into account while SOME of the optional constraints MAY be taken 
into account

hence one could consider that list in the reply corresponds to the list 
of considered constraints and since the requestor knows these are 
optional or not there is no need for a second flag - this prevents back 
tracking of optional information - and restrict confirmation to the 
mandatory constraints

ps: are you serious when considering a message length of 2^32 ?

thanks,
- dimitri.

---

From: Dave Wang <[email-masked]>
Date: Sat, 15 Jul 2006 11:39:21 -0400 (EDT)

Hi Igor,

 	There is also the complexity of setup/holding priority.
If you raise the setup priority, you may succeed in path placement,
but may also cause many lower holding priority LSP's to re-route
or fail.

Dave

---

From: JP Vasseur <[email-masked]>
Date: Mon, 17 Jul 2006 09:24:54 -0400

On Jul 14, 2006, at 12:14 PM, Adrian Farrel wrote:

> I think the disconnect is that the I flag is only used in  
> constraints *returned* to the PCC. I.e. in constraints that formed  
> part of the original request, but were ignored. There is no  
> requirement (or desire?) for the PCE to randomly report other  
> things it did not take into account (such as weather, shoe-size of  
> operator, etc.)

Correct (since if the PCE does not support or decided to ignore a  
mandatory object), it would send a PCErr message.

Thanks.

JP.