Re: [Pce] Whither Stateless PCE?

[Robert Varga]

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



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

> 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:pce-boun...@ietf.org] On Behalf Of Olivier Dugeon
Sent: Thursday, September 08, 2016 15:10
To: Robert Varga; Ina Minei
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

Hello Robert,
Le 08/09/2016 11:38, Robert Varga a écrit :

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




Bye,

Robert




_

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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Robert Varga]

On 09/08/2016 03:10 PM, Olivier Dugeon wrote:
> Hello Robert,
> 
> Le 08/09/2016 11:38, Robert Varga a écrit :
>> 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.
> 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:

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



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Olivier Dugeon]

Hello Robert,

Le 08/09/2016 11:38, Robert Varga a écrit :
> 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.
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
> Bye,
> Robert
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Robert Varga]

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



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

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:inami...@google.com]
Sent: Friday, September 02, 2016 01:23
To: MEURIC Julien IMT/OLN
Cc: Aissaoui, Mustapha (Nokia - CA); LITKOWSKI Stephane OBS/OINIS; pce@ietf.org
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.

I will post shortly, comments welcome.

On Fri, Aug 19, 2016 at 8:56 AM, Julien Meuric 
mailto:julien.meu...@orange.com>> 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 - mustapha.aissa...@nokia.com<mailto:mustapha.aissa...@nokia.com>:
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 
mailto:julien.meu...@orange.com>> 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 - 
mailto:stephane.litkow...@orange.com>:
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:inami...@google.com]
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 se

Re: [Pce] Whither Stateless PCE?

[Aissaoui, Mustapha (Nokia - CA)]

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 
mailto:julien.meu...@orange.com>> 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 - 
mailto:stephane.litkow...@orange.com>:
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:inami...@google.com]
Sent: Thursday, August 11, 2016 19:25
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; Dhruv Dhody; 
pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Whither Stateless PCE?

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 th

Re: [Pce] Whither Stateless PCE?

[Julien Meuric]

  
  
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 -
  <stephane.litkow...@orange.com:


  
  
  
  
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:inami...@google.com]

Sent: Thursday, August 11, 2016 19:25
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui,
Mustapha (Nokia - CA); adr...@olddog.co.uk; Dhruv Dhody;
pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?
 

  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, represen

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

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:inami...@google.com]
Sent: Thursday, August 11, 2016 19:25
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk; Dhruv Dhody; pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

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 => M

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

Hi Ina,

Thanks for the feedback
Please find some inline comments.

Brgds,

Stephane

From: Ina Minei [mailto:inami...@google.com]
Sent: Tuesday, August 09, 2016 00:20
To: LITKOWSKI Stephane OBS/OINIS
Cc: Fatai Zhang; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk; Dhruv Dhody; pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?


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.

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


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

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

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:

::= 
   
Where:

::= []

::= []
  
  
 Where:
   ::= 
 []
 

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

 []



   ::=[]
 []

Where:
is represented by the ERO object defined in
   section 7.9 of [RFC5440].
consists of the actual computed and signaled values
   of the  and  objects defined in [RFC5440].
is represented by the RRO object defined in
   section 7.10 of [RFC5440].
is the attribute-list defined in
   section 6.5 of [RFC5440] and extended by PCEP extensions.

The intended_attribute_list maps to the attrib

Re: [Pce] Whither Stateless PCE?

[Robert Varga]

On 04/08/2016 07:04 PM, stephane.litkow...@orange.com wrote:
> Hi,

Hello,

> 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 …).

RFC5440's spirit is that the PCC is the ultimate owner of LSP state. I
do believe both behaviors are valid and should be a matter of local PCC
policy rather than protocol specification.

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

Does this statement refer to multiple PCE implementations or multiple
PCC implementations?

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

Yes, exactly.
Depending on the exact level of detail we want from the PCC, we may need 
possibly three different states :
- intended (configuration => may be partially/totally received from PCE)
- effective (configuration => what has been really taken into account by PCC in 
term of config) => this one may be necessary in case some configuration option 
may be sent by the PCE but not taken into account by PCC.
- operational (ops state => what is the current state of the computed path)

