Hi Mustapha, Since delegation is applied per LSP and not all LSPs are delegated it is perfectly fine for an active stateful PCE to receive PCReq/PCRep. In your mail you apply a passive / active property to whole PCC/PCE which is not correct.
I see this as - Stateless PCE Stateless PCE + PCRpt (LSPBD) = Passive Stateful PCE Stateless PCE + PCRpt (LSPBD) + PCUpd (delegation) = Active Stateful PCE At the same time, someone may choose to implement (as per some SDN like deployment) to only support delegation. But that is their choice. Some more inline.... On Sat, Dec 6, 2014 at 5:08 AM, Aissaoui, Mustapha (Mustapha) <[email protected]> wrote: > Dear all, > > The use of PCReq/PCRep messages with the passive stateful PCE is well > documented in draft-ietf-pce-stateful-pce-10. There is however no explicit > procedures for using PCReq/PCRep with active stateful PCE. > To me this is implicit, as above. > > > There are cases where the router will not be able to compute the initial > path for an LSP configured on the router. This can be for example a Segment > Routing TE LSP which has a bandwidth requirement. In this case, the LSP will > remain down until PCE computes a path for it. > > > > In such a case, the PCC must make a request to PCE for the computation of > the initial path for the LSP. I can think of two different ways for > achieving this but none of these are explicitly described in the draft: > > > > 1. The PCC starts with the passive stateful procedures and uses the > PCReq/PCRep message to request the initial path for the LSP. If the PCE > returns a path, then the PCC can delegate the LSP to the PCE in the > subsequent PCRpt message after the LSP is instantiated on the PCC. From > there on, the active stateful procedures with PCRpt/PCUpd messages can be > followed until such time the LSP delegation is changed. This method seems > appropriate and complete but it is not described in the draft. In other > words, there is no statement that an active stateful PCE can operate in > passive mode for a given LSP when delegation of the LSP has not been given > to it. > > Correct! Since delegation is applied per LSP, PCC should be able to use PCReq/PCRep (passive) for an undelegated LSP and later delegate the same LSP. Need for text can be evaluated by the WG. > > 2. The PCC starts in the active stateful mode and delegates the LSP, > which is in down state, using the PCRpt message. In this case, the PCRpt is > used to synchronize the state of the LSP with the PCE but also as an > implicit way to request the initial LSP path computation. The issue though > is that the PCRpt message is not an explicit path computation request and > lacks the following: > > It is completely fine for PCC to delegate an unsignalled LSP to PCE. But I think we should not equate a path computation request with delegation completely. With delegation your aim is to give up some control and let PCE run the show, one should not expect the behavior of this action to be exactly same as a path computation request/response. > > a. path request timeout: > > draft-ietf-pce-stateful-pce-10 does not describe a timer mechanism that a > PCC might use to detect an initial path request timeout. From reading the > draft, the PCE is not mandated to compute a path and send a PCUpd message in > response to a PCRpt message even when the LSP is down. > > PCC can have faith in the PCE to respond as it sees fit based on the overall network. PCC can always choose to revoke the delegation if it is not happy. > > b. No path found by PCE: > > Even if one assumes that the PCE attempts a path computation within a > reasonable time from receiving the PCRpt message, how will it communicate to > PCC a failure to find a path for that LSP? > This is interesting, can a PCUpd message with empty ERO fulfill this? Another interesting case is when the path is not found because of some constraint, PCE can still send PCUpd message with a path relaxing some constraints and its attributes. PCC has a choice to accept them or not. > > > c. Synchronous path computation: > > How can a PCC request synchronous path computation for a set of > link/node/SRLG disjoint LSP paths? With PCReq/PCRep, this was possible via > the SVEC object. > > We need to enhance the mechanism to group LSPs via [1] to consider the above. It is in my to do list :) [1] http://datatracker.ietf.org/doc/draft-minei-pce-association-group/ Regards, Dhruv > > I appreciate if you could provide comments on the above points. > > > > Regards, > > Mustapha. > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
