Re: [Pce] Whither Stateless PCE?

[Ina Minei <[e-mail]>]

Thank you all. I will remove the text that states that the ERO must include
at least one subobject, and state instead that the ERO may indeed be empty.

I will post shortly, comments welcome.

On Fri, Aug 19, 2016 at 8:56 AM, Julien Meuric <[e-mail]>
wrote:

> 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 - [e-mail]:
>
> 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 <[e-mail]>
> 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 - <[e-mail]:
>
> 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:[e-mail] <[e-mail]>]
> *Sent:* Thursday, August 11, 2016 19:25
>
>
>
> 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
>
>    destination of the LSP. "
>
>
>
> 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:
>
>    <path>::= <intended_path>
>
>              [<actual_attribute_list><actual_path>]
>
>              <intended_attribute_list>
>
>
>
> [SLI] Why do you interleave intended and actual parameters ? Why not
> having :
>
>    <path>::= <intended_path>
>
>                         <intended_attribute_list>
>
>                          [<actual_path><actual_attribute_list>]
>
> %%% This was done in order to keep the encoding backwards compatible with
> existing implementations
>
>
>
>
>
>
>
>    <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]>[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]>
> [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
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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 [e-mail]://www.ietf.org/mailman/listinfo/pce
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>
>