Subject: Re: [Pce] Whither Stateless PCE?

From: Ina Minei <[email-masked]>
Date: Thu, 1 Sep 2016 16:22:35 -0700

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 <[email-masked]>
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 - [email-masked]:
>
> 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]>
> 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]:
>
> 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] <[email-masked]>]
> *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:[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]>[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]>
> [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
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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 [email-masked]://www.ietf.org/mailman/listinfo/pce
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>
>

---

From: <[email-masked]>
Date: Fri, 2 Sep 2016 08:59:17 +0000

Thanks Ina,

If everyone agrees, is it possible to have a statement about PCE telling PCC that no path has been found using empty ERO ? This should cause PCC to remove the path from the network until PCE advertise a new PCUpdate with a non empty ERO.

Best Regards,

Stephane

From: Ina Minei [mailto:[email-masked]]
Sent: Friday, September 02, 2016 01:23
To: MEURIC Julien IMT/OLN
Cc: Aissaoui, Mustapha (Nokia - CA); LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

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.

On Fri, Aug 19, 2016 at 8:56 AM, Julien Meuric <[email-masked]<mailto:[email-masked]>> 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 - [email-masked]<mailto:[email-masked]>:
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,

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,

%%% 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]]
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:

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

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>]
%%% This was done in order to keep the encoding backwards compatible with existing implementations

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

Thank you.

Thank you.

Pce mailing list

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

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

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 2 Sep 2016 11:28:33 +0200

Hello Ina, all,

Like for the end of sync, I would suggest to used the NO_PATH object defined in RFC5440 instead of empty ERO. The NO-PATH object has been defined exactly for this meaning: there is no path. An empty ERO has variable interpretation which is not good for a standard i.e. it could mean that there is really no path, no computed ERO, or the path is loose.

So, I would suggest the following text (section 6.1, page 25 line 25)

   "The intended path, represented by the ERO object, is REQUIRED.  If
   the ERO object 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). If the PCC does not have
   a path for a delegated LSP, it MUST replace the ERO object by the
   NO_PATH object defined in RFC5440."

Regards

Olivier

BTW, In the original text, there is a misspelling in line 26 s/ojbect/object/ and I think you would mean PCC instead of PCE in line 29.

Le 02/09/2016 01:22, Ina Minei a écrit :
> On Fri, Aug 19, 2016 at 8:56 AM, Julien Meuric <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Mustapha,
>
>     Aug. 17, 2016 - [email-masked] <mailto:[email-masked]>:
>>     On Aug 12, 2016, at 5:31 AM, Julien Meuric <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>     Hi Ina, hi Stéphane,
>>>
>>>     Aug. 12, 2016 - <[email-masked] <mailto:[email-masked]>:
>>>>
>>>>     Hi Ina,
>>>>
>>>>      
>>>>
>>>>     *From:*Ina Minei [mailto:[email-masked]]
>>>>             ð  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.
>>>>
>>>>             *From:*Fatai Zhang [mailto:[email-masked] <mailto:[email-masked]>]
>>>>             *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]>
>>>>             *发件人**:*Pce [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'
>>>>             *抄送**:[email-masked] <mailto:[email-masked]>
>>>>             *主题**:*Re: [Pce] Whither Stateless PCE?
>>>>
>>>>              
>>>>
>>>>             Hi,
>>>>
>>>>              
>>>>
>>>>             *From:*Pce [mailto:[email-masked]] *On Behalf Of [email-masked] <mailto:[email-masked]>
>>>>             *To:* Aissaoui, Mustapha (Nokia - CA); <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>; 'Dhruv Dhody'
>>>>             *Cc:* [email-masked] <mailto:[email-masked]>
>>>>                 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]] *On Behalf Of *EXT Adrian Farrel
>>>>                 *Cc:* [email-masked] <mailto:[email-masked]>
>>>>                 *From:[email-masked] <mailto:[email-masked]> [mailto:[email-masked]] *On Behalf Of *Dhruv Dhody
>>>>                 *Cc:* [email-masked] <mailto:[email-masked]>
>>>>                 On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>                 [email-masked] <mailto:[email-masked]>
>>>>                 https://www.ietf.org/mailman/listinfo/pce <https://www.ietf.org/mailman/listinfo/pce>
>>>>
>>>>                  
>>>>
>>>>                  
>>>>
>>>>                 [email-masked] <mailto:[email-masked]>
>>>>
>>>>                 https://www.ietf.org/mailman/listinfo/pce <https://www.ietf.org/mailman/listinfo/pce>
>>>>
>>>>              
>>>>
>>>>             _______________________________________________ Pce mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pce <https://www.ietf.org/mailman/listinfo/pce>
>>>>
>>>>          
>>>>
>>>>     [email-masked] <mailto:[email-masked]>
>>>>     https://www.ietf.org/mailman/listinfo/pce <https://www.ietf.org/mailman/listinfo/pce>
>>>     _______________________________________________ Pce mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pce <https://www.ietf.org/mailman/listinfo/pce>
>

