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

Hi,

Request authors to let us know your view about it.

Thanks.
Venu

From: Cyril Margaria [mailto:cyril.margaria@gmail.com]
Sent: 2015年6月10日 20:34
To: Venugopal Reddy K
Cc: pce; inaminei@google.com
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 <venugopalreddyk@huawei.com<mailto:venugopalreddyk@huawei.com>> wrote:
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?
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.

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)

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.

Response will be appreciated.

Thanks a lot.

Regards,
Venu

Regards,
 Cyril

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce