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

From: <[email-masked]>
Date: Mon, 3 Oct 2016 08:27:38 +0000

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:[email-masked]]
Sent: Saturday, October 01, 2016 00:53
To: LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); [email-masked]; [email-masked]
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Stephane,

We are not in favor of using empty ERO as way to signal the tearing of an LSP. IMO empty ERO object should be interpreted to mean deferring the ERO selection to the router, perhaps through local policy on the PCC. For example PCC could choose between a local CSPF or a IGP based hop-by-hop.

In cases where we want PCE to explicitly control the behavior of the PCC when a path is not available, NO-PATH object can be used to dictate the behavior. One such behavior could be that of tearing down the LSP.

Thanks,
Harish

From: Pce <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 30, 2016 at 8:33 AM
To: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Mustapha,

Your proposal works from my point of view, but it looks that it causes some trouble to another vendor so I would like these people (and others as well) to express their concerns regarding usage of empty ERO.

Thanks for pointing again your last proposal.

Best Regards,

Stephane

From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]
Sent: Friday, September 30, 2016 17:08
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Stephane,
In the last email related to this issue, I made a proposal to Olivier and Robert commented on it. Would that be sufficient to address this interop issue?
https://mailarchive.ietf.org/arch/msg/pce/A1ADiw6Uvjn1ETjErqzgjdjXnsE

Mustapha.

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, September 30, 2016 5:46 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi WG, and draft authors,

We still have an urgent interoperability issue to solve with draft-ietf-pce-stateful-pce. We currently have no clear semantic for the PCE to advise the PCC that there is no more path available. This point was already raised through the list but as we need an URGENT resolution of this issue because of implementation timelines, I would like to reactivate the thread.

The situation of no path at PCE side can happen in many situations, and a particular situation will require PCC to tear down an existing path : let's think about two strictly SRLG disjoint LSPs with a working path . Now the transmission topology is changing (rerouting at WDM layer) leading SRLG disjointness not being fitted anymore and PCE cannot find anymore disjoint path, it must advise one PCC to tear down the path because it is no more disjoint (strict disjointness required).
We do not have any clear semantic today and some implementations are using empty ERO for this purpose in PCUpdate but the PCC does not recognize it as a valid no path significance.

This subject is critical and I would like that we can achieve a consensus asap on the target solution so then vendors can align implementations.
This thread is focusing on the PCE -> PCC way, but having a semantic of reporting a no path is also necessary in PCC->PCE way through PCRpt, at least to ACK a PCupdate.

One of the previous discussion on the list talked about the possibility to use NO-PATH object which already has this semantic for PCReq/PCRep but as already mentioned we need to assess impact on existing implementations, so vendor feedback (with customer implementations) is highly required. So this is my starting proposal to initiate the discussion.

Best Regards,

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 3 Oct 2016 14:30:22 +0000

Hi Stephane,

The case you described is valid and important to support. I am one of those who believed empty ERO to be just fine, but I understand the other point of view as well.
IMHO we need to resolve it quickly and completely.  I see two ways -

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

(2) Add NO-PATH object
If we do this way, then we need to make following changes in all messages!

-        Remove ERO as mandatory object and its error codes in all messages

-        Change RBNF to add NO-PATH object

-        Update NI fields (if needed)

All existing implementation would need change, and this change would be a non-backward-compatible change. This is what I am afraid of the most especially with open source. But if this is the only way to reach consensus and move the document forward, I *personally* could live with it.

Hi Harish

I agree with Stephane we have returning/revoking of delegation as the right mechanism for PCC to select the locally computed path instead.
Do you have suggestion to improve the text above if we go with option 1?

Regards,
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 October 2016 13:58
To: Harish Magganmane <[email-masked]>; Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Harish,

Best Regards,

Stephane

From: Harish Magganmane [mailto:[email-masked]]
Sent: Saturday, October 01, 2016 00:53
To: LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Mon, 3 Oct 2016 22:47:53 +0000

Hi Harish,
The intended use of the empty ERO is to indicate there is no valid path for the LSP. In fact, if you read the updated Section 6.1 in the latest version of the draft Ina posted, we are proposing to use this not just in the PCUpd message but also in the PCRpt message if PCC did not have a valid path for an LSP it has control of.