---

From: <[email-masked]>
Date: Fri, 2 Sep 2016 09:43:07 +0000

Hi Olivier,

Do you also suggest to use NO-PATH in PCUpdate when PCE has no more path available for a particular LSP ?
Even if I think this could be a right way to go, we need to take care about backward compatibility, there are running codes now that are not using NO-PATH at all for PCRpt/PCUpd and we must not break those implementations.

Best Regards,

From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Friday, September 02, 2016 11:29
To: Ina Minei; MEURIC Julien IMT/OLN
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Hello Ina, all,

Olivier

Cheers,

Julien

Mustapha.
Sent from my iPhone

Cheers,

Julien

Best Regards,

Stephane

Stephane,

Please see inline %%%

[snip]

Example :

Where:

Best Regards,

Stephane

Hi Stephane,

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,

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

Thank you.

Thank you.

Pce mailing list

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

Pce mailing list

---

From: Olivier Dugeon <[email-masked]>
Date: Fri, 2 Sep 2016 14:26:06 +0200

Hello Stéphane,

> Do you also suggest to use NO-PATH in PCUpdate when PCE has no more path available for a particular LSP ?
Yes indeed. NO-PATH object would be used each time message report/update an LSP without a valid path. In RFC5440, when a PCE received a PCReq message from a PCC, it must answer a PCRep with a NO-PATH object if it would not be able to find a suitable path that meet the requested constraints. So, for the consistency of standard, the PCUpd message must carry a NO-PATH object if no suitable path is available.
> Even if I think this could be a right way to go, we need to take care about backward compatibility, there are running codes now that are not using NO-PATH at all for PCRpt/PCUpd and we must not bre…
Agree. But, as we face some interoperability issue of those implementations regarding the empty ERO, it is necessary to update the code. I prefer to clarify the actual standard and obtain interoperable implementations instead of letting the standard unclear or subject to variable interpretation and run into others interoperability issue when new implementations come into the market.

Regards

Olivier
>
>  
>
> Best Regards,
>
>  
>
>  
>
> *From:*Pce [mailto:[email-masked]] *On Behalf Of *Olivier Dugeon
> *Sent:* Friday, September 02, 2016 11:29
> *To:* Ina Minei; MEURIC Julien IMT/OLN
> *Cc:* [email-masked]
>                         *发 件人**:*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,
>
>                          
>
>                         *To:* Aissaoui, Mustapha (Nokia - CA); [email-masked] <mailto:[email-masked]>; 'Dhruv Dhody'
>                         _______________________________________________ Pce mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/pce
>
>                      
>

---

From: Ina Minei <[email-masked]>
Date: Wed, 7 Sep 2016 08:57:50 -0700

Olivier,

I think if we replace MUST with SHOULD in the text you provided that would
work for the transition. Can implementors comment on the impact?

Ina

On Fri, Sep 2, 2016 at 5:26 AM, Olivier Dugeon <[email-masked]>
wrote:

