Hi Dimitri, > -----Message d'origine----- > De : dimitri papadimitriou [mailto:[EMAIL PROTECTED] > Envoyé : dimanche 16 juillet 2006 18:25 > À : Igor Bryskin > Cc : LE ROUX Jean-Louis RD-CORE-LAN; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Objet : Re: [Pce] P & I flags > > 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
NO, why do you want to change the semantic if the P flag? this semantic is required... > > 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 No, all recognized and supported constraints MUST be taken into account during path computation, whatever the P flag value. The P flag simply indicates what to do when a constraint is not recognized/unsupported. > > 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 ? Yes, 2^16 may not be enought, think about an NMS that would send a request for tens of thousands of LSPs. Thanks, JL > > thanks, > - dimitri. > > > > > Igor Bryskin wrote: > > 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
