Subject: Re: [Pce] Whither Stateless PCE?

From: Ina Minei <[email-masked]>
Date: Mon, 8 Aug 2016 15:20:04 -0700

Stephane,

Please see some answers inline below ###.

Ina

[snip]

> Example :
>
> Case#1 : PCC has no path, it reports empty ERO in PCRpt (case Olivier was
> mentioning), PCE vendor does not compute path and does not send update
>

### In this case, the ERO must at least have one loose hop, the
destination. This will be clarified in the next version of the draft in
(the new) section 6.1. See proposed text below:

The intended path, represented by the ERO object, is REQUIRED.  If
   the ERO ojbect is missing, the receiving PCE MUST send a PCErr
   message with Error-type=6 (Mandatory Object missing) and Error-value
   to be assigned by IANA (ERO object missing).  When present, the ERO
   object SHOULD contain at least one subobject, representing the
   destination of the LSP. "

This is a SHOULD and not a MUST because an empty ERO is allowed for
the end of synchronization marker.

> ð  Using PCReq could make sense here as Mustapha proposed or clearly
> mentioning that PCRpt with empty ERO needs to trigger path computation and
> sending PCUpd.
>
### This will be clarified in the next version of the draft as well, the
mode of operation is to mandate a PCReq before the delegation.

Proposed text (new section 5.8.2)
5.8.2. Switching from Passive Stateful to Active Stateful

This section deals with the scenario of an LSP transitioning from a
passive stateful to an active stateful mode of operation. When the
LSP has no working path, prior to delegating the LSP, the PCC MUST
first use the procedure defined in Section 5.8.1 to request the
initial path from the PCE. This is required because the action of
delegating the LSP to a PCE using a PCRpt message is not an explicit
request to the 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.
The PCRpt message MUST NOT be used by the PCC to attempt to request a path
from the PCE.
When the LSP is delegated after its setup, it may be useful for the
PCC to communicate to the PCE the locally configured intended
configuration parameters, so that the PCE may reuse them in its
computations. Such parameters MAY be acquired through an out of band
channel, or MAY be communicated in the PCRpt message delegating the
LSPs, by including them as part of the intented-attribute-list as
explained in Section 6.1. An implementation MAY allow policies on
the PCC to determine the configuration parameters to be sent to the
PCE.
(the intended-attribute-list is new, see more below).

Case#2 : PCC has a path, it reports ERO, PCE has different constraints
> configured, we expect PCE to update the path
>
>
>
> Case#3 : PCC has a path, it reports ERO, PCE has a different optimization
> algorithm leading to a different ERO with the same constraint, we expect
> PCE to update the path
>
>
>
>
>
> Case#2 and Case#3 requires the PCE to know the existing constraint
> configured on PCC for the LSP , by using only PCRpt we cannot have such
> constraint information, we need a PCReq also to describe the configuration
> (PCRpt only describes operation state => Mustapha’s point again).
>
>
>
> ### This observation is correct, the PCRpt currently carries the actual
state.
As Robert mentioned in his reply to this thread, the issue you are raising
is the one of intended versus actual state.
After discussing at the IETF with Julien, Dhruv, Mustapha as well as
offline with other implementors, the proposed solution is to include both
the configured (intended) and actual state in the PCRpt.

The following text is proposed to section 6.1
  The format of the PCRpt message is as follows:

   <PCRpt Message> ::= <Common Header>
                       <state-report-list>
Where:

   <state-report-list> ::= <state-report>[<state-report-list>]

   <state-report> ::= [<SRP>]
                      <LSP>
                      <path>
 Where:
   <path>::= <intended_path>
             [<actual_attribute_list><actual_path>]
             <intended_attribute_list>

   <actual_attribute-list>::=[<BANDWIDTH>]
                             [<metric-list>]

Where:
   <intended_path> is represented by the ERO object defined in
   section 7.9 of [RFC5440].
   <actual_attribute_list> consists of the actual computed and signaled
values
   of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440].
   <actual_path> is represented by the RRO object defined in
   section 7.10 of [RFC5440].
   <intended_attribute_list> is the attribute-list defined in
   section 6.5 of [RFC5440] and extended by PCEP extensions.

The intended_attribute_list maps to the attribute_list in Section 6.5
   of [RFC5440] and is used to convey the requested parameters of the
   LSP path.  This is needed in order to support the switch from passive
   to active stateful PCE as described in Section 5.8.2.  When included
   as part of the intended_attribute_list, the meaning of the BANDWIDTH
   object is the requested bandwidth as intended by the operator.  In
   this case, the BANDWIDTH Object-Type of 1 SHOULD be used.  Similarly,
   to indicate a limiting constraint, the METRIC object SHOULD be
   included as part of the intended_attribute_list with the B flag set
   and with a specific metric value.  To indicate the optimization
   metric, the METRIC object SHOULD be included as part of the
   intended_attribute_list with the B flag unset and the metric value
   set to zero.  Note that the intended_attribute_list is optional and
   thus may be omitted.  In this case, the PCE MAY use the values in the
   actual_attribute_list as the requested parameters for the path.

  The actual_attribute_list consists of the actual computed and
   signaled values of the BANDWIDTH and METRIC objects defined in
   [RFC5440].  When included as part of the actual_attribute_list,
   Object-Type 2 ([RFC5440]) SHOULD be used for the BANDWIDTH object and
   the C flag SHOULD be set in the METRIC object ([RFC5440]).