-Original Message-
From: Robert Varga [mailto:n...@hq.sk] 
Sent: Monday, May 09, 2016 15:18
To: LITKOWSKI Stephane OBS/OINIS; Zhangxian (Xian); Aissaoui, Mustapha (Nokia - 
CA); DUGEON Olivier IMT/OLN
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

On 05/09/2016 03:06 PM, stephane.litkow...@orange.com wrote:
> Hi Xian,
> 
>  
> 
> Regarding the METRIC object, the issue is not having the Object in the 
> PCRpt (which already works). The issue is that the metric object will 
> reflect the operational state of the LSP rather than it's configuration.
> 
> The best example may be :
> 
> PCC is configured to use IGP metric with a cost bound to 20.
> 
> In the PCRpt, it will send in the METRIC object the operational values 
> of the LSP, so the metric may be anything below 20 (e.g. 14) and B=0 
> and we will not have any information about the cost boundary 
> constraint, so the PCE will not be able to fullfill this constraint 
> when computing the path for the PCC.

Hello,

This looks like the 'ERO/RRO in PCRpt' discussion we have had with Julien. 
While the ERO/RRO split makes this a non-issue in that case, we seem to lack a 
general mechanism to discern 'intended' and 'effective'
state, notably in the case when the PCE needs to recover the intended state 
from the PCC.

Does that sum up the problem?

Thanks,
Robert


_

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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Robert Varga]

On 05/09/2016 03:06 PM, stephane.litkow...@orange.com wrote:
> Hi Xian,
> 
>  
> 
> Regarding the METRIC object, the issue is not having the Object in the
> PCRpt (which already works). The issue is that the metric object will
> reflect the operational state of the LSP rather than it’s configuration.
> 
> The best example may be :
> 
> PCC is configured to use IGP metric with a cost bound to 20.
> 
> In the PCRpt, it will send in the METRIC object the operational values
> of the LSP, so the metric may be anything below 20 (e.g. 14) and B=0 and
> we will not have any information about the cost boundary constraint, so
> the PCE will not be able to fullfill this constraint when computing the
> path for the PCC.

Hello,

This looks like the 'ERO/RRO in PCRpt' discussion we have had with
Julien. While the ERO/RRO split makes this a non-issue in that case, we
seem to lack a general mechanism to discern 'intended' and 'effective'
state, notably in the case when the PCE needs to recover the intended
state from the PCC.

Does that sum up the problem?

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

Hi Xian,

Regarding the METRIC object, the issue is not having the Object in the PCRpt 
(which already works). The issue is that the metric object will reflect the 
operational state of the LSP rather than it’s configuration.
The best example may be :
PCC is configured to use IGP metric with a cost bound to 20.
In the PCRpt, it will send in the METRIC object the operational values of the 
LSP, so the metric may be anything below 20 (e.g. 14) and B=0 and we will not 
have any information about the cost boundary constraint, so the PCE will not be 
able to fullfill this constraint when computing the path for the PCC.

Hope it helps,

Stephane


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Zhangxian (Xian)
Sent: Thursday, May 05, 2016 08:33
To: Aissaoui, Mustapha (Nokia - CA); DUGEON Olivier IMT/OLN
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

Hi,

   I would like to first thank Olivier and Mustapha for bringing such good 
comments/discussions, based on inter-op test.  With your help, hope we can 
clear the ambiguity very soon.

With regard to the 2nd point raised below by Mustapha:
＂
In addition, I think it is worth considering sending the constraints in a PCRpt 
message in duplicate Metric/LSPA objects with the P-flag set. This is in 
addition to the same objects containing the operational values. This can be 
useful in the case where the initial path was computed by the router and it is 
active and the user is delegating it. The PCE at that point in time will not 
compute a path immediately but will save the original constraints in the PCRpt 
message for the next time it needs to update the path.＂