Perhaps where I do agree with you is that PCC could make use of a policy to decide if the LSP should be torn down or it would be kept on the current working path even if PCE by sending the empty ERO is telling there exists no path which satisfied the constraints of that LSP.

Regards,
Mustapha.

From: Dhruv Dhody [mailto:[email-masked]]
Sent: Monday, October 03, 2016 10:30 AM
To: [email-masked]; Harish Magganmane; Aissaoui, Mustapha (Nokia - CA); [email-masked]; [email-masked]
Subject: RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Stephane,

(2) Add NO-PATH object

Hi Harish

Regards,
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 03 October 2016 13:58
To: Harish Magganmane <[email-masked]<mailto:[email-masked]>>; Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: Sudhir Cheruathur <[email-masked]>
Date: Tue, 4 Oct 2016 17:46:17 +0000

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 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Monday, October 3, 2016 at 1:27 AM
To: Harish Magganmane <[email-masked]>, "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Harish,

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

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

The situation of no path at PCE side can happen in many situations, and a particular situation will require PCC to tear down an existing path : let’s think about two strictly SRLG disjoint LSPs with a working path . Now the transmission topology is changing (rerouting at WDM layer) leading SRLG disjointness not being fitted anymore and PCE cannot find anymore disjoint path, it must advise one PCC to tear down the path because it is no more disjoint (strict disjointness required).
We do not have any clear semantic today and some implementations are using empty ERO for this purpose in PCUpdate but the PCC does not recognize it as a valid no path significance.

Best Regards,

[ange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 5 Oct 2016 04:09:07 +0000

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:[email-masked]] On Behalf Of Sudhir Cheruathur
Sent: 04 October 2016 23:16
To: [email-masked]; Harish Magganmane <[email-masked]>; Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

From: Pce <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 3, 2016 at 1:27 AM
To: Harish Magganmane <[email-masked]<mailto:[email-masked]>>, "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 5 Oct 2016 08:05:53 +0000

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:[email-masked]]
Sent: Wednesday, October 05, 2016 06:09
To: Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia - CA); [email-masked]; [email-masked]
Cc: 'Dhruv Dhody'
Subject: RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Sudhir/Harish,

Regards,
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of Sudhir Cheruathur
Sent: 04 October 2016 23:16
To: [email-masked]<mailto:[email-masked]>; Harish Magganmane <[email-masked]<mailto:[email-masked]>>; Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: Robert Varga <[email-masked]>
Date: Wed, 5 Oct 2016 13:45:21 +0200

On 10/03/2016 04:30 PM, Dhruv Dhody wrote:
> We can add text in section 6.2 to say something like –
> 
>  
> 
> 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

---

From: Julien Meuric <[email-masked]>
Date: Wed, 5 Oct 2016 14:03:45 +0200

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:[email-masked]]

To: Sudhir Cheruathur; LITKOWSKI Stephane
OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia
- CA); [email-masked];
[email-masked]

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:[email-masked]]
On Behalf Of Sudhir Cheruathur

To: [email-masked];
Harish Magganmane <[email-masked]>;
Aissaoui, Mustapha (Nokia - CA) <[email-masked]>;
[email-masked];

[email-masked]

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 <[email-masked]> on behalf of "[email-masked]" <[email-masked]>

To: Harish Magganmane <[email-masked]>, "Aissaoui, Mustapha (Nokia -
CA)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

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:[email-masked]]

To: LITKOWSKI Stephane OBS/OINIS; Aissaoui,
Mustapha (Nokia - CA);
[email-masked];
[email-masked]

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

Hi
Stephane,

We are
not in favor of using empty ERO as way to signal the
tearing of an LSP. IMO empty ERO object should be
interpreted to mean deferring the ERO selection to the
router, perhaps through local policy on the PCC. For
example PCC could choose between a local CSPF or a IGP
based hop-by-hop.

In cases
where we want PCE to explicitly control the behavior of
the PCC when a path is not available, NO-PATH object can
be used to dictate the behavior. One such behavior could
be that of tearing down the LSP.

Thanks,

Harish

From:
Pce <[email-masked]> on behalf of "[email-masked]" <[email-masked]>

To: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

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

Hi
Mustapha,