> Yes indeed. NO-PATH object would be used each time message report/update
> an LSP without a valid path. In RFC5440, when a PCE received a PCReq
> message from a PCC, it must answer a PCRep with a NO-PATH object if it
> would not be able to find a suitable path that meet the requested
> constraints. So, for the consistency of standard, the PCUpd message must
> carry a NO-PATH object if no suitable path is available.
>
> Even if I think this could be a right way to go, we need to take care
> about backward compatibility, there are running codes now that are not
> using NO-PATH at all for PCRpt/PCUpd and we must not break those
> implementations.
>
> Agree. But, as we face some interoperability issue of those
> implementations regarding the empty ERO, it is necessary to update the
> code. I prefer to clarify the actual standard and obtain interoperable
> implementations instead of letting the standard unclear or subject to
> variable interpretation and run into others interoperability issue when new
> implementations come into the market.
>
> Regards
>
> Olivier
>
>
>
> Best Regards,
>
>
>
>
>
> Behalf Of *Olivier Dugeon
> Like for the end of sync, I would suggest to used the NO_PATH object
> defined in RFC5440 instead of empty ERO. The NO-PATH object has been
> defined exactly for this meaning: there is no path. An empty ERO has
> variable interpretation which is not good for a standard i.e. it could mean
> that there is really no path, no computed ERO, or the path is loose.
>
> BTW, In the original text, there is a misspelling in line 26
> s/ojbect/object/ and I think you would mean PCC instead of PCE in line 29.
>
> 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.
>
>
>
> Aug. 17, 2016 - <[email-masked]>[email-masked]:
>
> Aug. 12, 2016 - < <[email-masked]>
> [email-masked]:
>
> Hi Ina,
>
>
>
> *From:* Fatai Zhang [mailto: <[email-masked]>[email-masked]]
>
> Mustapha (Nokia - CA); <[email-masked]>[email-masked]; 'Dhruv
> Dhody'
> *Cc:* <[email-masked]>[email-masked]
> *发 件人**:* Pce [ <[email-masked]>mailto:[email-masked]
> <[email-masked]>] *代 表 [email-masked]
> *发 送时间**:* 2016年4月9日 1:04
> *收 件人**:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA);
> *抄 送**:* <[email-masked]>[email-masked]
> *主 题**:* Re: [Pce] Whither Stateless PCE?
>
>
>
> Hi,
>
>
>
> *From:* Pce [ <[email-masked]>mailto:[email-masked]
> <[email-masked]>] *On Behalf Of * <[email-masked]>
> [email-masked]
> *Cc:* <[email-masked]>[email-masked]
> <https://mailarchive.ietf.org/>https://mailarchive.ietf.org/a
> rch/search/?email_list=pce&so=-date&q=%22+Path+Computation+
> Request+in+Active+Stateful+PCE%22
>
>
>
> Regards,
>
> Mustapha.
>
>
>
> *From:* Pce [ <[email-masked]>mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *EXT Adrian Farrel
> *Cc:* <[email-masked]>[email-masked]
> *From:* <[email-masked]>[email-masked] [
> <[email-masked]>mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Dhruv Dhody
> *Cc:* <[email-masked]>[email-masked]
> On Wed, Apr 6, 2016 at 4:00 PM, Adrian Farrel < <[email-masked]>
> [email-masked]> wrote:
>
> <[email-masked]>[email-masked]
> <https://www.ietf.org/mailman/>https://www.ietf.org/mailman/listinfo/pce
>
>
>
>
>
> _______________________________________________ Pce mailing list
> <[email-masked]>[email-masked] <https://www.ietf.org/mailman/listinfo/pce>
> _______________________________________________ Pce mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pce
>

---

From: Robert Varga <[email-masked]>
Date: Thu, 8 Sep 2016 11:38:24 +0200

On 09/07/2016 05:57 PM, Ina Minei wrote:
> I think if we replace MUST with SHOULD in the text you provided that
> would work for the transition. Can implementors comment on the impact?

The change in PCRpt format is incompatible with fielded installations.

OpenDaylight will refuse a PCRpt consisting of (LSP, NO-PATH) and will
raise an Mandatory Object Missing PCErr, leading to failure to perform
initial state synchronization. The requirement has been there since
revision 05 (at least) and has been clarified in revision 16.

Bye,
Robert

---

From: Olivier Dugeon <[email-masked]>
Date: Thu, 8 Sep 2016 15:10:01 +0200

Hello Robert,

> revision 05 (at least) and has been clarified in revision 16.
Agree. But, as we face to some interoperability issues between various implementation, whatever the solution we choose, we need new release, so new version of firmware in the routers and new software for the PCE. So, I prefer to have a clear fix without any ambiguity instead of patch what wil continue to be subject to misinterpretation.

Regarding OpenDayLight, I think that the modification is not too huge:

Add NO-PATH object in 'path-definition' group in pcep-types.yang (line 1027 - 1031)

    grouping path-definition {
        uses explicit-route-object;
+      uses no-path-object;
        uses lsp-attributes;
    }

Or if you prefer

    grouping path-definition {
+        choice report-path {
+            mandatory true;
+
+        case ero {       
            uses explicit-route-object;
+        }
+
+        case no-path {
+           uses no-path-object;
+        }
        uses lsp-attributes;
    }

I also look at the Stateful07TopologySessionListener() class where the PCRpt is handle. At any moment the code check that there is a valid ERO (i.e. method buildPath() line 389 and following). I also made some tests with Juniper router with RSVP-TE tunnel setup and delegated, but without an explicit route set in the config. The Juniper router report the tunnel through a PCRpt message without ERO. Just an RRO. And this is correctly handle by OpenDayLight.

So, for me there is no much issue in OpenDayLight no manage NO-PATH Object.

Regards

Olivier

---

From: Robert Varga <[email-masked]>
Date: Thu, 8 Sep 2016 15:20:36 +0200

On 09/08/2016 03:10 PM, Olivier Dugeon wrote:
> Agree. But, as we face to some interoperability issues between various
> implementation, whatever the solution we choose, we need new release, so
> new version of firmware in the routers and new software for the PCE. So,
> I prefer to have a clear fix without any ambiguity instead of patch what
> wil continue to be subject to misinterpretation.
> 

I do agree that the change is not that big, but it will lead to the same
interoperability issues we have had with -02 and -07, which required
explicit configuration to deal with network-wide upgrades.

Unlike the previous break in protocol, the draft now has an IANA early
allocation, which prohibits us from breaking the protocol. Quoting
https://tools.ietf.org/html/rfc7120#section-2:

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

Bye,
Robert

---

From: <[email-masked]>
Date: Thu, 8 Sep 2016 14:11:07 +0000

> whatever the solution we choose, we need new release, so new version of firmware in the routers and new software for the PCE

Yes but some changes can be introduced as easy fix while introducing NO-PATH may not be so trivial from a coding point of view (leading to not being able to be introduced in minor release as a fix).
Moreover as already told, introducing new things is possible as long as we do not break what is working today (between some implementations, even if not all).

Introducing NO-PATH is possible if we still support the “old” approach using empty ERO (so both can be used) => everyone will have to fix.

From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Thursday, September 08, 2016 15:10
To: Robert Varga; Ina Minei
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Hello Robert,

Or if you prefer

Regards

Olivier

Bye,

Robert

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Thu, 8 Sep 2016 21:59:55 +0000

Hi Olivier,
While I understand the need for consistency across the PCEP messages, I think an empty ERO may just work fine in this case. If I am not mistaken, a valid empty path (computed by PCE or router) will always have one loose hop sub-object corresponding to the destination of the LSP while the empty ERO has no hop sub-objects. So, we can always distinguish the case when there is no current valid path for the LSP from the case where there is a valid empty path.

If we used the NO-PATH object in the PCRpt message, I believe we would need to also define new NI field values and potentially new Flags field values when the PCC is not able to compute a path. For example the SR-TE LSP requested bandwidth but this cannot be performed by the local CSPF since there is no SR-TE LSP state in the LSR to update the available bandwidth consumed by SR-TE LSPs on a link.

The NO-PATH object could indeed be used as is in RFC 5440 in the PCUpd message with the NI field set to 0 (“No path satisfying the set of constraints could be found”). This may be useful for the user to debug the situation from the router without logging in into the PCE. I am OK if this is added an optional object in addition to the empty ERO and can be used to send more information about the lack of a path in the PCUpd message.

Regards,
Mustapha.

From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Friday, September 02, 2016 8:26 AM
To: LITKOWSKI Stephane OBS/OINIS; Ina Minei; MEURIC Julien IMT/OLN
Cc: [email-masked]
Subject: Re: [Pce] Whither Stateless PCE?

Hello Stéphane,

Regards

Olivier

Best Regards,

Hello Ina, all,

Olivier

Cheers,

Julien

Mustapha.
Sent from my iPhone

Cheers,

Julien

Best Regards,

Stephane

Stephane,

Please see inline %%%

[snip]

Example :

Where:

Best Regards,

Stephane

Hi Stephane,

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,

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.

Thank you.

Pce mailing list

Pce mailing list

---

From: Robert Varga <[email-masked]>
Date: Fri, 9 Sep 2016 00:55:15 +0200

Hello Mustapha,

On 09/08/2016 11:59 PM, Aissaoui, Mustapha (Nokia - CA) wrote:
> The NO-PATH object could indeed be used as is in RFC 5440 in the PCUpd
> message with the NI field set to 0 (“No path satisfying the set of
> constraints could be found”). This may be useful for the user to debug
> the situation from the router without logging in into the PCE. I am OK
> if this is added an optional object in addition to the empty ERO and can
> be used to send more information about the lack of a path in the PCUpd
> message.

I think this is a good idea. I would suggest specifying this in a
separate document with its own capability negotiation, just like the
state synchronization optimizations are.

Bye,
Robert