>
> Best Regards,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Fatai Zhang [mailto:[email-masked]]
> *Sent:* Thursday, April 14, 2016 09:39
> *To:* LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui,
> Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
> *Cc:* [email-masked]
> *Subject:* 答复: [Pce] Whither Stateless PCE?
>
>
>
> Hi Stephane,
>
>
>
> Could you clarify what is interoperability issue in multivendor
> environment (multivendor in one administrative domain?)?
>
>
>
> Do you mean there is interoperability issue when vendor 1 supports
> stateless PCE and vendor 2 supports stateful PCE?
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks
>
>
>
> Fatai
>
>
>
> *发件人**:* Pce [mailto:[email-masked] <[email-masked]>] *代表 *
> [email-masked]
> *发送时间:* 2016年4月9日 1:04
> *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA);
> [email-masked]; 'Dhruv Dhody'
> *抄送:* [email-masked]
> *主题:* Re: [Pce] Whither Stateless PCE?
>
>
>
> Hi,
>
>
>
> I fully agree that stateful PCE draft needs to be more clear about how a
> PCC retrieves a path when the delegation starts and the LSP has just been
> configured (does it need to compute locally first and then delegate, or do
> PCReq as Olivier proposed …).
>
> I want to add my voice to what Olivier said about the inconsistent
> behaviors we see today in implementations leading to lack of
> interoperability.
>
> The most important point is that we need to find a solution as soon as
> possible as some people wants to deploy it in multivendor environment and
> find workaround (btw vendor1 and vendor 2) to fix it interop is not the
> right way to go …
>
> This is a question that the WG must work on and close asap.
>
>
>
> Best Regards,
>
>
>
> Stephane
>
>
>
>
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* Friday, April 08, 2016 18:29
> *To:* Aissaoui, Mustapha (Nokia - CA); [email-masked]; 'Dhruv Dhody'
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] Whither Stateless PCE?
>
>
>
> Hello all,
>
> IMHO the discussion must be split into is 2 different subjects:
>
> 1/ PCInit message could be seen as an independent message compared to
> other PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit message
> after a request that comes from another interface (e.g. a RestConf API)
> instead of PCReq that comes from the router itself through PCEP. In fact,
> when you configure a tunnel on the router, only the path computation part
> is requested to the PCE. Complements of tunnel configuration still remain
> in the router configuration. In case of PCInit, all information must be
> provided to the router. This could be for example the traffic steering. So,
> IMHO, it is normal that the PCInit message evolves through extensions
> different from the other PCEP messages, and in particular PCReq, as it is
> not triggered by the same entity, i.e. an external component instead the
> PCC router itself.
>
> 2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 will
> continue to be mandatory for stateful both passive and active mode even if
> it needs clarification in the draft. Let me explain. In passive stateful, a
> PCReq/PCRep sequence is drawn in Figure 7 of the pce stateful draft prior
> to the PCRpt message Now, the ambiguity comes from the active stateful mode
> and figure 8. Why is the PCReq/PCRep sequence not mentioned? Of course the
> tunnel is delegated in this mode, but, the delegation object has been added
> as an extension to the PCReq message in the same draft. So, IMHO, at the
> creation of the tunnel, the draft must precise that a PCReq/PCRep exchange
> with delegation=1 must be used prior to the PCRpt to be coherent with RFC
> 5440 and passive stateful mode.
>
> The problem occured during our evaluation of commercial products on which
> we made interoperability tests. Indeed we observed different behaviours
> that are due to the draft ambiguity and conduct to some interoperability
> issues. The different cases are as follow:
>  - a/ - PCReq/PCRep exchange to obtain a valid ERO before the PCRpt message
>  - b/ - PCReq message to obtain a valid ERO but with no reaction from the
> PCE which is not conform to RFC5440
>  - c/ - PCRpt with empty ERO (looks strange. What is the meaning of an
> Empty ERO ? a loose path ? no path ? )/PCupd to get a valid path which
> overlaps with standard RFC5440 PCReq/PCRep.
>  - d/ - PCRpt with empty ERO and no PCUpd leaving the tunnel down.
>
> Thus, PCC/PCE that used PCRpt/PCupd messages for active stateful mode are
> incompatible with PCC/PCE that used standard PCReq/PCrep exchange. We could
> not mix both behaviours (PCC that use PCReq message with PCE that react to
> PCRpt with empty ERO and reciprocally). The problem occurs only at the
> creation of the tunnel. Once created and up the tunnel is reported and
> updated by means of PCRpt / PCupd messages correctly in all cases.
>
> To summarize: PCInit message could leave independently from other
> messages. PCReq is the basis of PCE and is mandatory in all use cases
> included the active stateful mode, but this need to be clarify in the pce
> stateful draft.
>
> Regards
>
> Olivier
>
> Le 07/04/2016 23:22, Aissaoui, Mustapha (Nokia - CA) a écrit :
>
> Hi Adrian,
>
> I raised in December 2014 the technical issue in
> draft-ietf-pce-stateful-pce that a PCC must be able to convey the original
> parameters (constraints) of the LSP path (Bandwidth, Metric, and LSPA
> objects) using a PCReq message to a PCE and subsequently delegate the LSP
> to PCE using the PCRpt message. Otherwise, when the LSP is delegated to PCE
> only the operational values of these parameters can be included in the
> PCRpt message. The latter means that the PCE will update the path without
> knowing exactly the original parameters.
>
>
>
> For me, PCReq/PCRep are an integral part of operating an LSP in stateful
> mode.
>
>
>
> Here is the link to the archived thread:
>
> https://mailarchive.ietf.org/arch/search/?email_list=pce&
> so=-date&q=%22+Path+Computation+Request+in+Active+Stateful+PCE%22
>
>
>
> Regards,
>
> Mustapha.
>
>
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *EXT Adrian Farrel
> *Sent:* Thursday, April 07, 2016 12:48 AM
> *To:* 'Dhruv Dhody'
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] Whither Stateless PCE?
>
>
>
> I think you are probably right, Dhruv.
>
>
>
> But referencing the ways in which customers deploy may be a little
> limiting.
>
> To say PCE is widely deployed (even after all these years) may be an
> exaggeration.
>
> Although we do have some clues about what is currently being pushed for
> deployment.
>
>
>
> I think you have mainly grasped my point, however. We need to understand
> which extensions are definitely only needed in one mode or another, and
> which should be done in all modes (either because they are needed or
> because we don't know).
>
>
>
> OTOH, I suppose TLVs are just TLVs. Once you specified the TLV it is not
> rocket science to include it in a message. In fact, it is probably one line
> of text to include it and only a short paragraph to describe additional
> processing in other modes once you have described how it is used in one
> mode.
>
>
>
> Where does that leave us?
>
>
>
> Adrian
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Dhruv Dhody
> *Sent:* 06 April 2016 23:07
> *To:* Farrel Adrian
> *Cc:* [email-masked]
> *Subject:* Re: [Pce] Whither Stateless PCE?
>
>
>
> Hi Adrian,
>
>
>
> Even in the brave new world of Stateful PCE, PCReq and PCRep messages do
> play a role in the passive stateful PCE mode. PCReq/PCRep also play a
> crucial role in the inter-domain and inter-layer context in the new
> proposal like stateful H-PCE.
>
>
>
> At the same time mandating that every extension (say SFC) must also be
> specified in a stateless manner when no customer deploy in such a way,
> might be overkill.
>
>
>
> Perhaps we need to look at it case by case!
>
>
>
> Dhruv
>
>
>
> On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <[email-masked]> wrote:
>
> Once upon a time, in a working group far, far away, PCE was basically
> stateless.
> PCE acted in response to questions asked by PCCs.
>
> These days, everyone is excited by stateful PCEs and there is a lot of
> initiation (of LSPs or of control of LSPs).
>
> In the jabber room during today's meeting Ravi noted that not a lot of the
> new
> drafts (maybe none of them) talk about PCReq messages. This raises the
> question
> in our minds as to whether stateless PCE is obsolete.
>
> If (and only if) this mode of PCE usage has gone out of fashion, we *might*
> consider cleaning up the protocol and architecture so that we don't need
> to make
> protocol extensions to PCReq and PCRep messages when we make extensions to
> PCInit messages.
>
> Thoughts?
>
> Adrian
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
>
>
> _______________________________________________
>
> Pce mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
> Thank you.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: <[email-masked]>
Date: Tue, 9 Aug 2016 07:33:01 +0000

Hi Ina,

Thanks for the feedback
Please find some inline comments.

Brgds,

Stephane

From: Ina Minei [mailto:[email-masked]]
Sent: Tuesday, August 09, 2016 00:20
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]; Dhruv Dhody; [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Stephane,

Ina

[snip]

Example :

Case#1 : PCC has no path, it reports empty ERO in PCRpt (case Olivier was mentioning), PCE vendor does not compute path and does not send update

### In this case, the ERO must at least have one loose hop, the destination. This will be clarified in the next version of the draft in (the new) section 6.1. See proposed text below:

[SLI] Having PCC sending an ERO with the destination as loose hop does not make sense to me while PCC has no path. How do you differentiate with the case the PCC reports a loose path to the destination from the case it has no path ?

=>  Using PCReq could make sense here as Mustapha proposed or clearly mentioning that PCRpt with empty ERO needs to trigger path computation and sending PCUpd.
### This will be clarified in the next version of the draft as well, the mode of operation is to mandate a PCReq before the delegation.

[SLI] Ok thanks, that’s the good way to go.

The PCRpt message MUST NOT be used by the PCC to attempt to request a path from the PCE.

Case#2 : PCC has a path, it reports ERO, PCE has different constraints configured, we expect PCE to update the path

Case#3 : PCC has a path, it reports ERO, PCE has a different optimization algorithm leading to a different ERO with the same constraint, we expect PCE to update the path

Case#2 and Case#3 requires the PCE to know the existing constraint configured on PCC for the LSP , by using only PCRpt we cannot have such constraint information, we need a PCReq also to describe the configuration (PCRpt only describes operation state => Mustapha’s point again).

### This observation is correct, the PCRpt currently carries the actual state.
As Robert mentioned in his reply to this thread, the issue you are raising is the one of intended versus actual state.
After discussing at the IETF with Julien, Dhruv, Mustapha as well as offline with other implementors, the proposed solution is to include both the configured (intended) and actual state in the PCRpt.

[SLI] Why do you interleave intended and actual parameters ? Why not having :
   <path>::= <intended_path>
                        <intended_attribute_list>
                         [<actual_path><actual_attribute_list>]

Where:
   <actual_attribute_list> consists of the actual computed and signaled values

Best Regards,

Stephane

From: Fatai Zhang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 14, 2016 09:39
To: LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
Subject: 答复: [Pce] Whither Stateless PCE?

Hi Stephane,

Could you clarify what is interoperability issue in multivendor environment (multivendor in one administrative domain?)?

Do you mean there is interoperability issue when vendor 1 supports stateless PCE and vendor 2 supports stateful PCE?

Thanks

Fatai

发件人: Pce [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2016年4月9日 1:04
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] Whither Stateless PCE?

Hi,

I fully agree that stateful PCE draft needs to be more clear about how a PCC retrieves a path when the delegation starts and the LSP has just been configured (does it need to compute locally first and then delegate, or do PCReq as Olivier proposed …).

I want to add my voice to what Olivier said about the inconsistent behaviors we see today in implementations leading to lack of interoperability.

The most important point is that we need to find a solution as soon as possible as some people wants to deploy it in multivendor environment and find workaround (btw vendor1 and vendor 2) to fix it interop is not the right way to go …

Best Regards,

Stephane

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hello all,

1/ PCInit message could be seen as an independent message compared to other PCReq/PCRep, PCRpt and PCUp. Indeed, the PCE uses the PCInit message after a request that comes from another interface (e.g. a RestConf API) instead of PCReq that comes from the router itself through PCEP. In fact, when you configure a tunnel on the router, only the path computation part is requested to the PCE. Complements of tunnel configuration still remain in the router configuration. In case of PCInit, all information must be provided to the router. This could be for example the traffic steering. So, IMHO, it is normal that the PCInit message evolves through extensions different from the other PCEP messages, and in particular PCReq, as it is not triggered by the same entity, i.e. an external component instead the PCC router itself.

2/ But, this will not make PCReq message obsolete. Indeed, RFC5440 will continue to be mandatory for stateful both passive and active mode even if it needs clarification in the draft. Let me explain. In passive stateful, a PCReq/PCRep sequence is drawn in Figure 7 of the pce stateful draft prior to the PCRpt message Now, the ambiguity comes from the active stateful mode and figure 8. Why is the PCReq/PCRep sequence not mentioned? Of course the tunnel is delegated in this mode, but, the delegation object has been added as an extension to the PCReq message in the same draft. So, IMHO, at the creation of the tunnel, the draft must precise that a PCReq/PCRep exchange with delegation=1 must be used prior to the PCRpt to be coherent with RFC 5440 and passive stateful mode.

The problem occured during our evaluation of commercial products on which we made interoperability tests. Indeed we observed different behaviours that are due to the draft ambiguity and conduct to some interoperability issues. The different cases are as follow:
 - a/ - PCReq/PCRep exchange to obtain a valid ERO before the PCRpt message
 - b/ - PCReq message to obtain a valid ERO but with no reaction from the PCE which is not conform to RFC5440
 - c/ - PCRpt with empty ERO (looks strange. What is the meaning of an Empty ERO ? a loose path ? no path ? )/PCupd to get a valid path which overlaps with standard RFC5440 PCReq/PCRep.
 - d/ - PCRpt with empty ERO and no PCUpd leaving the tunnel down.

Thus, PCC/PCE that used PCRpt/PCupd messages for active stateful mode are incompatible with PCC/PCE that used standard PCReq/PCrep exchange. We could not mix both behaviours (PCC that use PCReq message with PCE that react to PCRpt with empty ERO and reciprocally). The problem occurs only at the creation of the tunnel. Once created and up the tunnel is reported and updated by means of PCRpt / PCupd messages correctly in all cases.

To summarize: PCInit message could leave independently from other messages. PCReq is the basis of PCE and is mandatory in all use cases included the active stateful mode, but this need to be clarify in the pce stateful draft.

Regards

Olivier

Hi Adrian,

I raised in December 2014 the technical issue in draft-ietf-pce-stateful-pce that a PCC must be able to convey the original parameters (constraints) of the LSP path (Bandwidth, Metric, and LSPA objects) using a PCReq message to a PCE and subsequently delegate the LSP to PCE using the PCRpt message. Otherwise, when the LSP is delegated to PCE only the operational values of these parameters can be included in the PCRpt message. The latter means that the PCE will update the path without knowing exactly the original parameters.

For me, PCReq/PCRep are an integral part of operating an LSP in stateful mode.

https://mailarchive.ietf.org/arch/search/?email_list=pce&so=-date&q=%22+Path+Computation+Request+in+Active+Stateful+PCE%22

Regards,

Mustapha.

From: Pce [mailto:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Thursday, April 07, 2016 12:48 AM
To: 'Dhruv Dhody'
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

But referencing the ways in which customers deploy may be a little limiting.

To say PCE is widely deployed (even after all these years) may be an exaggeration.

Although we do have some clues about what is currently being pushed for deployment.

I think you have mainly grasped my point, however. We need to understand which extensions are definitely only needed in one mode or another, and which should be done in all modes (either because they are needed or because we don't know).

OTOH, I suppose TLVs are just TLVs. Once you specified the TLV it is not rocket science to include it in a message. In fact, it is probably one line of text to include it and only a short paragraph to describe additional processing in other modes once you have described how it is used in one mode.

Adrian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hi Adrian,

Even in the brave new world of Stateful PCE, PCReq and PCRep messages do play a role in the passive stateful PCE mode. PCReq/PCRep also play a crucial role in the inter-domain and inter-layer context in the new proposal like stateful H-PCE.

At the same time mandating that every extension (say SFC) must also be specified in a stateless manner when no customer deploy in such a way, might be overkill.

Dhruv

On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Once upon a time, in a working group far, far away, PCE was basically stateless.
PCE acted in response to questions asked by PCCs.

In the jabber room during today's meeting Ravi noted that not a lot of the new
drafts (maybe none of them) talk about PCReq messages. This raises the question
in our minds as to whether stateless PCE is obsolete.

If (and only if) this mode of PCE usage has gone out of fashion, we *might*
consider cleaning up the protocol and architecture so that we don't need to make
protocol extensions to PCReq and PCRep messages when we make extensions to
PCInit messages.

Thoughts?

Adrian

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

Pce mailing list

[email-masked]<mailto:[email-masked]>

Thank you.

Thank you.

Thank you.

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

---

From: Ina Minei <[email-masked]>
Date: Thu, 11 Aug 2016 10:25:14 -0700

Stephane,

Please see inline %%%

> [SLI] Having PCC sending an ERO with the destination as loose hop does not
> make sense to me while PCC has no path. How do you differentiate with the
> case the PCC reports a loose path to the destination from the case it has
> no path ?
>
%%% The PCC must at the minimum know what the destination is, and a loose
hop is a way to encode this. I cannot think of any situation in which the
PCC does not know the destination. I don't think the PCE should worry about
whether the PCC will request a path or not, since we are mandating a PCReq
to request a path, the PCE does not have to imply it from the ERO.

>                          [<actual_path><actual_attribute_list>]
%%% This was done in order to keep the encoding backwards compatible with
existing implementations

> *发送时间**:* 2016年4月9日 1:04
> *收件人**:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA);
> *抄送**:* [email-masked]
> *主题**:* Re: [Pce] Whither Stateless PCE?
>
>
>
> Hi,
>
>
>

---

From: <[email-masked]>
Date: Fri, 12 Aug 2016 07:22:26 +0000

Hi Ina,

%%% The PCC must at the minimum know what the destination is, and a loose hop is a way to encode this. I cannot think of any situation in which the PCC does not know the destination. I don't think the PCE should worry about whether the PCC will request a path or not, since we are mandating a PCReq to request a path, the PCE does not have to imply it from the ERO

[SLI] PCC knows the destination but when LSP is delegated, PCC does not own path of the LSP anymore, so ERO should reflect what PCE sent to PCC. Again in case of no path available from PCE, PCE will send empty ERO, PCE will not really understand if PCC reports back an ERO with the destination in the ERO as loose hop as this may imply that the PCC is trying to establish a path to the destination using loose hop which is not compliant with what PCE tells. You may fall into PCUpd/PCRpt loop in such scenario because PCE will try to update PCC until PCC reports the same path as PCE sent in ERO.

Best Regards,

Stephane

Sent: Thursday, August 11, 2016 19:25

Stephane,

Please see inline %%%

[snip]

Example :

[SLI] Having PCC sending an ERO with the destination as loose hop does not make sense to me while PCC has no path. How do you differentiate with the case the PCC reports a loose path to the destination from the case it has no path ?
%%% The PCC must at the minimum know what the destination is, and a loose hop is a way to encode this. I cannot think of any situation in which the PCC does not know the destination. I don't think the PCE should worry about whether the PCC will request a path or not, since we are mandating a PCReq to request a path, the PCE does not have to imply it from the ERO.

%%% This was done in order to keep the encoding backwards compatible with existing implementations

Where:

Best Regards,

Stephane

Hi Stephane,

Thanks

Fatai

Hi,

Best Regards,

Stephane

Hello all,

Regards

Olivier

Hi Adrian,

Regards,

Mustapha.

Adrian

Hi Adrian,

Dhruv

Thoughts?

Adrian

Pce mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Julien Meuric <[email-masked]>
Date: Fri, 12 Aug 2016 11:30:57 +0200

Hi Ina, hi Stéphane,

I am glad to see this discussion progressing, sorry for
interrupting.

RFC 5440 defines the END-POINTS object, which includes an egress ID.
Do not you think it could be considered to unambiguously convey the
egress destination-attached ID in the PCRpt, without colliding with
the loose ERO case?

Cheers,

Julien

Aug. 12, 2016 -
<[email-masked]:

Hi
Ina,

%%% The PCC must at the minimum know what
the destination is, and a loose hop is a way to encode this. I
cannot think of any situation in which the PCC does not know
the destination. I don't think the PCE should worry about
whether the PCC will request a path or not, since we are
mandating a PCReq to request a path, the PCE does not have to
imply it from the ERO

[SLI] PCC knows the destination but when
LSP is delegated, PCC does not own path of the LSP anymore, so
ERO should reflect what PCE sent to PCC. Again in case of no
path available from PCE, PCE will send empty ERO, PCE will not
really understand if PCC reports back an ERO with the
destination in the ERO as loose hop as this may imply that the
PCC is trying to establish a path to the destination using
loose hop which is not compliant with what PCE tells. You may
fall into PCUpd/PCRpt loop in such scenario because PCE will
try to update PCC until PCC reports the same path as PCE sent
in ERO.

Best
Regards,

Stephane

From:
Ina Minei [mailto:[email-masked]]

Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui,
Mustapha (Nokia - CA); [email-masked]; Dhruv Dhody;
[email-masked]

Stephane,

Please see inline %%%

[snip]

Example
:

Case#1
: PCC has no path, it reports empty
ERO in PCRpt (case Olivier was
mentioning), PCE vendor does not
compute path and does not send
update

###
In this case, the ERO must at least have
one loose hop, the destination. This will
be clarified in the next version of the
draft in (the new) section 6.1. See
proposed text below:

The
intended path, represented by the ERO
object, is REQUIRED.  If

the ERO ojbect is missing, the
receiving PCE MUST send a PCErr

message with Error-type=6 (Mandatory
Object missing) and Error-value

to be assigned by IANA (ERO object
missing).  When present, the ERO

object SHOULD contain at least one
subobject, representing the

This
is a SHOULD and not a MUST because an
empty ERO is allowed for

the
end of synchronization marker.

[SLI] Having PCC
sending an ERO with the destination as
loose hop does not make sense to me
while PCC has no path. How do you
differentiate with the case the PCC
reports a loose path to the destination
from the case it has no path ?

%%% The PCC must at the minimum
know what the destination is, and a loose hop is a way
to encode this. I cannot think of any situation in
which the PCC does not know the destination. I don't
think the PCE should worry about whether the PCC will
request a path or not, since we are mandating a PCReq
to request a path, the PCE does not have to imply it
from the ERO.

ð
Using
PCReq could make sense here as
Mustapha proposed or clearly
mentioning that PCRpt with empty ERO
needs to trigger path computation
and sending PCUpd.

###
This will be clarified in the next version
of the draft as well, the mode of
operation is to mandate a PCReq before the
delegation.

[SLI]
Ok thanks, that’s the good way to go.

Proposed
text (new section 5.8.2)

5.8.2. Switching from Passive
Stateful to Active Stateful

This section deals with the
scenario of an LSP
transitioning from a

passive stateful to an
active stateful mode of
operation. When the

LSP has no working path,
prior to delegating the LSP,
the PCC MUST

first use the procedure
defined in Section 5.8.1 to
request the

initial path from the PCE.
This is required because the
action of

delegating the LSP to a PCE
using a PCRpt message is not
an explicit

request to the 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.

The PCRpt message MUST NOT
be used by the PCC to
attempt to request a path
from the PCE.

When the LSP is delegated
after its setup, it may be
useful for the

PCC to communicate to the
PCE the locally configured
intended

configuration parameters, so
that the PCE may reuse them
in its

computations. Such
parameters MAY be acquired
through an out of band

channel, or MAY be
communicated in the PCRpt
message delegating the

LSPs, by including them as
part of the
intented-attribute-list as

explained in Section 6.1. An
implementation MAY allow
policies on

the PCC to determine the
configuration parameters to
be sent to the

PCE.

(the intended-attribute-list
is new, see more below).

Case#2
: PCC has a path, it reports
ERO, PCE has different
constraints configured, we
expect PCE to update the path

Case#3
: PCC has a path, it reports
ERO, PCE has a different
optimization algorithm leading
to a different ERO with the same
constraint, we expect PCE to
update the path

Case#2
and Case#3 requires the PCE to
know the existing constraint
configured on PCC for the LSP ,
by using only PCRpt we cannot
have such constraint
information, we need a PCReq
also to describe the
configuration (PCRpt only
describes operation state =>
Mustapha’s point again).

###
This observation is correct, the PCRpt
currently carries the actual state.

As
Robert mentioned in his reply to this
thread, the issue you are raising is
the one of intended versus actual
state.

After
discussing at the IETF with Julien,
Dhruv, Mustapha as well as offline
with other implementors, the proposed
solution is to include both the
configured (intended) and actual state
in the PCRpt.

The
following text is proposed to section
6.1

The format of the PCRpt message is as
follows:

<PCRpt Message> ::= <Common
Header>

<state-report-list>

Where:

<state-report-list> ::=
<state-report>[<state-report-list>]

<state-report> ::=
[<SRP>]

<LSP>

<path>

Where:

[SLI]
Why do you interleave intended and
actual parameters ? Why not having :

%%% This was done in order to keep
the encoding backwards compatible with existing
implementations

[<metric-list>]

Where:

<intended_path> is represented
by the ERO object defined in

<actual_attribute_list>
consists of the actual computed and
signaled values

of the <BANDWIDTH> and
<metric-lists> objects defined
in [RFC5440].

<actual_path> is represented by
the RRO object defined in

<intended_attribute_list> is
the attribute-list defined in

section 6.5 of [RFC5440] and extended
by PCEP extensions.

The
intended_attribute_list maps to the
attribute_list in Section 6.5

of [RFC5440] and is used to convey
the requested parameters of the

LSP path.  This is needed in order
to support the switch from passive

to active stateful PCE as described
in Section 5.8.2.  When included

as part of the
intended_attribute_list, the meaning
of the BANDWIDTH

object is the requested bandwidth
as intended by the operator.  In

this case, the BANDWIDTH
Object-Type of 1 SHOULD be used.
Similarly,

to indicate a limiting constraint,
the METRIC object SHOULD be

included as part of the
intended_attribute_list with the B
flag set

and with a specific metric value.
To indicate the optimization

metric, the METRIC object SHOULD be
included as part of the

intended_attribute_list with the B
flag unset and the metric value

set to zero.  Note that the
intended_attribute_list is optional
and

thus may be omitted.  In this case,
the PCE MAY use the values in the

actual_attribute_list as the
requested parameters for the path.

The actual_attribute_list consists of
the actual computed and

signaled values of the BANDWIDTH and
METRIC objects defined in

[RFC5440].  When included as part of
the actual_attribute_list,

Object-Type 2 ([RFC5440]) SHOULD be
used for the BANDWIDTH object and

the C flag SHOULD be set in the
METRIC object ([RFC5440]).

Best
Regards,

Stephane

From:
Fatai Zhang [mailto:[email-masked]]

Sent: Thursday, April
14, 2016 09:39

To: LITKOWSKI
Stephane OBS/OINIS; DUGEON
Olivier IMT/OLN; Aissaoui,
Mustapha (Nokia - CA);
[email-masked];
'Dhruv Dhody'

Cc: [email-masked]

Subject: 答
复:
[Pce] Whither Stateless PCE?

Hi
Stephane,

Could
you clarify what is
interoperability issue in
multivendor
environment (multivendor in
one administrative domain?)?

Do
you mean there is
interoperability issue when
vendor 1 supports stateless
PCE and vendor 2 supports
stateful PCE?

Thanks

Fatai

发件人:
Pce [mailto:[email-masked]]
代表
[email-masked]

发送时间:
2016年4月9日 1:04

收件人:
DUGEON Olivier IMT/OLN;
Aissaoui, Mustapha
(Nokia - CA); [email-masked];
'Dhruv Dhody'

抄送:
[email-masked]

主题:
Re: [Pce] Whither
Stateless PCE?

Hi,

I
fully agree that stateful
PCE draft needs to be more
clear about how a PCC
retrieves a path when the
delegation starts and the
LSP has just been configured
(does it need to compute
locally first and then
delegate, or do PCReq as
Olivier proposed …).

I
want to add my voice to what
Olivier said about the
inconsistent behaviors we
see today in implementations
leading to lack of
interoperability.

The
most important point is that
we need to find a solution
as soon as possible as some
people wants to deploy it in
multivendor environment and
find workaround (btw vendor1
and vendor 2) to fix it
interop is not the right way
to go …

This
is a question that the WG
must work on and close asap.

Best
Regards,

Stephane

From:
Pce [mailto:[email-masked]]
On Behalf Of [email-masked]

Sent: Friday,
April 08, 2016 18:29

To: Aissaoui,
Mustapha (Nokia - CA);
[email-masked];
'Dhruv Dhody'

Cc: [email-masked]

Subject: Re:
[Pce] Whither Stateless
PCE?

Hello all,

IMHO the discussion must be
split into is 2 different
subjects:

1/ PCInit message could be
seen as an independent message
compared to other PCReq/PCRep,
PCRpt and PCUp. Indeed, the
PCE uses the PCInit message
after a request that comes
from another interface (e.g. a
RestConf API) instead of PCReq
that comes from the router
itself through PCEP. In fact,
when you configure a tunnel on
the router, only the path
computation part is requested
to the PCE. Complements of
tunnel configuration still
remain in the router
configuration. In case of
PCInit, all information must
be provided to the router.
This could be for example the
traffic steering. So, IMHO, it
is normal that the PCInit
message evolves through
extensions different from the
other PCEP messages, and in
particular PCReq, as it is not
triggered by the same entity,
i.e. an external component
instead the PCC router itself.

2/ But, this will not make
PCReq message obsolete.
Indeed, RFC5440 will continue
to be mandatory for stateful
both passive and active mode
even if it needs clarification
in the draft. Let me explain.
In passive stateful, a
PCReq/PCRep sequence is drawn
in Figure 7 of the pce
stateful draft prior to the
PCRpt message Now, the
ambiguity comes from the
active stateful mode and
figure 8. Why is the
PCReq/PCRep sequence not
mentioned? Of course the
tunnel is delegated in this
mode, but, the delegation
object has been added as an
extension to the PCReq message
in the same draft. So, IMHO,
at the creation of the tunnel,
the draft must precise that a
PCReq/PCRep exchange with
delegation=1 must be used
prior to the PCRpt to be
coherent with RFC 5440 and
passive stateful mode.

The problem occured during our
evaluation of commercial
products on which we made
interoperability tests. Indeed
we observed different
behaviours that are due to the
draft ambiguity and conduct to
some interoperability issues.
The different cases are as
follow:

- a/ - PCReq/PCRep exchange
to obtain a valid ERO before
the PCRpt message

- b/ - PCReq message to
obtain a valid ERO but with no
reaction from the PCE which is
not conform to RFC5440

- c/ - PCRpt with empty ERO
(looks strange. What is the
meaning of an Empty ERO ? a
loose path ? no path ? )/PCupd
to get a valid path which
overlaps with standard RFC5440
PCReq/PCRep.

- d/ - PCRpt with empty ERO
and no PCUpd leaving the
tunnel down.

Thus, PCC/PCE that used
PCRpt/PCupd messages for
active stateful mode are
incompatible with PCC/PCE that
used standard PCReq/PCrep
exchange. We could not mix
both behaviours (PCC that use
PCReq message with PCE that
react to PCRpt with empty ERO
and reciprocally). The problem
occurs only at the creation of
the tunnel. Once created and
up the tunnel is reported and
updated by means of PCRpt /
PCupd messages correctly in
all cases.

To summarize: PCInit message
could leave independently from
other messages. PCReq is the
basis of PCE and is mandatory
in all use cases included the
active stateful mode, but this
need to be clarify in the pce
stateful draft.

Regards

Olivier

Le
07/04/2016 23:22, Aissaoui,
Mustapha (Nokia - CA) a
écrit :

Hi
Adrian,

I
raised in December 2014
the technical issue in
draft-ietf-pce-stateful-pce
that a PCC must be able to
convey the original
parameters (constraints)
of the LSP path
(Bandwidth, Metric, and
LSPA objects) using a
PCReq message to a PCE and
subsequently delegate the
LSP to PCE using the PCRpt
message. Otherwise, when
the LSP is delegated to
PCE only the operational
values of these parameters
can be included in the
PCRpt message. The latter
means that the PCE will
update the path without
knowing exactly the
original parameters.

For
me, PCReq/PCRep are an
integral part of operating
an LSP in stateful mode.

Here
is the link to the
archived thread:

Regards,

Mustapha.

From:
Pce [mailto:[email-masked]]
On Behalf Of EXT
Adrian Farrel

Sent:
Thursday, April 07,
2016 12:48 AM

To: 'Dhruv
Dhody'

Cc: [email-masked]

Subject: Re:
[Pce] Whither
Stateless PCE?

I think you
are probably right,
Dhruv.

But
referencing the ways in
which customers deploy
may be a little
limiting.

To say PCE
is widely deployed (even
after all these years)
may be an exaggeration.

Although we
do have some clues about
what is currently being
pushed for deployment.

I think you
have mainly grasped my
point, however. We need
to understand which
extensions are
definitely only needed
in one mode or another,
and which should be done
in all modes (either
because they are needed
or because we don't
know).

OTOH, I
suppose TLVs are just
TLVs. Once you specified
the TLV it is not rocket
science to include it in
a message. In fact, it
is probably one line of
text to include it and
only a short paragraph
to describe additional
processing in other
modes once you have
described how it is used
in one mode.

Where does
that leave us?

Adrian

From:
[email-masked]
[mailto:[email-masked]]
On Behalf Of Dhruv
Dhody

Sent: 06
April 2016 23:07

To: Farrel
Adrian

Cc: [email-masked]

Subject:
Re: [Pce] Whither
Stateless PCE?

Hi
Adrian,

Even
in the brave new
world of Stateful
PCE, PCReq and
PCRep messages do
play a role in the
passive
stateful PCE mode.
PCReq/PCRep also
play a crucial
role in the
inter-domain and
inter-layer
context in the new
proposal like
stateful H-PCE.

At
the same time
mandating that
every
extension (say
SFC) must also be
specified in a
stateless manner
when no customer
deploy in such
a way, might be
overkill.

Perhaps
we need to look at
it case by case!

Dhruv

On
Wed, Apr 6, 2016
at 4:00 PM, Adrian
Farrel <[email-masked]>
wrote:

Once
upon a time, in a
working group far,
far away, PCE was
basically
stateless.

PCE acted in
response to
questions asked by
PCCs.

These days,
everyone is
excited by
stateful PCEs and
there is a lot of

initiation (of
LSPs or of control
of LSPs).

In the jabber room
during today's
meeting Ravi noted
that not a lot of
the new

drafts (maybe none
of them) talk
about PCReq
messages. This
raises the
question

in our minds as to
whether stateless
PCE is obsolete.

If (and only if)
this mode of PCE
usage has gone out
of fashion, we
*might*

consider cleaning
up the protocol
and architecture
so that we don't
need to make

protocol
extensions to
PCReq and PCRep
messages when we
make extensions to

PCInit messages.

Thoughts?

Adrian

Pce mailing list

[email-masked]

Pce mailing list

[email-masked]

Thank you.

Thank you.

Thank you.

Pce mailing list

[email-masked]

Thank you.

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Tue, 16 Aug 2016 23:27:34 +0000

Julien, Stephane, and Ina,
The lsp-identifiers tlv has the information about source and destination of the lsp. So no need to use the END-POINTS object for that.

I think it may be just fine to continue using an empty ERO in the PCRpt message to mean there is no current path for a non-zero plsp-id. When the plsp-id is zero we know that it is the end of synchronization marker.

Mustapha.
Sent from my iPhone

On Aug 12, 2016, at 5:31 AM, Julien Meuric <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ina, hi Stéphane,

I am glad to see this discussion progressing, sorry for interrupting.

RFC 5440 defines the END-POINTS object, which includes an egress ID. Do not you think it could be considered to unambiguously convey the egress destination-attached ID in the PCRpt, without colliding with the loose ERO case?

Cheers,

Julien

Aug. 12, 2016 - <[email-masked]<mailto:[email-masked]>:
Hi Ina,

Best Regards,

Stephane

Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; Dhruv Dhody; [email-masked]<mailto:[email-masked]>

Stephane,

Please see inline %%%

[snip]

Example :

Where:

Best Regards,

Stephane

From: Fatai Zhang [mailto:<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 14, 2016 09:39
To: LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: 答 复: [Pce] Whither Stateless PCE?

Hi Stephane,

Thanks

Fatai

发件人: Pce [<mailto:[email-masked]>mailto:[email-masked]] 代表 <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
发送时间: 2016年4月9日 1:04
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
抄送: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] Whither Stateless PCE?

Hi,

Best Regards,

Stephane

From: Pce [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; 'Dhruv Dhody'
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hello all,

Regards

Olivier

Hi Adrian,

<https://mailarchive.ietf.org/arch/search/?email_list=pce&so=-date&q=%22+Path+Computation+Request+in+Active+Stateful+PCE%22>https://mailarchive.ietf.org/arch/search/?email_list=pce&so=-date&q=%22+Path+Computation+Request+in+Active+Stateful+PCE%22

Regards,

Mustapha.

From: Pce [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of EXT Adrian Farrel
Sent: Thursday, April 07, 2016 12:48 AM
To: 'Dhruv Dhody'
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Adrian

From: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Whither Stateless PCE?

Hi Adrian,

Dhruv

On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Thoughts?

Adrian

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

Pce mailing list

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Julien Meuric <[email-masked]>
Date: Fri, 19 Aug 2016 17:56:17 +0200

Hi Mustapha,

You are right: the information is already there, this is an
non-issue. As a result, an ERO which is not empty can be considered
as loose.

Cheers,

Julien

Aug. 17, 2016 -
[email-masked]:

The lsp-identifiers tlv has the
information about source and destination of the lsp. So no
need to use the END-POINTS object for that.

I think it may be just fine to
continue using an empty ERO in the PCRpt message to mean
there is no current path for a non-zero plsp-id. When the
plsp-id is zero we know that it is the end of
synchronization marker.

Mustapha.

Sent from my iPhone

On Aug 12, 2016, at 5:31 AM, Julien Meuric <[email-masked]>
wrote:

Hi Ina, hi Stéphane,

RFC 5440 defines the END-POINTS object, which includes an
egress ID. Do not you think it could be considered to
unambiguously convey the egress destination-attached ID in
the PCRpt, without colliding with the loose ERO case?

Cheers,

Julien

Aug. 12, 2016 - <[email-masked]:

Hi
Ina,

%%% The PCC must at the minimum
know what the destination is, and a loose hop is a
way to encode this. I cannot think of any situation
in which the PCC does not know the destination. I
don't think the PCE should worry about whether the
PCC will request a path or not, since we are
mandating a PCReq to request a path, the PCE does
not have to imply it from the ERO

[SLI] PCC knows the destination
but when LSP is delegated, PCC does not own path of
the LSP anymore, so ERO should reflect what PCE sent
to PCC. Again in case of no path available from PCE,
PCE will send empty ERO, PCE will not really
understand if PCC reports back an ERO with the
destination in the ERO as loose hop as this may
imply that the PCC is trying to establish a path to
the destination using loose hop which is not
compliant with what PCE tells. You may fall into
PCUpd/PCRpt loop in such scenario because PCE will
try to update PCC until PCC reports the same path as
PCE sent in ERO.

Best
Regards,

Stephane

From:

Stephane,

Please see inline %%%

[snip]

Example
:

Case#1
: PCC has no path, it
reports empty ERO in PCRpt
(case Olivier was
mentioning), PCE vendor
does not compute path and
does not send update

###
In this case, the ERO must at
least have one loose hop, the
destination. This will be
clarified in the next version of
the draft in (the new) section
6.1. See proposed text below:

The
intended path, represented by
the ERO object, is REQUIRED.
If

the ERO ojbect is missing,
the receiving PCE MUST send a
PCErr

message with Error-type=6
(Mandatory Object missing) and
Error-value

to be assigned by IANA (ERO
object missing).  When
present, the ERO

object SHOULD contain at
least one subobject,
representing the

This
is a SHOULD and not a MUST
because an empty ERO is allowed
for

the

[SLI]
Having PCC sending an ERO with
the destination as loose hop
does not make sense to me
while PCC has no path. How do
you differentiate with the
case the PCC reports a loose
path to the destination from
the case it has no path ?

%%% The PCC must at the
minimum know what the destination is, and a
loose hop is a way to encode this. I cannot
think of any situation in which the PCC does
not know the destination. I don't think the
PCE should worry about whether the PCC will
request a path or not, since we are
mandating a PCReq to request a path, the PCE
does not have to imply it from the ERO.

ð
Using
PCReq could make sense
here as Mustapha proposed
or clearly mentioning that
PCRpt with empty ERO needs
to trigger path
computation and sending
PCUpd.

###
This will be clarified in the
next version of the draft as
well, the mode of operation is
to mandate a PCReq before the
delegation.

[SLI]
Ok thanks, that’s the good way
to go.

Proposed
text (new section 5.8.2)

Stateful to Active
Stateful

This section deals
with the scenario
of an LSP
transitioning from
a

passive stateful
to an active
stateful mode of
operation. When
the

LSP has no working
path, prior to
delegating the
LSP, the PCC MUST

first use the
procedure defined
in Section 5.8.1
to request the

initial path from
the PCE. This is
required because
the action of

delegating the LSP
to a PCE using a
PCRpt message is
not an explicit

request to the 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.

The PCRpt message
MUST NOT be used
by the PCC to
attempt to request
a path from the
PCE.

When the LSP is
delegated after
its setup, it may
be useful for the

PCC to communicate
to the PCE the
locally configured
intended

configuration
parameters, so
that the PCE may
reuse them in its

computations. Such
parameters MAY be
acquired through
an out of band

channel, or MAY be
communicated in
the PCRpt message
delegating the

LSPs, by including
them as part of
the
intented-attribute-list
as

explained in
Section 6.1. An
implementation MAY
allow policies on

the PCC to
determine the
configuration
parameters to be
sent to the

PCE.

(the
intended-attribute-list
is new, see more
below).

Case#2
: PCC has a path, it
reports ERO, PCE has
different constraints
configured, we expect
PCE to update the path

Case#3
: PCC has a path, it
reports ERO, PCE has a
different optimization
algorithm leading to a
different ERO with the
same constraint, we
expect PCE to update
the path

Case#2
and Case#3 requires
the PCE to know the
existing constraint
configured on PCC for
the LSP , by using
only PCRpt we cannot
have such constraint
information, we need a
PCReq also to describe
the configuration
(PCRpt only describes
operation state =>
Mustapha’s point
again).

###
This observation is correct,
the PCRpt currently carries
the actual state.

As
Robert mentioned in his
reply to this thread, the
issue you are raising is the
one of intended versus
actual state.

After
discussing at the IETF with
Julien, Dhruv, Mustapha as
well as offline with other
implementors, the proposed
solution is to include both
the configured (intended)
and actual state in the
PCRpt.

The
following text is proposed
to section 6.1

The format of the PCRpt
message is as follows:

<PCRpt Message> ::=
<Common Header>

<state-report-list>

Where:

<state-report-list>
::=

<state-report> ::=
[<SRP>]

<LSP>

<path>

Where:

<path>::=
<intended_path>

[SLI]
Why do you interleave intended
and actual parameters ? Why
not having :

<path>::=
<intended_path>

%%% This was done in
order to keep the encoding backwards
compatible with existing implementations

[<metric-list>]

Where:

<intended_path> is
represented by the ERO
object defined in

<actual_attribute_list> consists of the actual computed and
signaled values

of the <BANDWIDTH>
and <metric-lists>
objects defined in
[RFC5440].

<actual_path> is
represented by the RRO
object defined in

section 6.5 of [RFC5440]
and extended by PCEP
extensions.

The
intended_attribute_list
maps to the attribute_list
in Section 6.5

of [RFC5440] and is used
to convey the requested
parameters of the

LSP path.  This is needed
in order to support the
switch from passive

to active stateful PCE as
described in Section
5.8.2.  When included

as part of the
intended_attribute_list,
the meaning of the
BANDWIDTH

object is the requested
bandwidth as intended by
the operator.  In

this case, the BANDWIDTH
Object-Type of 1 SHOULD be
used.  Similarly,

to indicate a limiting
constraint, the METRIC
object SHOULD be

included as part of the
intended_attribute_list
with the B flag set

and with a specific
metric value.  To indicate
the optimization

metric, the METRIC object
SHOULD be included as part
of the

intended_attribute_list
with the B flag unset and
the metric value

set to zero.  Note that
the
intended_attribute_list is
optional and

thus may be omitted.  In
this case, the PCE MAY use
the values in the

actual_attribute_list as
the requested parameters
for the path.

The actual_attribute_list
consists of the actual
computed and

signaled values of the
BANDWIDTH and METRIC objects
defined in

[RFC5440].  When included
as part of the
actual_attribute_list,

Object-Type 2 ([RFC5440])
SHOULD be used for the
BANDWIDTH object and

the C flag SHOULD be set in
the METRIC object
([RFC5440]).

Best
Regards,

Stephane

From:
Fatai Zhang
[mailto:[email-masked]]

Sent:
Thursday, April
14, 2016 09:39

To:
LITKOWSKI Stephane
OBS/OINIS; DUGEON
Olivier IMT/OLN;
Aissaoui, Mustapha
(Nokia - CA);
[email-masked];
'Dhruv Dhody'

Cc: [email-masked]

Subject: 答
复:
[Pce] Whither
Stateless PCE?

Hi
Stephane,

Could
you clarify what
is
interoperability
issue in
multivendor
environment
(multivendor in
one administrative
domain?)?

Do
you mean there is
interoperability
issue when vendor
1 supports
stateless PCE and
vendor 2 supports
stateful PCE?

Thanks

Fatai

发件人:

发送时间:
2016年4月9日 1:04

收件人:
DUGEON Olivier
IMT/OLN;
Aissaoui,
Mustapha
(Nokia - CA);

[email-masked];
'Dhruv Dhody'

抄送:
[email-masked]

主题:
Re: [Pce]
Whither
Stateless PCE?

Hi,

I
fully agree that
stateful PCE draft
needs to be more
clear about how a
PCC retrieves a
path when the
delegation starts
and the LSP has
just been
configured (does
it need to compute
locally first and
then delegate, or
do PCReq as
Olivier proposed
…).

I
want to add my
voice to what
Olivier said about
the inconsistent
behaviors we see
today in
implementations
leading to lack of
interoperability.

The
most important
point is that we
need to find a
solution as soon
as possible as
some people wants
to deploy it in
multivendor
environment and
find workaround
(btw vendor1 and
vendor 2) to fix
it interop is not
the right way to
go …

This
is a question that
the WG must work
on and close asap.

Best
Regards,

Stephane

From:
Pce [mailto:[email-masked]]
On Behalf
Of [email-masked]

Sent:
Friday, April
08, 2016 18:29

To:
Aissaoui,
Mustapha
(Nokia - CA);

[email-masked];
'Dhruv Dhody'

Cc: [email-masked]

Subject:
Re: [Pce]
Whither
Stateless PCE?

Hello all,

IMHO the discussion
must be split into
is 2 different
subjects:

1/ PCInit message
could be seen as an
independent message
compared to other
PCReq/PCRep, PCRpt
and PCUp. Indeed,
the PCE uses the
PCInit message after
a request that comes
from another
interface (e.g. a
RestConf API)
instead of PCReq
that comes from the
router itself
through PCEP. In
fact, when you
configure a tunnel
on the router, only
the path computation
part is requested to
the PCE. Complements
of tunnel
configuration still
remain in the router
configuration. In
case of PCInit, all
information must be
provided to the
router. This could
be for example the
traffic steering.
So, IMHO, it is
normal that the
PCInit message
evolves through
extensions different
from the other PCEP
messages, and in
particular PCReq, as
it is not triggered
by the same entity,
i.e. an external
component instead
the PCC router
itself.

2/ But, this will
not make PCReq
message obsolete.
Indeed, RFC5440 will
continue to be
mandatory for
stateful both
passive and active
mode even if it
needs clarification
in the draft. Let me
explain. In passive
stateful, a
PCReq/PCRep sequence
is drawn in Figure 7
of the pce stateful
draft prior to the
PCRpt message Now,
the ambiguity comes
from the active
stateful mode and
figure 8. Why is the
PCReq/PCRep sequence
not mentioned? Of
course the tunnel is
delegated in this
mode, but, the
delegation object
has been added as an
extension to the
PCReq message in the
same draft. So,
IMHO, at the
creation of the
tunnel, the draft
must precise that a
PCReq/PCRep exchange
with delegation=1
must be used prior
to the PCRpt to be
coherent with RFC
5440 and passive
stateful mode.

The problem occured
during our
evaluation of
commercial products
on which we made
interoperability
tests. Indeed we
observed different
behaviours that are
due to the draft
ambiguity and
conduct to some
interoperability
issues. The
different cases are
as follow:

- a/ - PCReq/PCRep
exchange to obtain a
valid ERO before the
PCRpt message

- b/ - PCReq
message to obtain a
valid ERO but with
no reaction from the
PCE which is not
conform to RFC5440

- c/ - PCRpt with
empty ERO (looks
strange. What is the
meaning of an Empty
ERO ? a loose path ?
no path ? )/PCupd to
get a valid path
which overlaps with
standard RFC5440
PCReq/PCRep.

- d/ - PCRpt with
empty ERO and no
PCUpd leaving the
tunnel down.

Thus, PCC/PCE that
used PCRpt/PCupd
messages for active
stateful mode are
incompatible with
PCC/PCE that used
standard PCReq/PCrep
exchange. We could
not mix both
behaviours (PCC that
use PCReq message
with PCE that react
to PCRpt with empty
ERO and
reciprocally). The
problem occurs only
at the creation of
the tunnel. Once
created and up the
tunnel is reported
and updated by means
of PCRpt / PCupd
messages correctly
in all cases.

To summarize: PCInit
message could leave
independently from
other messages.
PCReq is the basis
of PCE and is
mandatory in all use
cases included the
active stateful
mode, but this need
to be clarify in the
pce stateful draft.

Regards

Olivier

Le
07/04/2016 23:22,
Aissaoui, Mustapha
(Nokia - CA) a
écrit :

Hi
Adrian,

I
raised in
December 2014
the technical
issue in
that a PCC must
be able to
convey the
original
parameters
(constraints) of
the LSP path
(Bandwidth,
Metric, and LSPA
objects) using a
PCReq message to
a PCE and
subsequently
delegate the LSP
to PCE using the
PCRpt message.
Otherwise, when
the LSP is
delegated to PCE
only the
operational
values of these
parameters can
be included in
the PCRpt
message. The
latter means
that the PCE
will update the
path without
knowing exactly
the original
parameters.

For
me, PCReq/PCRep
are an integral
part of
operating an LSP
in stateful
mode.

Here
is the link to
the archived
thread:

Regards,

Mustapha.

From:
On Behalf
Of EXT
Adrian Farrel

Sent:
Thursday,
April 07, 2016
12:48 AM

To:
'Dhruv Dhody'

Cc: [email-masked]

Subject:
Re: [Pce]
Whither
Stateless PCE?

I
think you are
probably
right, Dhruv.

But
referencing
the ways in
which
customers
deploy may be
a little
limiting.

To
say PCE is
widely
deployed (even
after all
these years)
may be an
exaggeration.

Although
we do have
some clues
about what is
currently
being pushed
for
deployment.

I
think you have
mainly grasped
my point,
however. We
need to
understand
which
extensions are
definitely
only needed in
one mode or
another, and
which should
be done in all
modes (either
because they
are needed or
because we
don't know).

OTOH,
I suppose TLVs
are just TLVs.
Once you
specified the
TLV it is not
rocket science
to include it
in a message.
In fact, it is
probably one
line of text
to include it
and only a
short
paragraph to
describe
additional
processing in
other modes
once you have
described how
it is used in
one mode.

Where
does that
leave us?

Adrian

From:
[email-masked]
On Behalf
Of Dhruv
Dhody

Sent:
06 April 2016
23:07

To:
Farrel Adrian

Cc: [email-masked]

Subject:
Re: [Pce]
Whither
Stateless PCE?

Hi
Adrian,

Even
in the brave
new world of
Stateful PCE,
PCReq and
PCRep messages
do play a role
in the passive
stateful PCE
mode.
PCReq/PCRep
also play a
crucial role
in the
inter-domain
and
inter-layer
context in the
new proposal
like
stateful H-PCE.

At
the same time
mandating that
every
extension (say
SFC) must also
be specified
in a stateless
manner when no
customer
deploy in such
a way, might
be overkill.

Perhaps
we need to
look at it
case by case!

Dhruv

On
Wed, Apr 6,
2016 at 4:00
PM, Adrian

Once
upon a time,
in a working
group far, far
away, PCE was
basically
stateless.

PCE acted in
response to
questions
asked by PCCs.

These days,
everyone is
excited by
stateful PCEs
and there is a
lot of

initiation (of
LSPs or of
control of
LSPs).

In the jabber
room during
today's
meeting Ravi
noted that not
a lot of the
new

drafts (maybe
none of them)
talk about
PCReq
messages. This
raises the
question

in our minds
as to whether
stateless PCE
is obsolete.

If (and only
if) this mode
of PCE usage
has gone out
of fashion, we
*might*

consider
cleaning up
the protocol
and
architecture
so that we
don't need to
make

protocol
extensions to
PCReq and
PCRep messages
when we make
extensions to

PCInit
messages.

Thoughts?

Adrian

Pce mailing
list

[email-masked]

Pce mailing list

[email-masked]

Thank you.

Thank you.

Thank you.

Pce mailing list

[email-masked]

Thank you.

Pce mailing list

[email-masked]