Re: [Pce] Whither Stateless PCE?

[Ina Minei <[e-mail]>]

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:[e-mail]]
> *Sent:* Thursday, April 14, 2016 09:39
> *To:* LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui,
> Mustapha (Nokia - CA); [e-mail]; 'Dhruv Dhody'
> *Cc:* [e-mail]
> *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:[e-mail] <[e-mail]>] *代表 *
> [e-mail]
> *发送时间:* 2016年4月9日 1:04
> *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA);
> [e-mail]; 'Dhruv Dhody'
> *抄送:* [e-mail]
> *主题:* 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:[e-mail] <[e-mail]>] *On
> Behalf Of *[e-mail]
> *Sent:* Friday, April 08, 2016 18:29
> *To:* Aissaoui, Mustapha (Nokia - CA); [e-mail]; 'Dhruv Dhody'
> *Cc:* [e-mail]
> *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:[e-mail] <[e-mail]>] *On
> Behalf Of *EXT Adrian Farrel
> *Sent:* Thursday, April 07, 2016 12:48 AM
> *To:* 'Dhruv Dhody'
> *Cc:* [e-mail]
> *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:* [e-mail] [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Dhruv Dhody
> *Sent:* 06 April 2016 23:07
> *To:* Farrel Adrian
> *Cc:* [e-mail]
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
>
>
> _______________________________________________
>
> Pce mailing list
>
> [e-mail]
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>