The capability of carrying Metric/LSPA in PCRpt message is already allowed (see 
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-14#section-6.1).  If 
you think there is lack of text explanation of the motivation behind, we should 
add some to make it clearer.

Regards,
Xian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Nokia 
- CA)
Sent: 2016年4月19日 4:00
To: EXT Olivier Dugeon; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Dhruv 
Dhody'
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Whither Stateless PCE?

Hi Olivier,
It is one option for sure. In general, implementations of stateful PCE should 
be able of caching the constraints received in the PCReq message for some 
period of time to give a chance for a potential follow-up PCRpt message. Even 
if you set the D-flag in the PCReq message, there is no guarantee that a PCRpt 
will follow and as such a PCE implementation will have to flush that 
information from its cache at some point in time.

In addition, I think it is worth considering sending the constraints in a PCRpt 
message in duplicate Metric/LSPA objects with the P-flag set. This is in 
addition to the same objects containing the operational values. This can be 
useful in the case where the initial path was computed by the router and it is 
active and the user is delegating it. The PCE at that point in time will not 
compute a path immediately but will save the original constraints in the PCRpt 
message for the next time it needs to update the path.

Regards,
Mustapha.

From: EXT Olivier Dugeon [mailto:olivier.dug...@orange.com]
Sent: Monday, April 18, 2016 8:58 AM
To: Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Dhruv Dhody'
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Whither Stateless PCE?

Dear Mustapha,

You catch a good point regarding the original constraints that are not carry by 
the PCRpt message. Thus, if we used a standard PCReq message without the 
D-delegate flag set, there is a risk that the PCE considers this request as a 
stateless one and don't keep track of the original request, and consequently, 
original constraints.

So, is it preferable to set de D-delegate flag in the PCReq message to tell the 
PCE to keep in memory the original constraints for further usage, or, is the 
'STATEFUL-PCE-CAPABILITY' TLV in Open message is sufficient for the PCE to know 
that it must keep track of any requests? I prefer the first option as it allows 
a per request configuration while the second enables the memorization globally 
for all requests.

Regards,

Olivier
Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit :
Hi Olivier,
Good summary indeed. I was worried about interop testing when I sent the 
original email to the list in December 2014.

I just wanted to comment on a couple of things:


1.  You are correct that the LSP object which has the D-delegate flag is 
allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I however 
think it is more appropriate to do the delegation in the subsequent PCRpt 
message once the LSP path is programmed by PCC following the PCRep message from 
PCE. This is because it is at that time that the LSP is being synchronized with 
the PCE LSP database.



2.

Re: [Pce] Whither Stateless PCE?

[Zhangxian (Xian)]

Hi,

   I would like to first thank Olivier and Mustapha for bringing such good 
comments/discussions, based on inter-op test.  With your help, hope we can 
clear the ambiguity very soon.

With regard to the 2nd point raised below by Mustapha:
＂
In addition, I think it is worth considering sending the constraints in a PCRpt 
message in duplicate Metric/LSPA objects with the P-flag set. This is in 
addition to the same objects containing the operational values. This can be 
useful in the case where the initial path was computed by the router and it is 
active and the user is delegating it. The PCE at that point in time will not 
compute a path immediately but will save the original constraints in the PCRpt 
message for the next time it needs to update the path.＂

