Hi Dimitri, > -----Message d'origine----- > De : dimitri papadimitriou [mailto:[EMAIL PROTECTED] > Envoyé : lundi 17 juillet 2006 00:04 > À : LE ROUX Jean-Louis RD-CORE-LAN > Cc : [EMAIL PROTECTED]; Igor Bryskin; [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é : 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... > > call it I flag if you want the point is that the Error should > be generated once an object (from its class or type) is not recognized
Humm no, I flag is already used! Call it O flag if you like > > if you have that a too high rejection rate could result from > optional constraints such behaviour should be inferred by no > further looking into the object > > >> 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. > > again call it I flag, point remains, a negative answer shall > come only from not finding a result from mandatory constraints Dimitri, please see my previous answer. I understand the semantic you define, it was discussed one year ago as part of a constraint relaxation thread (less constrained path), and the result of this thread was that there there was no consensus, some people were against, hence we removed the requirement from the generic PCECP req id, and also we removed text on less constrained path from the PCEP spec, and decided to address it latter. This should be defined in a separate ID once the requirement is clearly expressed. By the way there are various options for handling optional constraints and more generally constraint relaxation. For instance the PCC may also send two requests, one with only mandatory constraints and another with optional constraints... > > and a positive result may include more than the set of > mandatory constraints Ah, this is interesting...and what sub-set of optional constraints is selected if not all optional constaints can be satisfied? Again we are discussing constraint relaxation here and this is beyond the scope of this doc... > > the fact that an error is issued should then be the result of > the non-support of a mandatory constraint Yes, indeed this is current P flag processing > > all together this makes one flag - and this only because > there is a difference between optional object support and > optional processing > > >> 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. > > what does make the NMS PCC different from an LSR ? Please keep it simple, you were asking why do we need 2^32, and I answered that 2^16 may not be enough, and I took, as pure illustration, the example of an NMS acting as PCC, and sending a PCReq for a synchronized path computation of tens of K LSPs, ie a PCReq with tens of K requests (I simply took the example of NMS PCC, as an NMS is likely to request synchronized path computation of many more LSPs, than an LSR would do). > i think > there is a difference between the set of command issued to > the NMS and the resulting set of PCC requests an NMS will generate Who says the contrary? And what is the point here? Thanks, JL > > thanks, > - dimitri. > > > 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
