Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Olivier Dugeon]

Hello all,

If I try to summarize, in one hand we have some implementations that use an 
empty ERO which lead in interoperability issues due to ambiguous 
interpretation, and in the other hand a clear non-ambiguous object i.e. NO-PATH 
which break implementation or at least impose strong modifications in existing 
code.

So, in order to advance on the subject, I would propose to add new code points 
to explicitly mention that the ERO is empty, and why is empty:  This solves the 
ambiguity while imposing smooth modification in today implementations as they 
just have to check a particular ERO code point (in replacement to check that 
the ERO is empty) instead processing a new object (i.e. NO-PATH).

There is two options for this new ERO code points:

a) At the ERO registry level. ERO is Class Type 20 and Class Num 1. The idea is 
to add a new Class Num = 2 i.e. Empty ERO with possibility to add different 
values to specify why it is empty e.g. 1 = NO-PATH, 2 = LOOSE-PATH ...

b) At the sub-object level. Within ERO Class Type 20 and Class Num 1, add new 
code points. eg. 38 = Empty-ERO NO-PATH, 39 = Empty-ERO Loose-Path ...

Option a) require to request a new registry and code points while option b) 
just require new code points in existing registry to IANA. Option a) allows to 
add a dedicated registry for Empty ERO with possibility to precisely describe 
why it is empty, while option b) mix the notion of Empty ERO and the reason why 
it is empty. Looking to implementation, option a) impose to look at Class Num 
when processing the ERO while option b) just need to look at sub-object.

Draft stateful could introduce this new ERO code points (whatever option a or 
b) and other drafts (initiated, synchronisation ...) could add there own needs 
regarding this empty ERO.

Comments are welcome.

Regards

Olivier

Le 05/10/2016 à 16:01, Aissaoui, Mustapha (Nokia - CA) a écrit :
>
> I am of the same opinion too. Let us keep empty ERO in both the PCUpd and 
> PCRpt messages to mean there is no valid path for the LSP. A PCC 
> implementation receiving a PCUpd with an empty ERO for a non-zero PLSP-ID can 
> decide if the outcome of this means to tear down the path or keep the 
> existing working path. If the PCC wants to use the local CSPF or an IGP 
> driven path, then it must first revoke the delegation as per existing 
> procedures.
>
>  
>
> Regards,
>
> Mustapha.
>
>  
>
> *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Julien Meuric
> *Sent:* Wednesday, October 05, 2016 8:04 AM
> *To:* pce@ietf.org
> *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE 
> advising PCC about no path
>
>  
>
> Hi all,
>
> Chair hat on, I concur with the proposed plan: we need to stick to the 
> current scope of the base stateful I-D and fix pending issues in there, new 
> proposals like "partial delegation" do require a new document.
>
> Thank you Dhruv and Stéphane for being proactive on that,
>
> Julien
>
>  
>
> Oct. 05, 2016 - :
>
> Hi Dhruv, Sudhir
>
>  
>
> I agree that what is achieved here is a partial delegation which is not 
> inline with delegation in stateful pce draft which gives full control to PCE.
>
>  
>
> The use case described is interesting but I’m afraid that empty ERO was 
> used for this purpose while there was no discussion at WG level to achieve 
> consensus for this partial delegation solution. I would prefer that Juniper 
> used a vendor specific flag for this behavior rather than using existing 
> objects.
>
> I would prefer to close the base stateful PCE draft before adding new 
> features …
>
>  
>
> Partial delegation may be complex to handle as some people may want ERO 
> to be controlled by PCC while constraints by PCE and some other may want the 
> opposite (constraints by PCC and ERO by PCE) so this requires more discussion.
>
>  
>
> Brgds,
>
>  
>
> Stephane
>
>  
>
> *From:*Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
> *Sent:* Wednesday, October 05, 2016 06:09
> *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; 
> Aissaoui, Mustapha (Nokia - CA); pce@ietf.org ; 
> draft-ietf-pce-stateful-...@tools.ietf.org 
> 
> *Cc:* 'Dhruv Dhody'
> *Subject:* RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE 
> advising PCC about no path
>
>  
>
> Hi Sudhir/Harish,
>
>  
>
> Thanks for explaining your motivation but it is not as per the definition 
> of “delegation”.
>
> What you are suggesting is a new feature lets call it “partial 
> delegation”. I hope we can discuss the merit and the procedures of this in a 
> small separate document away from this base document. IMHO this document 
> should explain why partial delegation is needed and especially why PCE would 
> still like to control how the path is computed at PCC?
>
>  
>
> How do you/WG feel about taking this approach?

Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Aissaoui, Mustapha (Nokia - CA)]