Your
proposal works from my point of view, but it looks that
it causes some trouble to another vendor so I would like
these people (and others as well) to express their
concerns regarding usage of empty ERO.

Thanks
for pointing again your last proposal.

Best
Regards,

Stephane

From:
Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]

To: LITKOWSKI Stephane OBS/OINIS; [email-masked];
[email-masked]

Subject: RE: Urgent issue with
draft-ietf-pce-stateful-pce : PCE advising PCC about
no path

Hi
Stephane,

In
the last email related to this issue, I made a proposal
to Olivier and Robert commented on it. Would that be
sufficient to address this interop issue?

Mustapha.

From:
Pce [mailto:[email-masked]]
On Behalf Of [email-masked]

To: [email-masked];
[email-masked]

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

Hi WG,
and draft authors,

We
still have an urgent interoperability issue to solve
with draft-ietf-pce-stateful-pce. We currently have no
clear semantic for the PCE to advise the PCC that
there is no more path available. This point was
already raised through the list but as we need an
URGENT resolution of this issue because of
implementation timelines, I would like to reactivate
the thread.

The
situation of no path at PCE side can happen in many
situations, and a particular situation will require
PCC to tear down an existing path : let’s think about
two strictly SRLG disjoint LSPs with a working path .
Now the transmission topology is changing (rerouting
at WDM layer) leading SRLG disjointness not being
fitted anymore and PCE cannot find anymore disjoint
path, it must advise one PCC to tear down the path
because it is no more disjoint (strict disjointness
required).

We do
not have any clear semantic today and some
implementations are using empty ERO for this purpose
in PCUpdate but the PCC does not recognize it as a
valid no path significance.

This
subject is critical and I would like that we can
achieve a consensus asap on the target solution so
then vendors can align implementations.

This
thread is focusing on the PCE -> PCC way, but
having a semantic of reporting a no path is also
necessary in PCC->PCE way through PCRpt, at least
to ACK a PCupdate.

One of
the previous discussion on the list talked about the
possibility to use NO-PATH object which already has
this semantic for PCReq/PCRep but as already mentioned
we need to assess impact on existing implementations,
so vendor feedback (with customer implementations) is
highly required. So this is my starting proposal to
initiate the discussion.

Best
Regards,

Stephane
Litkowski

Network
Architect

phone:
+33 2 23 28 49 83

mobile:
+33 6 37 86 97 52

[email-masked]

Thank you.

Thank you.

Thank you.

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

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Wed, 5 Oct 2016 14:01:31 +0000

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:[email-masked]] On Behalf Of Julien Meuric
Sent: Wednesday, October 05, 2016 8:04 AM
To: [email-masked]
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.

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

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

Brgds,

Stephane

From: Dhruv Dhody [mailto:[email-masked]]
Sent: Wednesday, October 05, 2016 06:09
To: Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia - CA); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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?

Regards,
Dhruv

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 ?

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Pce mailing list

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

---

