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

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Tue, 14 Jun 2016 20:41:03 +0000

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

-----------------------------------------------------------------

---

From: Robert Varga <[email-masked]>
Date: Mon, 27 Jun 2016 15:58:40 +0200

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

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

---

From: Olivier Dugeon <[email-masked]>
Date: Tue, 28 Jun 2016 19:45:26 +0200

Hello Robert,

General comment: The proposal modifications has been written following different interoperability tests done on different commercial solutions of both PCE and PCC. The issue raised following these tests show that the draft has been interpreted differently and thus, need to be consolidated i.e. precise text when ambiguity take place.

More detail answers below.

Regards

Olivier

> LSP involves the PCC losing control over timing of route computation.
Well, from an operational point of view, there is a need to take back the control of LSP on a PCC. This new text just proposes to precise these process.
> to repeat this information anyway...
When a PCC loose its session with a PCE and try to setup a new PCEP session with a backup PCE, the later needs to know the details of the original request. Of course its a PCE problem, but if the PCC doesn't provide the information, how the PCE could collect them ?
> would be a PCErr) or the PCC does not support it (which is okay).
Yes. Good catch.
> config changing, or is this for sake of backup PCEs?
The first case apply as depending of the implementation, it is necessary to revoke the delegation before attempting to change CLI config on the PCC. Once the delegation is turn on, the PCC send a new PCRpt with the updated request-list.
The second case apply when the PCC loose the PCEP session with the primary PCE and start establish a PCEP session with its backup PCE for which it send PCRpt message with the reques-list.

> Also, would an active PCE be able to update this information?
PCE could override the information in its LSP database, but could not update the information on the router. PCEP is not NETCONF/YANG. I mean that PCEP statefull configuration are stored in the ephemeral configuration of the PCC while the config CLI  remains in the static configuration.
> would be more appropriate.
Up to you to place the propose text at the most suitable place in the draft.
> PCRpt -- but this text forbids empty EROs in PCRpt...
Well I understand the point. But, an empty ERO is something very strange for me ;-)

Concerning the end-of-sync marker, perhaps another marker could be used instead of an empty ERO.

For the PCEInitiate, again, it is strange for me to deploy a PCE on a network just to push on a PCC some tunnels without  ERO. This means that you let the PCC perform the CSPF while the PCE is build for that purpose. A simple NMS that push CLI or Netconf/Yang configuration is sufficient for this use case.
>
> Bye,
> Robert
>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce