Subject: [Pce] Path Computation Request in Active Stateful PCE

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Fri, 5 Dec 2014 23:38:48 +0000

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.

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.

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:

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.

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?

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.

I appreciate if you could provide comments on the above points.

Regards,
Mustapha.

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 6 Dec 2014 11:54:22 +0530

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

> 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

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>