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 PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, July 14, 2006 10:46 AM Subject: RE: [Pce] P & I flags Hi Dimitri, > -----Message d'origine----- > De : dimitri papadimitriou [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 14 juillet 2006 15:44 > À : [EMAIL PROTECTED] > 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 protected] > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