From: Olivier Dugeon <[email-masked]>
Date: Wed, 5 Oct 2016 18:10:59 +0200

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 :
> *From:*Pce [mailto:[email-masked]] *On Behalf Of *Julien Meuric
> *Sent:* Wednesday, October 05, 2016 8:04 AM
> *To:* [email-masked]
> *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>  
>
> Hi all,
>
>     *From:*Dhruv Dhody [mailto:[email-masked]]
>     *Sent:* Wednesday, October 05, 2016 06:09
>     *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane; Aissaoui, Mustapha (Nokia - CA); [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Cc:* 'Dhruv Dhody'
>     *Subject:* RE: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Hi Sudhir/Harish,
>
>      
>
>     *From:* Pce [mailto:[email-masked]] *On Behalf Of *Sudhir Cheruathur
>     *Sent:* 04 October 2016 23:16
>     *To:* [email-masked] <mailto:[email-masked]>; Harish Magganmane <[email-masked] <mailto:[email-masked]>>; Aissaoui, Mustapha (Nokia - CA) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Stephane/Dhruv/Mustapha,
>
>      
>
>     *From: *Pce <[email-masked] <mailto:[email-masked]>> on behalf of "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Date: *Monday, October 3, 2016 at 1:27 AM
>     *To: *Harish Magganmane <[email-masked] <mailto:[email-masked]>>, "Aissaoui, Mustapha (Nokia - CA)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Hi Harish,
>
>      
>
>     *From:*Harish Magganmane [mailto:[email-masked]]
>     *Sent:* Saturday, October 01, 2016 00:53
>     *To:* LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA); [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Hi Stephane,
>
>      
>
>     *From: *Pce <[email-masked] <mailto:[email-masked]>> on behalf of "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Date: *Friday, September 30, 2016 at 8:33 AM
>     *To: *"Aissaoui, Mustapha (Nokia - CA)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject: *Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Hi Mustapha,
>
>      
>
>     *From:*Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]
>     *Sent:* Friday, September 30, 2016 17:08
>     *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject:* RE: Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     Hi Stephane,
>
>     *From:*Pce [mailto:[email-masked]] *On Behalf Of [email-masked] <mailto:[email-masked]>
>     *Sent:* Friday, September 30, 2016 5:46 AM
>     *To:* [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     *Subject:* [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path
>
>      
>
>     ange logo <http://www.orange.com/>
>
>      
>
>     *Stephane Litkowski *
>     Network Architect
>     [email-masked] <mailto:[email-masked]>
>
>      
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: <[email-masked]>
Date: Thu, 6 Oct 2016 07:18:33 +0000

Hi Olivier,

I think we almost have a consensus on using the current ERO object with the semantic “I have no intended path”, so adding a new sibling object is not necessary.
It would then be up to the PCC to have a local policy to control the associated behavior => tear down, revoking delegation, keep existing path or whatever…

Optionally, we still need to agree if we consider NO-PATH object as a complement and optional object.

Brgds,

From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Wednesday, October 05, 2016 18:11
To: Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hello all,

Comments are welcome.

Regards

Olivier

Regards,
Mustapha.

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

Hi all,

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

Brgds,

Stephane

Hi Sudhir/Harish,

Regards,
Dhruv

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Pce mailing list

Pce mailing list

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 10 Oct 2016 02:45:12 +0000

Hi, Stephane,  Olivier, All,

      I support the option 1 Dhruv proposed (see below), which has least impact on existing implementations.

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

If we have rough consensus, we should start to work on the changes  needed in draft-ietf-pce-stateful-pce-16 to clarify, I would propose to add the following sentences in somewhere in Section 6.2 (edited on top of what Dhruv has suggested above):

The ERO may be empty if the PCE cannot find one or a set of valid paths for a delegated LSP.  One typical situation resulting in this empty ERO carried in the PCUpd message is that PCE can no longer find two strictly SRLG-disjoint paths for a delegation LSP after link failure.  If its local policy allows it, the PCC SHOULD signal the tear down of the LSP. Alternatively, PCC MAY revoke delegation and use a locally computed path instead.

Does the text look good to address the ambiguity issue you raised?

Regards,
Xian

发件人: Pce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2016年10月6日 15:19
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]
主题: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Olivier,

Brgds,

From: Pce [mailto:[email-masked]] On Behalf Of Olivier Dugeon
Sent: Wednesday, October 05, 2016 18:11
To: Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hello all,

Comments are welcome.

Regards

Olivier

Regards,
Mustapha.

Hi all,

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

Brgds,

Stephane

Hi Sudhir/Harish,

Regards,
Dhruv

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Pce mailing list

Pce mailing list

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 10 Oct 2016 10:15:10 +0530

Hi Xian,

I would avoid saying set of *paths* for delegated LSP, instead I would
modify your text slightly as -

The ERO may be empty if the PCE cannot find a valid path for a delegated
LSP. One typical situation resulting in this empty ERO carried in the PCUpd
message is that a PCE can no longer find a strict SRLG-disjoint path for a
delegated LSP after a link failure.  If the PCC's local policy allows it,
it SHOULD signal the tear down of the LSP. Alternatively, PCC MAY revoke
delegation and use a locally computed path instead.

Regards,
Dhruv

On Mon, Oct 10, 2016 at 8:15 AM, Zhangxian (Xian) <[email-masked]>
wrote:

> If we have rough consensus, we should start to work on the changes  needed
> in draft-ietf-pce-stateful-pce-16 to clarify, I would propose to add the
> following sentences in somewhere in Section 6.2 (edited on top of what
> Dhruv has suggested above):
>
>
>
> The ERO may be empty if the PCE cannot find one or a set of valid paths
> for a delegated LSP.  One typical situation resulting in this empty ERO
> carried in the PCUpd message is that PCE can no longer find two strictly
> SRLG-disjoint paths for a delegation LSP after link failure.  If its local
> policy allows it, the PCC SHOULD signal the tear down of the LSP.
> Alternatively, PCC MAY revoke delegation and use a locally computed path
> instead.
>
>
>
> *发件人:* Pce [mailto:[email-masked]] *代表 *
> *发送时间:* 2016年10月6日 15:19
> *收件人:* DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC
> Julien IMT/OLN; [email-masked]
> *主题:* Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE
> advising PCC about no path
>
>
>
> Hi Olivier,
>
>
>
> I think we almost have a consensus on using the current ERO object with
> the semantic “I have no intended path”, so adding a new sibling object is
> not necessary.
>
> It would then be up to the PCC to have a local policy to control the
> associated behavior => tear down, revoking delegation, keep existing path
> or whatever…
>
>
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Olivier Dugeon
> *Sent:* Wednesday, October 05, 2016 18:11
> *To:* Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]
> 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).
>
> 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
>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Julien Meuric
> 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.
>
> 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.
>
> 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:[email-masked]
> <[email-masked]>]
> *To:* Sudhir Cheruathur; LITKOWSKI Stephane OBS/OINIS; Harish Magganmane;
> Aissaoui, Mustapha (Nokia - CA); [email-masked];
> 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?
>
>
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Sudhir Cheruathur
> *To:* [email-masked]; Harish Magganmane <
> [email-masked]>; Aissaoui, Mustapha (Nokia - CA) <
> [email-masked]>; [email-masked]; draft-ietf-pce-stateful-pce@
> tools.ietf.org
> >>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
>
> *From: *Pce <[email-masked]> on behalf of "
> [email-masked]" <[email-masked]>
> *To: *Harish Magganmane <[email-masked]>, "Aissaoui, Mustapha
> (Nokia - CA)" <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <draft-ietf-pce-stateful-pce@
> tools.ietf.org>
> 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:[email-masked]
> <[email-masked]>]
> *To:* LITKOWSKI Stephane OBS/OINIS; Aissaoui, Mustapha (Nokia - CA);
> [email-masked]; [email-masked]
> We are not in favor of using empty ERO as way to signal the tearing of an
> LSP. IMO empty ERO object should be interpreted to mean deferring the ERO
> selection to the router, perhaps through local policy on the PCC. For
> example PCC could choose between a local CSPF or a IGP based hop-by-hop.
>
>
>
> In cases where we want PCE to explicitly control the behavior of the PCC
> when a path is not available, NO-PATH object can be used to dictate the
> behavior. One such behavior could be that of tearing down the LSP.
>
>
>
> Thanks,
>
> Harish
>
>
>
> *From: *Pce <[email-masked]> on behalf of "
> [email-masked]" <[email-masked]>
> *To: *"Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Your proposal works from my point of view, but it looks that it causes
> some trouble to another vendor so I would like these people (and others as
> well) to express their concerns regarding usage of empty ERO.
>
>
>
> *From:* Aissaoui, Mustapha (Nokia - CA) [mailto:mustapha.aissaoui@
> nokia.com <[email-masked]>]
> *To:* LITKOWSKI Stephane OBS/OINIS; [email-masked];
> In the last email related to this issue, I made a proposal to Olivier and
> Robert commented on it. Would that be sufficient to address this interop
> issue?
>
> *From:* Pce [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *To:* [email-masked]; [email-masked]
> We still have an urgent interoperability issue to solve with
> draft-ietf-pce-stateful-pce. We currently have no clear semantic for the
> PCE to advise the PCC that there is no more path available. This point was
> already raised through the list but as we need an URGENT resolution of this
> issue because of implementation timelines, I would like to reactivate the
> thread.
>
>
>
> The situation of no path at PCE side can happen in many situations, and a
> particular situation will require PCC to tear down an existing path : let’s
> think about two strictly SRLG disjoint LSPs with a working path . Now the
> transmission topology is changing (rerouting at WDM layer) leading SRLG
> disjointness not being fitted anymore and PCE cannot find anymore disjoint
> path, it must advise one PCC to tear down the path because it is no more
> disjoint (strict disjointness required).
>
> We do not have any clear semantic today and some implementations are using
> empty ERO for this purpose in PCUpdate but the PCC does not recognize it as
> a valid no path significance.
>
>
>
> This subject is critical and I would like that we can achieve a consensus
> asap on the target solution so then vendors can align implementations.
>
> This thread is focusing on the PCE -> PCC way, but having a semantic of
> reporting a no path is also necessary in PCC->PCE way through PCRpt, at
> least to ACK a PCupdate.
>
>
>
> One of the previous discussion on the list talked about the possibility to
> use NO-PATH object which already has this semantic for PCReq/PCRep but as
> already mentioned we need to assess impact on existing implementations, so
> vendor feedback (with customer implementations) is highly required. So this
> is my starting proposal to initiate the discussion.
>
>
>
>
>
> Best Regards,
>
>
>
>
>
>  <http://www.orange.com/>
>
>
>
> *Stephane Litkowski *
> Network Architect
> phone: +33 2 23 28 49 83
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
> mobile: +33 6 37 86 97 52
> <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>

---

From: <[email-masked]>
Date: Tue, 11 Oct 2016 11:14:22 +0000

Hi,

I would rather prefer to have a more generic statement for the PCC local policy :

The ERO may be empty if the PCE cannot find a valid path for a delegated LSP. One typical situation resulting in this empty ERO carried in the PCUpd message is that a PCE can no longer find a strict SRLG-disjoint path for a delegated LSP after a link failure.  The PCC SHOULD implement a local policy to decide the appropriate action to be taken: tear down LSP, revoke delegation and use a locally computed path, keep existing LSP state …

Brgds,

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Monday, October 10, 2016 06:45
To: Zhangxian (Xian)
Cc: LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Xian,

I would avoid saying set of *paths* for delegated LSP, instead I would modify your text slightly as -

The ERO may be empty if the PCE cannot find a valid path for a delegated LSP. One typical situation resulting in this empty ERO carried in the PCUpd message is that a PCE can no longer find a strict SRLG-disjoint path for a delegated LSP after a link failure.  If the PCC's local policy allows it, it SHOULD signal the tear down of the LSP. Alternatively, PCC MAY revoke delegation and use a locally computed path instead.

Regards,
Dhruv

On Mon, Oct 10, 2016 at 8:15 AM, Zhangxian (Xian) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Stephane,  Olivier, All,

Regards,
Xian

发件人: Pce [mailto:[email-masked]<mailto:[email-masked]>] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2016年10月6日 15:19
收件人: DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]<mailto:[email-masked]>
主题: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Olivier,