I am of the same opinion too. Let us keep empty ERO in both the PCUpd and PCRpt 
messages to mean there is no valid path for the LSP. A PCC implementation 
receiving a PCUpd with an empty ERO for a non-zero PLSP-ID can decide if the 
outcome of this means to tear down the path or keep the existing working path. 
If the PCC wants to use the local CSPF or an IGP driven path, then it must 
first revoke the delegation as per existing procedures.

Regards,
Mustapha.

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: Wednesday, October 05, 2016 8:04 AM
To: pce@ietf.org
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path


Hi all,

Chair hat on, I concur with the proposed plan: we need to stick to the current 
scope of the base stateful I-D and fix pending issues in there, new proposals 
like "partial delegation" do require a new document.

Thank you Dhruv and Stéphane for being proactive on that,

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

I agree that what is achieved here is a partial delegation which is not inline 
with delegation in stateful pce draft which gives full control to PCE.

The use case described is interesting but I'm afraid that empty ERO was used 
for this purpose while there was no discussion at WG level to achieve consensus 
for this partial delegation solution. I would prefer that Juniper used a vendor 
specific flag for this behavior rather than using existing objects.
I would prefer to close the base stateful PCE draft before adding new features 
...

Partial delegation may be complex to handle as some people may want ERO to be 
controlled by PCC while constraints by PCE and some other may want the opposite 
(constraints by PCC and ERO by PCE) so this requires more discussion.

Brgds,

Stephane

From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
Sent: Wednesday, October 05, 2016 06:09
To: Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; 
Aissaoui, Mustapha (Nokia - CA); pce@ietf.org; 
draft-ietf-pce-stateful-...@tools.ietf.org
Cc: 'Dhruv Dhody'
Subject: RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Sudhir/Harish,

Thanks for explaining your motivation but it is not as per the definition of 
"delegation".
What you are suggesting is a new feature lets call it "partial delegation". I 
hope we can discuss the merit and the procedures of this in a small separate 
document away from this base document. IMHO this document should explain why 
partial delegation is needed and especially why PCE would still like to control 
how the path is computed at PCC?

How do you/WG feel about taking this approach?

Regards,
Dhruv


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Sudhir Cheruathur
Sent: 04 October 2016 23:16
To: stephane.litkow...@orange.com; Harish 
Magganmane mailto:hmagganm...@juniper.net>>; Aissaoui, 
Mustapha (Nokia - CA) 
mailto:mustapha.aissa...@nokia.com>>; 
pce@ietf.org; 
draft-ietf-pce-stateful-...@tools.ietf.org
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Stephane/Dhruv/Mustapha,

>>I'm trying to understand what you really want to achieve here. Or do you want 
>>to have PCE updating LSP parameters/constraints but let the PCC compute path ?

We want to allow changing of other attributes of an LSP (such as BW/metric), 
but leave the path computation to the PCC. With this a PCC now has a choice to 
do a local CSPF or use IGP hop-by-hop. This choice can be enforced on the PCC 
with an empty ERO and local policy. When we want to drive this same behavior 
from the PCE then we could you use a NO-PATH object.

We could define flags in the NO-PATH object to tell the PCC what to do when a 
path is not available. The Nature of Issue is set to 0 (No path) and flags can 
be defined to specify the following

a)  Bring down the LSP

b)  Use local CSPF

c)   Use IGP based hop-by-hop.

Thanks
Redgs
Sudhir C



From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
"stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Date: Monday, October 3, 2016 at 1:27 AM
To: Harish Magganmane 
mailto:hmagganm...@juniper.net>>, "Aissaoui, Mustapha 
(Nokia - CA)" 
mailto:mustapha.aissa...@nokia.com>>, 
"pce@ietf.org" mailto:pce@ietf.org>>, 
"draft-ietf-pce-stateful-...@tools.ietf.org"
 
mailto:draft-ietf-pce-stateful-...@tools.ietf.org>>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Harish,

Thanks for your feedback.
I do not really understand why you map the empty ERO to a decision to possibly 
fallback computation to local.
As you mentioned, it coul

Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Julien Meuric]

  
  
Hi all,
  
  Chair hat on, I concur with the proposed plan: we need to stick to
  the current scope of the base stateful I-D and fix pending issues
  in there, new proposals like "partial delegation" do require a new
  document.
  
  Thank you Dhruv and Stéphane for being proactive on that,
  
  Julien


Oct. 05, 2016 - :


  
  
  
  
  
Hi Dhruv,
Sudhir
 
I agree that
what is achieved here is a partial delegation which is not
inline with delegation in stateful pce draft which gives
full control to PCE.
 
The use case
described is interesting but I’m afraid that empty ERO was
used for this purpose while there was no discussion at WG
level to achieve consensus for this partial delegation
solution. I would prefer that Juniper used a vendor specific
flag for this behavior rather than using existing objects.
I would prefer
to close the base stateful PCE draft before adding new
features …
 
Partial
delegation may be complex to handle as some people may want
ERO to be controlled by PCC while constraints by PCE and
some other may want the opposite (constraints by PCC and ERO
by PCE) so this requires more discussion.
 
Brgds,
 
Stephane
 

  
From:
Dhruv Dhody [mailto:dhruv.dh...@huawei.com]

Sent: Wednesday, October 05, 2016 06:09
To: Sudhir Cheruathur; LITKOWSKI Stephane
OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia
- CA); pce@ietf.org;
draft-ietf-pce-stateful-...@tools.ietf.org
Cc: 'Dhruv Dhody'
Subject: RE: [Pce] Urgent issue with
draft-ietf-pce-stateful-pce : PCE advising PCC about no
path
  

 
Hi
Sudhir/Harish,

 
Thanks
for explaining your motivation but it is not as per the
definition of “delegation”.

What
you are suggesting is a new feature lets call it “partial
delegation”. I hope we can discuss the merit and the
procedures of this in a small separate document away from
this base document. IMHO this document should explain why
partial delegation is needed and especially why PCE would
still like to control how the path is computed at PCC?

 
How
do you/WG feel about taking this approach?

 
Regards,
Dhruv
 
 

  
From: Pce [mailto:pce-boun...@ietf.org]
On Behalf Of Sudhir Cheruathur
Sent: 04 October 2016 23:16
To: stephane.litkow...@orange.com;
Harish Magganmane ;
Aissaoui, Mustapha (Nokia - CA) ;
pce@ietf.org;

  draft-ietf-pce-stateful-...@tools.ietf.org
Subject: Re: [Pce] Urgent issue with
draft-ietf-pce-stateful-pce : PCE advising PCC about no
path
  

 
Stephane/Dhruv/Mustapha,
 
>>I’m
trying to understand what you really want to achieve here.
Or do you want to have PCE updating LSP
parameters/constraints but let the PCC compute path ?
 
We want to
allow changing of other attributes of an LSP (such as
BW/metric), but leave the path computation to the PCC. With
this a PCC now has a choice to do a local CSPF or use IGP
hop-by-hop. This choice can be enforced on the PCC with an
empty ERO and local policy. When we want to drive this same
behavior from the PCE then we could you use a NO-PATH
object.
 
We could
define flags in the NO-PATH object to tell the PCC what to
do when a path is not available. The Nature of Issue is set
to 0 (No path) and flags can be defined to specify the
following 
a) 
  Bring
down the LSP
b) 
  Use
local CSPF
c)  
  Use
IGP based hop-by-hop.
 
Thanks
Redgs
Sudhir C
 
 
 

  From:
  Pce  on behalf of "stephane.litkow...@orange.com" 
Date: Monday, October 3, 2016 at 1:27 AM
  

Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[Robert Varga]

On 10/03/2016 04:30 PM, Dhruv Dhody wrote:
> (1) Allow Empty ERO to mean no path.
> 
> Let it be valid in all messages to mean that no intended path exists for
> this LSP.
> 
> As per -16,
> 
> - empty ERO is added in the end of synchronization marker (PCRpt). 
> 
> - The ERO may be empty if the PCE does not have a path for a delegated LSP.
> 
>  
> 
> We can add text in section 6.2 to say something like –
> 
>  
> 
> The ERO may be empty if the PCE does not have an intended path for the
> delegated LSP. 
> 
> If the local policy allows it, the PCC SHOULD signal the tear down of
> the LSP. At 
> 
> this time, PCC MAY also revoke delegation and use a locally computed
> path instead. 
> 
>  
> 
> To me this is more logical and in spirit with the rest of the document,
> also would require least amount of changes in existing implementations.

