Subject: RE: [Pce] P & I flags

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 17 Jul 2006 00:28:56 +0200

Hi Igor, 

> -----Message d'origine-----
> De : Igor Bryskin [mailto:[email-masked]] 
> Envoyé : dimanche 16 juillet 2006 23:50
> À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked]; 
> [email-masked]; [email-masked]
> Objet : Re: [Pce] P & I flags
> 
> Hi JL.
> 
> Please, see in line.
> 
> Igor
> 
> ----- Original Message -----
> From: "LE ROUX Jean-Louis RD-CORE-LAN" 
> <[email-masked]>
> To: "Igor Bryskin" <[email-masked]>; 
> <[email-masked]>; <[email-masked]>; 
> <[email-masked]>
> 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-masked]]
> > Envoyé : samedi 15 juillet 2006 15:51
> > À : LE ROUX Jean-Louis RD-CORE-LAN; [email-masked];
> > [email-masked]; [email-masked]
> > 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-masked]>
> > To: <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > Sent: Friday, July 14, 2006 10:46 AM
> > Subject: RE: [Pce] P & I flags
> >
> >
> > Hi Dimitri,
> >
> > > -----Message d'origine-----
> > > De : dimitri papadimitriou [mailto:[email-masked]]
> > > Envoyé : vendredi 14 juillet 2006 15:44
> > > À : [email-masked]
> > > 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-masked]
> > > https://www1.ietf.org/mailman/listinfo/pce
> > >
> >
> > _______________________________________________
> > Pce mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pce
> >
> >
> 
> 

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Mon, 17 Jul 2006 10:36:05 -0400

Hi Igor and JL,

Comments in line,

> 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.

> <JLLR with PCE and PCEP developper hat on> I don't share your view...

Thanks.

JP.

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 17 Jul 2006 12:03:36 -0400

JP.

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

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 20 Jul 2006 07:59:36 -0500

Hi Adrian,

See below. 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Thursday, July 20, 2006 7:17 AM
> To: Igor Bryskin; JP Vasseur; LE ROUX Jean-Louis RD-CORE-LAN
> Cc: [email-masked]
> 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
> From: "Igor Bryskin" <[email-masked]>
> To: "JP Vasseur" <[email-masked]>; "LE ROUX Jean-Louis 
> RD-CORE-LAN" 
> Cc: <[email-masked]>
> Sent: Monday, July 17, 2006 5:03 PM
> Subject: Re: [Pce] P & I flags
> 
> > JP.
> >
> > IB>> I am just curious. Could you (or anybody) describe 
> > just one of the 
> > ways

---

From: JP Vasseur <[email-masked]>
Date: Sat, 22 Jul 2006 12:21:00 +0200

Hi Adrian,

On Jul 20, 2006, at 1:17 PM, Adrian Farrel wrote:

> 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?
>
> 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%.

I think it is ... there are many network designs in which a clear  
constraint hierarchy can be defined. For example, bandwidth and  
affinity (and of course the number of such example is quite large).  
"You can relax the affinity constraint if a path with at least 90% of  
the required bandwidth can be found". In that particular case, it is  
quite easy to specify an algorithm capable of satisfying such  
request. There are also some cases where the issue is NP-hard (most  
of them) but the number of situations where hierarchical constraint  
relaxation would be useful is not negligible.

Note that we're discussing about constraint relaxation here for which  
there was a decision to tackle this issue in a separate ID.

Cheers.

JP.

>
> Adrian
>
>
> ----- Original Message ----- From: "Igor Bryskin" <[email-masked]>
> To: "JP Vasseur" <[email-masked]>; "LE ROUX Jean-Louis RD-CORE- 
> LAN" <[email-masked]>
> Cc: <[email-masked]>