Hi Aaron, Thank for you comment.
As you point out, the current I-D has taken a timer-based approach: - while State Timeout is not expired, decision is at the PCE level, any PCE with ID knowledge may claim control (not necessarily granted); - once State Timeout is expired, the PCC gets the decision. What you are proposing could be a valuable enhancement, but at this stage we would prefer to send this version that has been there and implemented for a while. As a result, your proposal would deserve a new extension draft, focusing on take-over negotiation, which could be discussed with the WG. Please feel free to proceed. Best regards, Julien Jan. 05, 2017 - aitsk...@cisco.com: > Hi Jon, > > Thanks for your reply. > My interpretation of the following section of the existing > draft-ietf-pce-pce-initiated-lsp is > that PCC cannot just re-delegate PCE initiated LSP to a PCE. > > <snip> > > 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. Receipt of a > PCInitiate message with a non-zero PLSP-ID normally results in the > generation of a PCErr. If the LSP is an orphan, the PCC MUST NOT > generate an error and MUST redelegate the LSP to the PCE. The State > Timeout timer for the LSP is stopped upon the re-delegation. > </snip> > > I read it as PCC is not free to delegate PCE initiated LSP even in > orphan state, > it rather waits (using State Timer) for other PCE server to "adopt" such > "orphan" LSP. > This behavior is different for the PCE initiated LSPs vs PCC initiated > LSPs. > Hence my suggestion was a mechanism that will help redundant PCE servers to > discover PCE initiated LSPs that enter "orphan" state and trigger > "adoption" > process which is different then the just re-delegation. > > Thanks > Aaron > > > On 2017-01-05 11:25 AM, Jonathan Hardwick wrote: >> Hi Aaron >> >> Thanks for the comment. There are no procedures defined that would >> allow a PCE to initiate a take-over of an LSP from a PCC. Rather, the >> PCC must delegate the LSP to an appropriate PCE (if the LSP is >> initiated by a PCE then it must initially be delegated to that PCE). >> The cases you mention would be resolved by the PCC making a local >> decision whether or not to re-delegate the LSP to an alternative PCE. >> >> So, I am not sure that the "orphan" flag would be useful to the PCE, >> at least not for the purpose that you describe. >> >> Best regards >> Jon >> >> >> -----Original Message----- >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aaron Itskovich >> Sent: 04 January 2017 20:08 >> To: pce@ietf.org >> Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp >> >> >> I suggest to add indication that PCE Initiated LSP is orphan to LSP >> object in PCReport message. This information will be useful in >> facilitating takeover of an orphan LSP by redundant PCE server. >> >> Option 1) Adding bit to the LSP flags (L-bit "parentless/orphan") that >> will be set in the LSP object of the PCReport message sent when PCE >> Initiated LSP becomes orphan as result of connection loss to the PCE >> server that initiated this LSP or because such PCE server returns LSP >> delegation to the PCC to initiate transfer of LSP "ownership" to >> another PCE server. >> >> Option 2) Adding bit to the LSP flags (D2-bit ) that is set when such >> LSP is delegated to any PCE server. In this option PCE receiving >> report will be able to derive when PCE Initiated LSP is in orphan >> state when C flag in the report is set and the new D2-bit is not set. >> >> >> This proposal (regardless which option 1 or 2 is used ) alows PCC to >> propagate "orphan" state for the PCE initiated LSP to all PCE servers. >> It will help to trigger takeover of a PCE initiated LSP. The existing >> alternative is to rely on the PCE server to server communication for >> detection of such events which is prone to errors. >> >> For example: >> >> - loss of communication between PCE-A and PCE-B may be >> interpreted as "takeover" trigger which is not necessarily true as >> PCE-A<->PCC connection may still be up. >> - In case where PCE-A <-> PCC connection is down and both PCC >> <-> PCE-B and PCE-A <-> PCE-B connections are up we will need each >> PCE server to distribute information about connection with it's >> clients to all peers >> >> The suggestion frees PCE server from the need to propagate it's client >> connection status to all other PCE servers. >> >> Let me know what you think >> >> Thanks >> Aaron >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
