Hi Jerry, I like the <Minimum Constraints> concept; it could be extended further by specifying that a single or set of constraints might have a <Requested> value and a <Required> value. So the service is computed based an absolute <Minimum> and / or <Maximum>, or just flagged to simply <Minimize> or <Maximize> certain constraints wherever possible. It's also likely that the PCC will want to specify more than one constraint, so maybe it needs to specify the priority / weighting of each constraint when the service is computed. This will allow the minimizing of certain constraints at the expense of others. The PCE might want to flag which of the constraints met their requested value and which simply met the required value.
Dan -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:[EMAIL PROTECTED] Sent: 20 July 2006 14:00 To: Adrian Farrel; Igor Bryskin; JP Vasseur; LE ROUX Jean-Louis RD-CORE-LAN Cc: [EMAIL PROTECTED] Subject: RE: [Pce] P & I flags Hi Adrian, See below. > -----Original Message----- > From: Adrian Farrel [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 20, 2006 7:17 AM > To: Igor Bryskin; JP Vasseur; LE ROUX Jean-Louis RD-CORE-LAN > Cc: [EMAIL PROTECTED] > Subject: Re: [Pce] P & I flags > > Hi, > > This thread went suddenly very quiet in response to Igor's > question which is > a shame because it is a good question. > > When you are doing a path computation how do you know why you > can't reach > the destination with sufficient bandwidth and low enough delay? > > Is it because there is not enough bandwidth on the low delay path? > Or is it because there is too much delay on the high bandwidth path? > > The issue becomes unmanageably complex when there are many > constraints, and > is particularly difficult when those are absolute not > relative constraints. > > Of course, it is always possible to make some guesses, but > usually these are > based on varying the constraints to see what could be > achieved. The choice > of which constraints to vary, by how much, and in what order is very > suspect, and (as when we discussed constraint relaxation) > should be the > subject of policy either at the PCC or the PCE. > > For example, a response that says "If you relaxed the > required bandwidth by > 10% you could get a path" is no use to a PCC that MUST have > the bandwidth, > but that would be happy to relax the delay constraint by 90%. It seems that a <Minimum Constraint> option to PCC specified constraints would be one approach to your example (an analogous <Minimum QoS> approach is being used for example in NSIS QoS signaling, see e.g., http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt). If the PCC gave its <Minimum Constraints> = <90% * Bandwidth, 10% * delay>, that would work in this case. Thanks, Jerry > > Adrian > > > ----- Original Message ----- > From: "Igor Bryskin" <[EMAIL PROTECTED]> > To: "JP Vasseur" <[EMAIL PROTECTED]>; "LE ROUX Jean-Louis > RD-CORE-LAN" > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Monday, July 17, 2006 5:03 PM > Subject: Re: [Pce] P & I flags > > > JP. > > > >>> 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? > >> > > > > I agree with JL here. There *are* many ways to figure out which > > constraints could not be satisfied, in which case indicating this > > information to the PCC is quite useful. > > > > IB>> I am just curious. Could you (or anybody) describe > > just one of the > > ways > > how PCE can figure out which of mandatory constraints > > caused the path > > computation to fail? > > > > Thanks, > > Igor _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
