Dear all, As promised, Stephane, Olivier and I worked on a proposal for updating draft-ietf-pce-stateful-pce to handle the transition from stateless or router-computed to active-stateful operation for an LSP. More specifically, We are proposing the addition of a new section 5.8.3 describing extensions for the following:
a. support of use of PCReq/PCRep for an LSP which does not have an initial path and which the PCC intends to delegate to the PCE. The proposal here is to first use the same procedure as in passive-stateful mode of operation with a PCReq/PCRep followed by sending the PCRpt message. b. passing LSP constraints when delegating an LSP which already has a working path. While PCE does not need to compute a path immediately, it needs to save the constraints for the next opportunity to update the path. In this case, the PCRpt messages is enhanced to contains an additional set of the LSP parameters such as LSPA, Metric, Bandwidth, and IRO objects to report the original constraints of the LSP. We are also proposing modifications to a couple of paragraphs in sections 5.8.2 and 6.1 to clarify the use of the PCRpt message and of the ERO object in PCRpt respectively. We appreciate if the authors of the draft and members of this WG provide feedback. Regards, Mustapha. ------------------------------ I. New Section 5.8.3 - Reporting LSP Constraints on LSP transition from Stateless/Router-Computed to Active Stateful Modes of Operation When an LSP transitions from a stateless or router-computed mode to an active stateful mode of operation and the LSP has no working path, PCC MUST first reuse the same procedure defined in passive stateful mode to request the initial path from PCE. This additional step is required for two reasons. First, the action of delegating the LSP to a PCE using a PCRpt message is not an explicit request to PCE to compute a path for the LSP. The only explicit way for a PCC to request a path from PCE is to send a PCReq message as per RFC 5440. Second, the PCRpt message does not contains the original constraints of the LSP path as configured by the user on the router. The PCRpt message may contain the operational or computed values of those same objects in the attribute-list. For example, the hop-count Metric object included in the PCRpt message will contain the computed value for the current path of the LSP but will not contain the hop-count bound the user may have configured on the router for this LSP. Note that since in this case the LSP has no working path, it may even not include any of the Metric objects in the attribute-list of the PCRpt message. To address the above situation, the PCReq message SHOULD include all the objects describing the current configuration of the LSP on the PCC : e.g. the relevant LSPA, Metric, Bandwidth, IRO, ... objects to convey the LSP path constraints to PCE. An implementation MAY allow policies on PCC to determine the configuration parameters to be sent to the PCE. The LSP object MAY also be included with the D-bit (Delegate bit) set to indicate to PCE that it intends to delegate this LSP. The PCE uses this indication to cache the constraint in these objects in anticipation of the subsequent PCRpt message which should confirm the delegation by setting the D-bit in the LSP object. The PCE may clear the cached information if no PCRpt message for that PLSP-ID is received within a finite amount of time. When an LSP transitions from a stateless or router-computed to an active stateful mode of operation and the LSP has a working path, there is no need to explicitly request a path from PCE at that point in time. While a PCC may decide to first use the passive stateful mode procedures as in the case above, there is no requirement for doing so. As such, this document defines an optional procedure by which the PCC can simply report the LSP constraints to the PCE in the PCRpt message. A PCC which supports this procedure MUST append an additional set of the relevant objects like LSPA, Metric, Bandwidth, and IRO objects, referred to as the request-list(1), in which it conveys the LSP path constraints to PCE. A PCE that receives a PCRpt with the request-list should assume the values contained in the request-list are the actual constraints. The values in the request-list must update any corresponding value saved for that PLSP-ID in the LSP database. A PCE that receives a PCRpt without the request-list and that PLSP-ID has no saved constraints in the LSP database should assume the values contained in the attribute-list are the actual constraints. In either case, the constraint values can be overridden by PCE policy. Note (1): RFC 5440 defines the request-list in the PCReq message as the above objects plus the RP and END-POINTS objects. As such we may need to refer to this differently. Maybe the constraint-list. II. Modifications to last paragraph in Section 5.8.2 - Active Stateful PCE LSP Update " The PCRpt message MUST NOT be used by PCC to request a path from PCE. Standard PCReq as defined in RFC 5440 MUST be used instead. A PCC MUST however NOT send to any PCE a Path Computation Request for a once the LSP is delegated LSP. Should the PCC decide it wants to issue a Path Computation Request on a delegated LSP, it MUST perform Delegation Revocation procedure first. " III. Modifications to sixth paragraph in Section 6.1 - The PCRpt Message " The intended path, represented by the ERO object, SHOULD be included in PCRpt by the PCC whenever the PCC has a valid, non-empty, ERO for the LSP. A valid ERO can be obtained by requesting a path from the local router CSPF or from PCE using the PCReq message before delegation as explained in Section 5.8.3. It can also be provided by local configuration on the router. A PCC MUST omit the ERO object otherwise. In all cases, a PCC MUST NOT send an empty ERO in a PCRpt message to PCE. The actual path, represented by the RRO object, SHOULD be included in PCRpt by the PCC when the path is up or active, but MAY be omitted if the path is down due to a signaling error or another failure. " -----------------------------------------------------------------
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
