Hi Igor, > -----Message d'origine----- > De : Igor Bryskin [mailto:[EMAIL PROTECTED] > Envoyé : dimanche 16 juillet 2006 23:50 > À : LE ROUX Jean-Louis RD-CORE-LAN; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Objet : Re: [Pce] P & I flags > > Hi JL. > > Please, see in line. > > Igor > > ----- Original Message ----- > From: "LE ROUX Jean-Louis RD-CORE-LAN" > <[EMAIL PROTECTED]> > To: "Igor Bryskin" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Sunday, July 16, 2006 3:56 PM > Subject: RE: [Pce] P & I flags > > > Hi Igor, > > See inline, > > > > > -----Message d'origine----- > > De : Igor Bryskin [mailto:[EMAIL PROTECTED] > > Envoyé : samedi 15 juillet 2006 15:51 > > À : LE ROUX Jean-Louis RD-CORE-LAN; [EMAIL PROTECTED]; > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Objet : Re: [Pce] P & I flags > > > > 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. > > I don't think this is unrealistic, there are cases in your > example where > the bandwidth alone as a single constraint cannot be fit > while color as a > single constraint can be fit (and vice versa). In this case > this makes sense > IMO to send a negative reply indicating that the bandwidth > cannot be fit. > Anyway in the case you mention the PCE can send a negative > reply indicating > bandwidth and color as unsatisifed constraints, and may even > suggest values > that could be satisfied > (shall we consider that a PCE may be a bit more clever??) > > IB>> This is the whole my point. If there is a set of > mandatory constraints, > there is no way for a PCE to tell because of which particular > constraint(s) > the computation has failed,
Why, if it is clever enough to detect a blocking constraint? >let alone recommend other values for the > constraints to make the computation successful. I'd like to > hear from PCE > developers whether they share my view. Ah, OK let discuss with PCE developpers! <JLLR with PCE and PCEP developper hat on> I don't share your view... Best Regards, JL > > The only reasons to mark the constraints in the PC reply IMO are: > > a) for a mandatory constraint either when it was not > recognized or could not > be otherwise supported (e.g. an unknown color was specified) > b) for an optional constraint when it was removed according > to a signaled or > policed constraint relaxation strategy which made the computation > successful. > > Regards, > Igor > > > > > > 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. > > As already commented to Dimitri, this is related to > constraint relaxation > and is completely beyond the scope of this document as agreed > one year ago > on this list. There are various solutions for constraints > relaxation that > need to be discussed. By the way it could work as is by sending two > requests, one with mandatory constraints and the other with > all (mandatory + > optional) constraints... > > > > Recommend to make an assumption that PCE will run path > > computation at most two times: > > We will never make such recommendation, this is definitely a local > implementation issue. > > Regards, > > JL > > > > > 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
