Subject: RE: [Pce] P & I flags

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sun, 16 Jul 2006 22:08:07 +0200

Hi Dimitri, 

> -----Message d'origine-----
> De : dimitri papadimitriou [mailto:[email-masked]] 
> Envoyé : dimanche 16 juillet 2006 18:25
> À : Igor Bryskin
> Cc : LE ROUX Jean-Louis RD-CORE-LAN; 
> [email-masked]; [email-masked]
> 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-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: dimitri papadimitriou <[email-masked]>
Date: Mon, 17 Jul 2006 00:04:08 +0200

hi j-l

LE ROUX Jean-Louis RD-CORE-LAN wrote:

> Hi Dimitri,
> 
> 
>> -----Message d'origine----- De : dimitri papadimitriou
>> [mailto:[email-masked]] Envoyé : dimanche 16 juillet 2006
>> 18:25 À : Igor Bryskin Cc : LE ROUX Jean-Louis RD-CORE-LAN; 
>> [email-masked]; [email-masked] 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
> 
> 

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

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

and a positive result may include more than the set of mandatory constraints

the fact that an error is issued should then be the result of the 
non-support of a mandatory constraint

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

what does make the NMS PCC different from an LSR ? 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

thanks,
- dimitri.

>> thanks, - dimitri.
>>> 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
>> 
>>> the only thing is clear that there are no links with proper
>>> colors that have enough bandwidth, that is, entire set of
>> 
>> constraints cannot
>> 
>>> 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.
>>> 
>>> 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
>>>> 
>>>> 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
>>> 
>>> 
>>> it sends a PCErr message. Hence the PCC knows whether mandatory
>>> constraints have been
>> 
>> taken into
>> 
>>> account.
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> specify in a PCReq message sent to a PCE whether the object
>> 
>> must be taken
>> 
>>>> 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
>>> 
>>> 
>>>> 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.
>>> 
>>> 
>>> 
>>> 
>>>> 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.
>>>> 
>>>> 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] 
>>> _______________________________________________ Pce mailing list 
>>> [email-masked] https://www1.ietf.org/mailman/listinfo/pce
>>> 
>>> 
>>> .
>>> 
>> 
> 
> .
>