Re: [Pce] Proposed text for handling stateless/router-computed to active-stateful transitions in draft-ietf-pce-stateful-pce

[Robert Varga <[e-mail]>]

On 06/14/2016 10:41 PM, Aissaoui, Mustapha (Nokia - CA) wrote:
> 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.

This is an intentional side-effect of changing synchrony. Delegating an
LSP involves the PCC losing control over timing of route computation.

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

I think this really is 'PCE policy', as this requires resources on the
PCE side, which are shared across multiple PCCs, hence a LRU or similar
should be allowed.

I am not sure what caching the information will achieve: the PCC cannot
rely on this information to be present, hence a subsequent PCRpt needs
to repeat this information anyway...

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

I think we also need an indication that the PCC supports this procedure
-- otherwise the PCE cannot discern if the information is missing (which
would be a PCErr) or the PCC does not support it (which is okay).

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

I am not sure I understand this part. Is this related to the PCE which
has current control of the LSP and is triggered for things like CLI
config changing, or is this for sake of backup PCEs?

Also, would an active PCE be able to update this information?

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

The intent here is that for any particular LSP exactly one mode of
operation (passive or active) is used and they are not intermixed --
exactly because of synchrony problems arising from such use.

I agree with the updated text, but I also wonder if a paragraph in 5.8
would be more appropriate.

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

This would contradict the end-of-sync marker definition.

This also means that every PCE implementation must support the
router-initiated computation synchrony -- which can problematic with
some implementation architectures.

It also creates some friction with pce-initiated: the PCE is free to use
an empty ERO in PCEInitiate and the PCC is required to mirror it back in
PCRpt -- but this text forbids empty EROs in PCRpt...

Bye,
Robert