The capability of carrying Metric/LSPA in PCRpt message is already allowed (see 
https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-14#section-6.1).  If 
you think there is lack of text explanation of the motivation behind, we should 
add some to make it clearer.

Regards,
Xian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha (Nokia 
- CA)
Sent: 2016年4月19日 4:00
To: EXT Olivier Dugeon; adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

Hi Olivier,
It is one option for sure. In general, implementations of stateful PCE should 
be able of caching the constraints received in the PCReq message for some 
period of time to give a chance for a potential follow-up PCRpt message. Even 
if you set the D-flag in the PCReq message, there is no guarantee that a PCRpt 
will follow and as such a PCE implementation will have to flush that 
information from its cache at some point in time.

In addition, I think it is worth considering sending the constraints in a PCRpt 
message in duplicate Metric/LSPA objects with the P-flag set. This is in 
addition to the same objects containing the operational values. This can be 
useful in the case where the initial path was computed by the router and it is 
active and the user is delegating it. The PCE at that point in time will not 
compute a path immediately but will save the original constraints in the PCRpt 
message for the next time it needs to update the path.

Regards,
Mustapha.

From: EXT Olivier Dugeon [mailto:olivier.dug...@orange.com]
Sent: Monday, April 18, 2016 8:58 AM
To: Aissaoui, Mustapha (Nokia - CA); adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

Dear Mustapha,

You catch a good point regarding the original constraints that are not carry by 
the PCRpt message. Thus, if we used a standard PCReq message without the 
D-delegate flag set, there is a risk that the PCE considers this request as a 
stateless one and don't keep track of the original request, and consequently, 
original constraints.

So, is it preferable to set de D-delegate flag in the PCReq message to tell the 
PCE to keep in memory the original constraints for further usage, or, is the 
'STATEFUL-PCE-CAPABILITY' TLV in Open message is sufficient for the PCE to know 
that it must keep track of any requests? I prefer the first option as it allows 
a per request configuration while the second enables the memorization globally 
for all requests.

Regards,

Olivier
Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit :
Hi Olivier,
Good summary indeed. I was worried about interop testing when I sent the 
original email to the list in December 2014.

I just wanted to comment on a couple of things:


1. You are correct that the LSP object which has the D-delegate flag is 
allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I however 
think it is more appropriate to do the delegation in the subsequent PCRpt 
message once the LSP path is programmed by PCC following the PCRep message from 
PCE. This is because it is at that time that the LSP is being synchronized with 
the PCE LSP database.



2. The PCRpt message does not carry the original constraints of the LSP 
(Bandwidth, Metric, and LSPA objects). It can carry the operational values of 
the Bandwidth and Metric objects used by the last computed path in the router. 
So, even if you have a PCE which reacted to the PCRpt message and computed a 
new path, it will not get the appropriate constraints included. That is why the 
PCReq/PCRep sequence before delegating the LSP is needed.

Regards,
Mustapha.

From: EXT olivier.dug...@orange.com<mailto:olivier.dug...@orange.com> 
[mailto:olivier.dug...@orange.com]
Sent: Friday, April 08, 2016 12:29 PM
To: Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Dhruv Dhody'
Cc: pce@ietf.org<mailto:pce@ietf.org>
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

Re: [Pce] Whither Stateless PCE?

[Julien Meuric]

Hi Adrian,

Based on the evolution of this thread, it looks like it leaves us with 
the following guidelines:

- The case by case basis looks reasonable and should prevail;
- Extensions should focus on what is (eventually) useful;
- The scope of each work should be explicitly mentioned in I-Ds.

I hope this is an acceptable answer to your question.

Regards,

Julien


Apr. 07, 2016 - adr...@olddog.co.uk:
> 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:*dhruvdh...@gmail.com 
[mailto:dhruvdh...@gmail.com] *On Behalf > Of *Dhruv Dhody *Sent:* 06 
April 2016 23:07 > > > > 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  > 
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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Aissaoui, Mustapha (Nokia - CA)]

Hi Olivier,
It is one option for sure. In general, implementations of stateful PCE should 
be able of caching the constraints received in the PCReq message for some 
period of time to give a chance for a potential follow-up PCRpt message. Even 
if you set the D-flag in the PCReq message, there is no guarantee that a PCRpt 
will follow and as such a PCE implementation will have to flush that 
information from its cache at some point in time.

In addition, I think it is worth considering sending the constraints in a PCRpt 
message in duplicate Metric/LSPA objects with the P-flag set. This is in 
addition to the same objects containing the operational values. This can be 
useful in the case where the initial path was computed by the router and it is 
active and the user is delegating it. The PCE at that point in time will not 
compute a path immediately but will save the original constraints in the PCRpt 
message for the next time it needs to update the path.

Regards,
Mustapha.

From: EXT Olivier Dugeon [mailto:olivier.dug...@orange.com]
Sent: Monday, April 18, 2016 8:58 AM
To: Aissaoui, Mustapha (Nokia - CA); adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
Subject: Re: [Pce] Whither Stateless PCE?

