Hi Dimitri, > -----Message d'origine----- > De : dimitri papadimitriou [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 14 juillet 2006 20:52 > À : LE ROUX Jean-Louis RD-CORE-LAN > Cc : [EMAIL PROTECTED]; [EMAIL PROTECTED] > Objet : Re: [Pce] P & I flags > > hi j-l > > LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > 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 > > i restate you have two levels of indirection optional objects > and optional usage of the constraint during pc
Yes there are two levels, and the P/I flag semantic applies to the first one. Here is what is currently specified : -If a constraint is not recognized or not supported and P is set a PCErr is sent -If a constraint is not recognized or not supported and P is not set, the path is computed without taking into account this constraint, and this constraint is carried within the PCRep with the I flag is set. -If a constraint is recognized and supported it MUST be taken into account in path computation whatever the P flag value, and if no path supporting this constraint can be found a negative PCRep is sent, that may include the unsatisifed constraint. This notion of "optional usage of constraint" you discuss, is relevant...but actually related to constraint relaxation that was largely discussed one year ago on this list, and as agreed by WG consensus, we decided to remove constraint relaxation from this base spec... So, here in this spec, if a constraint is recognized and supported it must be used in Path computation, and, as clealry pointed out in the draft (section 7.4) if no path satisfiying a given constraint can be found, the PCE sends a PCRep message with a NO-PATH object that may include the unsatisfied constraint, then this is up to the PCC to decide what to do (e.g. it may send a new request by relaxing this constraint). > > 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 Yes but as discussed below this is another level, out of the scope of this document > > 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 But this is not the semantic of the P flag, here you refer to a new flag that would help constraint relaxation on the PCE. By the way, the PCC could send a PCReq including only constraints that MUST be taken into account during path computation, and then subsequent requests with additional optional constraints, and it would work as is. There are many ways to ensure constraint relaxation and this is out of the scope of this doc. > > 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 See above > > > "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". > > my point is that you can not return "unknown object" from the > P flag but from the unsupport of an object Why??? > > > 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 > > > >> 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? > > see adrian's reply Ah, thanks! JL > > 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. > > > > > > > >> 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
