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

From: Ina Minei <[email-masked]>
Date: Wed, 6 Jul 2016 17:23:42 -0700

Following the reminder from Adrian, please see my replies inline below,
look for ###.

>
>
>
>
>
> *From:* Pce [mailto:[email-masked]] *On Behalf Of *Venugopal Reddy K
> *Sent:* 2015年6月16日 11:27
> *To:* pce; [email-masked]
> *Cc:* Cyril Margaria
> *Subject:* 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:[email-masked]
> <[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]>
> 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.
>

### Either option is allowed.  The trigger of how to detect an orphaned LSP
is outside the scope of this document, similar to the decision of when to
instantiate or delete a pce-intiated LSP. This document only puts forth the
procedure a PCE can take after detecting an orphan LSP. Either (1) or (2)
can be supported with these procedures, but note that the document does not
_require_ support of any particular method for identifying orphans, and
that the state will be correctly cleaned up at the expiration of the State
Timeout timer.

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

### The draft avoids this kind of local action because it creates a
situation where decisions around the ownership of the LSPs are now split
between the central controller (where by central controller I mean either
one or multiple PCEs cooperating) and the local node, rather than being
owned by the central controller. This is also why a PCC cannot revoke a
delegation for a PCE-initated LSP. Allowing a mixed way of operation would
bring the need for a lot of complexities and error handling. I think this
is something better solved at the PCE layer.

>
>
>
> Response will be appreciated.
>
>
>
> Thanks a lot.
>
>
>
> Regards,
>
> Venu
>
>
>
>
>
> Regards,
>  Cyril
>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>
>
>