+1

Thanks,
Robert



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

Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

[stephane.litkowski]

Hi Dhruv, Sudhir

I agree that what is achieved here is a partial delegation which is not inline 
with delegation in stateful pce draft which gives full control to PCE.

The use case described is interesting but I’m afraid that empty ERO was used 
for this purpose while there was no discussion at WG level to achieve consensus 
for this partial delegation solution. I would prefer that Juniper used a vendor 
specific flag for this behavior rather than using existing objects.
I would prefer to close the base stateful PCE draft before adding new features …

Partial delegation may be complex to handle as some people may want ERO to be 
controlled by PCC while constraints by PCE and some other may want the opposite 
(constraints by PCC and ERO by PCE) so this requires more discussion.

Brgds,

Stephane

From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
Sent: Wednesday, October 05, 2016 06:09
To: Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; 
Aissaoui, Mustapha (Nokia - CA); pce@ietf.org; 
draft-ietf-pce-stateful-...@tools.ietf.org
Cc: 'Dhruv Dhody'
Subject: RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Sudhir/Harish,

Thanks for explaining your motivation but it is not as per the definition of 
“delegation”.
What you are suggesting is a new feature lets call it “partial delegation”. I 
hope we can discuss the merit and the procedures of this in a small separate 
document away from this base document. IMHO this document should explain why 
partial delegation is needed and especially why PCE would still like to control 
how the path is computed at PCC?

How do you/WG feel about taking this approach?

Regards,
Dhruv


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Sudhir Cheruathur
Sent: 04 October 2016 23:16
To: stephane.litkow...@orange.com; Harish 
Magganmane mailto:hmagganm...@juniper.net>>; Aissaoui, 
Mustapha (Nokia - CA) 
mailto:mustapha.aissa...@nokia.com>>; 
pce@ietf.org; 
draft-ietf-pce-stateful-...@tools.ietf.org
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Stephane/Dhruv/Mustapha,

>>I’m trying to understand what you really want to achieve here. Or do you want 
>>to have PCE updating LSP parameters/constraints but let the PCC compute path ?

We want to allow changing of other attributes of an LSP (such as BW/metric), 
but leave the path computation to the PCC. With this a PCC now has a choice to 
do a local CSPF or use IGP hop-by-hop. This choice can be enforced on the PCC 
with an empty ERO and local policy. When we want to drive this same behavior 
from the PCE then we could you use a NO-PATH object.

We could define flags in the NO-PATH object to tell the PCC what to do when a 
path is not available. The Nature of Issue is set to 0 (No path) and flags can 
be defined to specify the following

a)  Bring down the LSP

b)  Use local CSPF

c)   Use IGP based hop-by-hop.

Thanks
Redgs
Sudhir C



From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
"stephane.litkow...@orange.com" 
mailto:stephane.litkow...@orange.com>>
Date: Monday, October 3, 2016 at 1:27 AM
To: Harish Magganmane 
mailto:hmagganm...@juniper.net>>, "Aissaoui, Mustapha 
(Nokia - CA)" 
mailto:mustapha.aissa...@nokia.com>>, 
"pce@ietf.org" mailto:pce@ietf.org>>, 
"draft-ietf-pce-stateful-...@tools.ietf.org"
 
mailto:draft-ietf-pce-stateful-...@tools.ietf.org>>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising 
PCC about no path

Hi Harish,

Thanks for your feedback.
I do not really understand why you map the empty ERO to a decision to possibly 
fallback computation to local.
As you mentioned, it could be a local PCC policy decision and this local policy 
could be to tear down the LSP instead of deferring ERO selection to the local 
router as you proposed.

The important point is the semantic of this empty ERO, not really the action 
taken. I understand in your email  that you still interpret it from a semantic 
point of view has an indication of no path, so you then can decide to defer ERO 
selection to the router. Because in the case, you want to have the PCE giving 
back path computation role to PCC, the PCE must use the delegate flag for this 
purpose and can revoke the delegation at anytime. I’m trying to understand what 
you really want to achieve here. Or do you want to have PCE updating LSP 
parameters/constraints but let the PCC compute path ?

Best Regards,

Stephane



From: Harish Magganmane [mailto:hmagganm...@juniper.net]
Sent: Saturday, October 01, 2016 00:53
To: LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); 
pce@ietf.org; 
draft-ietf-pce-stateful-...@tools.ietf.org