Dear Mustapha,

You catch a good point regarding the original constraints that are not carry by 
the PCRpt message. Thus, if we used a standard PCReq message without the 
D-delegate flag set, there is a risk that the PCE considers this request as a 
stateless one and don't keep track of the original request, and consequently, 
original constraints.

So, is it preferable to set de D-delegate flag in the PCReq message to tell the 
PCE to keep in memory the original constraints for further usage, or, is the 
'STATEFUL-PCE-CAPABILITY' TLV in Open message is sufficient for the PCE to know 
that it must keep track of any requests? I prefer the first option as it allows 
a per request configuration while the second enables the memorization globally 
for all requests.

Regards,

Olivier
Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit :
Hi Olivier,
Good summary indeed. I was worried about interop testing when I sent the 
original email to the list in December 2014.

I just wanted to comment on a couple of things:


1.  You are correct that the LSP object which has the D-delegate flag is 
allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I however 
think it is more appropriate to do the delegation in the subsequent PCRpt 
message once the LSP path is programmed by PCC following the PCRep message from 
PCE. This is because it is at that time that the LSP is being synchronized with 
the PCE LSP database.



2.  The PCRpt message does not carry the original constraints of the LSP 
(Bandwidth, Metric, and LSPA objects). It can carry the operational values of 
the Bandwidth and Metric objects used by the last computed path in the router. 
So, even if you have a PCE which reacted to the PCRpt message and computed a 
new path, it will not get the appropriate constraints included. That is why the 
PCReq/PCRep sequence before delegating the LSP is needed.

Regards,
Mustapha.

From: EXT olivier.dug...@orange.com<mailto:olivier.dug...@orange.com> 
[mailto:olivier.dug...@orange.com]
Sent: Friday, April 08, 2016 12:29 PM
To: Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Dhruv Dhody'
Cc: pce@ietf.org<mailto:pce@ietf.org>
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

Re: [Pce] Whither Stateless PCE?

[Olivier Dugeon]

Dear Mustapha,

You catch a good point regarding the original constraints that are not 
carry by the PCRpt message. Thus, if we used a standard PCReq message 
without the D-delegate flag set, there is a risk that the PCE considers 
this request as a stateless one and don't keep track of the original 
request, and consequently, original constraints.


So, is it preferable to set de D-delegate flag in the PCReq message to 
tell the PCE to keep in memory the original constraints for further 
usage, or, is the 'STATEFUL-PCE-CAPABILITY' TLV in Open message is 
sufficient for the PCE to know that it must keep track of any requests? 
I prefer the first option as it allows a per request configuration while 
the second enables the memorization globally for all requests.


Regards,

Olivier

Le 08/04/2016 19:26, Aissaoui, Mustapha (Nokia - CA) a écrit :


Hi Olivier,

Good summary indeed. I was worried about interop testing when I sent 
the original email to the list in December 2014.


I just wanted to comment on a couple of things:

1.You are correct that the LSP object which has the D-delegate flag is 
allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I 
however think it is more appropriate to do the delegation in the 
subsequent PCRpt message once the LSP path is programmed by PCC 
following the PCRep message from PCE. This is because it is at that 
time that the LSP is being synchronized with the PCE LSP database.


2.The PCRpt message does not carry the original constraints of the LSP 
(Bandwidth, Metric, and LSPA objects). It can carry the operational 
values of the Bandwidth and Metric objects used by the last computed 
path in the router. So, even if you have a PCE which reacted to the 
PCRpt message and computed a new path, it will not get the appropriate 
constraints included. That is why the PCReq/PCRep sequence before 
delegating the LSP is needed.


Regards,

Mustapha.

*From:*EXT olivier.dug...@orange.com [mailto:olivier.dug...@orange.com]
*Sent:* Friday, April 08, 2016 12:29 PM
*To:* Aissaoui, Mustapha (Nokia - CA); adr...@olddog.co.uk; 'Dhruv Dhody'
*Cc:* pce@ietf.org
*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 

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

Hi,

