Subject: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-04

From: Venugopal Reddy K <[email-masked]>
Date: Wed, 10 Jun 2015 07:32:06 +0000

Hi, Everyone!

Have few comments/queries on draft-ietf-pce-pce-initiated-lsp-04. Could you please clarify on below points:

  Section 6

  In case of PCEP session failure, control over PCE-initiated LSPs
   reverts to the PCC at the expiration of the redelegation timeout.  At
   this point, the LSP is an "orphan" until the expiration of the State
   Timeout timer.  To obtain control of a PCE-initiated LSP, a PCE
   (either the original or one of its backups) sends a PCInitiate
   message, including just the SRP and LSP objects, and carrying the
   PLSP-ID of the LSP it wants to take control of

1.       In case of Backup PCE, what is the trigger point to send PCInitiate message to take control of orphan PCE-initiated LSP? I am wondering how does a backup PCE come to know that some LSPs are orphaned?

2.       Another option would be, if PCC takes charge and delegate the orphaned PCE initiated LSPs to backup PCE based on the local policy?

Response will be appreciated.

Thanks a lot.

Regards,
Venu

---

From: Cyril Margaria <[email-masked]>
Date: Wed, 10 Jun 2015 11:03:57 -0400

Hi,

On 10 June 2015 at 03:32, Venugopal Reddy K <[email-masked]>
wrote:

> 1.       In case of Backup PCE, what is the trigger point to send
> PCInitiate message to take control of orphan PCE-initiated LSP? I am
> wondering how does a backup PCE come to know that some LSPs are orphaned?
>
I see two scenarios :
  1) Another PCEP Session is up , in that case it seems to imply that the
PCE(s) keep track of the LSPs it can manage and the liveliness of the other
PCEs.
   2) There is no other PCEP session, the PCC reconnects to another PCE, in
this case the PCE can try to take ownership of the Initiated, not delegated
LSPs

 While I believe 1) is an interesting architecture, I do not think the
protocol procedures should put such constraint to the PCE implementation,
so the second option you propose should be allowed.

>
>
> 2.       Another option would be, if PCC takes charge and delegate the
> orphaned PCE initiated LSPs to backup PCE based on the local policy?
>
>
>
I think this should be allowed, the text could be :

In case of PCEP session failure, control over PCE-initiated LSPs
reverts to the PCC at the expiration of the redelegation timeout.  At
this point, the PCC MAY delegate the LSP to another PCE. the LSP is an
"orphan" until the expiration of the State
Timeout timer.

Some coordination between PCEs is still needed, for the original PCE to
regain control over that LSP the current PCE must forfeit control over that
LSP.

In addition there is no Error to indicate to the PCE that he can't have the
delegation back, this should be added , for instance 24,4

LSP instantiation error, Requested delegation rejected, another PCE
has the delegation. (ideally allow the optional inclusion of the other
PCE SPEAKER-IDENTITY-ID for troubleshooting. it should be subject to
security policies)

>  Response will be appreciated.
 Cyril

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

---

From: Venugopal Reddy K <[email-masked]>
Date: Tue, 16 Jun 2015 05:57:26 +0000

Hi,

Request authors to let us know your view about it.

Thanks.
Venu

From: Cyril Margaria [mailto:[email-masked]]
Sent: 2015年6月10日 20:34
To: Venugopal Reddy K
Cc: pce; [email-masked]
Subject: Re: [Pce] Few comments/queries on draft-ietf-pce-pce-initiated-lsp-04

Hi,

On 10 June 2015 at 03:32, Venugopal Reddy K <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Everyone!

  Section 6

1.       In case of Backup PCE, what is the trigger point to send PCInitiate message to take control of orphan PCE-initiated LSP? I am wondering how does a backup PCE come to know that some LSPs are orphaned?
I see two scenarios :
  1) Another PCEP Session is up , in that case it seems to imply that the PCE(s) keep track of the LSPs it can manage and the liveliness of the other PCEs.
   2) There is no other PCEP session, the PCC reconnects to another PCE, in this case the PCE can try to take ownership of the Initiated, not delegated LSPs

 While I believe 1) is an interesting architecture, I do not think the protocol procedures should put such constraint to the PCE implementation, so the second option you propose should be allowed.

Yes. Let us know authors view about it.

this point, the PCC MAY delegate the LSP to another PCE. the LSP is an "orphan" until the expiration of the State

Timeout timer.

Some coordination between PCEs is still needed, for the original PCE to regain control over that LSP the current PCE must forfeit control over that LSP.
In addition there is no Error to indicate to the PCE that he can't have the delegation back, this should be added , for instance 24,4

LSP instantiation error, Requested delegation rejected, another PCE has the delegation. (ideally allow the optional inclusion of the other PCE SPEAKER-IDENTITY-ID for troubleshooting. it should be subject to security policies)

Yes. I believe draft doesn’t address it. According to draft, PCC cannot revoke the delegation for PCE initiated LSPs for an active PCEP session. So, if the original PCE is UP and had to take the control back of its own initiated LSPs(from backup PCE), it might not be possible without some coordination between both PCEs(either through in-band or out-of-band mechanisms).
Another option would be, PCC can identify the original PCE from PCE SPEAKER-IDENTITY-ID of initiated LSP(at create time). Any time original PCE tries to take control, PCC may choose to either revoke control of LSP from backup PCE and delegate back to original PCE Or may send PCErr with “requested delegation rejected”.

Request authors opinion about it.

Thanks a lot.

Regards,
Venu

Regards,
 Cyril

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