Brgds,

Hello all,

Comments are welcome.

Regards

Olivier

Regards,
Mustapha.

Hi all,

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

Brgds,

Stephane

Hi Sudhir/Harish,

Regards,
Dhruv

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Pce mailing list

Pce mailing list

Thank you.

---

From: Sudhir Cheruathur <[email-masked]>
Date: Tue, 11 Oct 2016 23:16:43 +0000

Stephane/Dhruv/Xian,

I am concerned with the need to revoke the delegation when there is no path. Today, we can change three attributes of a delegated LSP - Path (ERO), Bandwidth and Metric.

Are we suggesting that when BW and/or Metric is changed it must always be accompanied with a path? How would you handle cases where only BW and/or Metric is changed for a delegated LSPs from controller that has no computation engine or would prefer the PCC to do the computation?  Yes, keep the existing path could be an option but since it is not always guaranteed we will need appropriate error handling.

Thanks
Regds
Sudhir C

From: Pce <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Tuesday, October 11, 2016 at 4:14 AM
To: Dhruv Dhody <[email-masked]>, "Zhangxian (Xian)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi,

Brgds,

Hi Xian,

Regards,
Dhruv

Regards,
Xian

Hi Olivier,

Brgds,

Hello all,

Comments are welcome.

Regards

Olivier

Regards,
Mustapha.

Hi all,

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

Brgds,

Stephane

Hi Sudhir/Harish,

Regards,
Dhruv

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

[nge logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Pce mailing list

Pce mailing list

Thank you.

Thank you.

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 12 Oct 2016 10:24:15 -0400

Hi,

I think the text from Stephane solve well the no-path case, if a PCE would
like to force a tear-down of the LSP, the admin-status bit seems
appropriate.
In the case you mention, a PCE may sets a loose hop towards egress, but its
up to the PCC to expand or not the ERO.

BR
Cyril

On 11 October 2016 at 19:16, Sudhir Cheruathur <[email-masked]>
wrote:

> Stephane/Dhruv/Xian,
>
>
>
> I am concerned with the need to revoke the delegation when there is no
> path. Today, we can change three attributes of a delegated LSP - Path
> (ERO), Bandwidth and Metric.
>
>
>
> Are we suggesting that when BW and/or Metric is changed it must always be
> accompanied with a path? How would you handle cases where only BW and/or
> Metric is changed for a delegated LSPs from controller that has no
> computation engine or would prefer the PCC to do the computation?  Yes,
> keep the existing path could be an option but since it is not always
> guaranteed we will need appropriate error handling.
>
>
>
> Thanks
>
> Regds
> Sudhir C
>
>
>
>
>
> *Date: *Tuesday, October 11, 2016 at 4:14 AM
> *To: *Dhruv Dhody <[email-masked]>, "Zhangxian (Xian)" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> delegated LSP after a link failure.  The PCC SHOULD implement a local
> policy to decide the appropriate action to be taken: tear down LSP, revoke
> delegation and use a locally computed path, keep existing LSP state …
>
>
>
> Brgds,
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Dhruv
> Dhody
> *Sent:* Monday, October 10, 2016 06:45
> *To:* Zhangxian (Xian)
> *Cc:* LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui,
> Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]
> *发件人**:* Pce [mailto:[email-masked]] *代表 *

---

From: <[email-masked]>
Date: Fri, 14 Oct 2016 07:32:09 +0000

Hi Sudhir,

Yes the PCE can change only a subset of parameters of the LSP.
But having a PCE with no computation engine is a bit weird as PCE means computation engine by definition. In your case, it’s more a SDN controller driving some LSP parameters (as we could do with NETCONF for example).
In your case, nothing prevents your SDN controller to just reflect the path sent by the PCC in the ERO.

Morever you may have some issue with the new procedures defined in 5.8.2. as before delegating the LSP, the PCC will need to do a PCReq to your SDN controller, which is a computation request. So you can still fake the PCRep with a NO-PATH, but I know some PCC implementations that are never delegating the LSP if they do not have a path in PCRep (they retry PCReq instead).
Brgds,

From: Sudhir Cheruathur [mailto:[email-masked]]
Sent: Wednesday, October 12, 2016 01:17
To: LITKOWSKI Stephane OBS/OINIS; Dhruv Dhody; Zhangxian (Xian)
Cc: [email-masked]
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Stephane/Dhruv/Xian,

Thanks
Regds
Sudhir C

From: Pce <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 11, 2016 at 4:14 AM
To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>, "Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi,

Brgds,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Monday, October 10, 2016 06:45
To: Zhangxian (Xian)
Cc: LITKOWSKI Stephane OBS/OINIS; DUGEON Olivier IMT/OLN; Aissaoui, Mustapha (Nokia - CA); MEURIC Julien IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Urgent issue with draft-ietf-pce-stateful-pce : PCE advising PCC about no path

Hi Xian,

Regards,
Dhruv

Regards,
Xian

Hi Olivier,

Brgds,

Hello all,

Comments are welcome.

Regards

Olivier

Regards,
Mustapha.

Hi all,

Julien

Oct. 05, 2016 - :
Hi Dhruv, Sudhir

Brgds,

Stephane

Hi Sudhir/Harish,

Regards,
Dhruv

Stephane/Dhruv/Mustapha,

a)      Bring down the LSP

b)      Use local CSPF

Thanks
Redgs
Sudhir C

Hi Harish,

Best Regards,

Stephane

Hi Stephane,

Thanks,
Harish

Hi Mustapha,

Best Regards,

Stephane

Hi Stephane,

Mustapha.

Best Regards,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.

Pce mailing list

Pce mailing list

Thank you.

Thank you.