It’s multivendor in a single domain between two stateful active implementations.
In a delegation scenario, we have some issue with triggers of Path computation 
and update sent on PCE side.
The draft is not really clear on when this path computation and update must be 
triggered, especially when PCC does not use PCReq but only PCRpt.

From an operational perspective, we expect PCE to takeover the LSP computation 
when LSP is delegated and it’s not always the case.

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

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


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


Best Regards,

Stephane


From: Fatai Zhang [mailto:zhangfa...@huawei.com]
Sent: Thursday, April 14, 2016 09:39
To: LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha 
(Nokia - CA); adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
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:pce-boun...@ietf.org] 代表 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
发送时间: 2016年4月9日 1:04
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Dhruv Dhody'
抄送: pce@ietf.org<mailto:pce@ietf.org>
主题: 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:pce-boun...@ietf.org] On Behalf Of 
olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); 
adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Dhruv Dhody'
Cc: pce@ietf.org<mailto:pce@ietf.org>
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/PC

Re: [Pce] Whither Stateless PCE?

[Aissaoui, Mustapha (Nokia - CA)]

Hi Olivier,
Good summary indeed. I was worried about interop testing when I sent the 
original email to the list in December 2014.

I just wanted to comment on a couple of things:


1. You are correct that the LSP object which has the D-delegate flag is 
allowed in the PCReq message as per draft-ietf-pce-stateful-pce. I however 
think it is more appropriate to do the delegation in the subsequent PCRpt 
message once the LSP path is programmed by PCC following the PCRep message from 
PCE. This is because it is at that time that the LSP is being synchronized with 
the PCE LSP database.



2. The PCRpt message does not carry the original constraints of the LSP 
(Bandwidth, Metric, and LSPA objects). It can carry the operational values of 
the Bandwidth and Metric objects used by the last computed path in the router. 
So, even if you have a PCE which reacted to the PCRpt message and computed a 
new path, it will not get the appropriate constraints included. That is why the 
PCReq/PCRep sequence before delegating the LSP is needed.

Regards,
Mustapha.

From: EXT olivier.dug...@orange.com [mailto:olivier.dug...@orange.com]
Sent: Friday, April 08, 2016 12:29 PM
To: Aissaoui, Mustapha (Nokia - CA); adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
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 e

Re: [Pce] Whither Stateless PCE?

[stephane.litkowski]

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:pce-boun...@ietf.org] On Behalf Of olivier.dug...@orange.com
Sent: Friday, April 08, 2016 18:29
To: Aissaoui, Mustapha (Nokia - CA); adr...@olddog.co.uk; 'Dhruv Dhody'
Cc: pce@ietf.org
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:pce-boun...@i

Re: [Pce] Whither Stateless PCE?

[olivier.dugeon]

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:pce-boun...@ietf.org] *On Behalf Of *EXT Adrian Farrel
*Sent:* Thursday, April 07, 2016 12:48 AM
*To:* 'Dhruv Dhody'
*Cc:* pce@ietf.org
*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 ot

Re: [Pce] Whither Stateless PCE?

[Aissaoui, Mustapha (Nokia - CA)]

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:pce-boun...@ietf.org] On Behalf Of EXT Adrian Farrel
Sent: Thursday, April 07, 2016 12:48 AM
To: 'Dhruv Dhody'
Cc: pce@ietf.org
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: dhruvdh...@gmail.com<mailto:dhruvdh...@gmail.com> 
[mailto:dhruvdh...@gmail.com] On Behalf Of Dhruv Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: pce@ietf.org<mailto:pce@ietf.org>
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 
mailto:adr...@olddog.co.uk>> 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
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Adrian Farrel]

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: dhruvdh...@gmail.com [mailto:dhruvdh...@gmail.com] On Behalf Of Dhruv 
Dhody
Sent: 06 April 2016 23:07
To: Farrel Adrian
Cc: pce@ietf.org
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  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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
 
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Whither Stateless PCE?

[Dhruv Dhody]

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  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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Whither Stateless PCE?

[Adrian Farrel]

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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce