Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp

From: Aaron Itskovich <[email-masked]>
Date: Wed, 4 Jan 2017 15:07:39 -0500

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

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 5 Jan 2017 16:25:24 +0000

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:[email-masked]] On Behalf Of Aaron Itskovich
Sent: 04 January 2017 20:08
To: [email-masked]
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.

Thanks
Aaron

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

---

From: Aaron Itskovich <[email-masked]>
Date: Thu, 5 Jan 2017 14:30:02 -0500

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

---

From: Julien Meuric <[email-masked]>
Date: Mon, 9 Jan 2017 14:00:23 +0100

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 - [email-masked]:
>> 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
>>
>>
>> delegation to the PCC to initiate transfer of LSP "ownership" to
>> another PCE server.
>>
>> 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.
>>
>>
>>       - 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
>>

---

From: Jonathan Hardwick <[email-masked]>
Date: Mon, 9 Jan 2017 13:45:40 +0000

Hi Aaron

Thanks.  So actually, I need to backtrack and agree that there is a mechanism defined for a backup PCE to request that an orphaned LSP is delegated to it - I had missed that.

I am not sure that this implies that the PCC cannot re-delegate of its own free will.  It would be useful to have that clarified in the draft.

However, given this mechanism exists, it does raise the question about how PCEs should properly cooperate in terms of how orphaned LSPs are detected and who should request ownership.  I know that there is work ongoing in the following draft which discusses co-operation between redundant PCEs.  I am not sure whether your idea is best discussed in the context of that draft or in draft-ietf-pce-pce-initiated-lsp.  Perhaps the authors could chime in?
https://tools.ietf.org/id/draft-litkowski-pce-state-sync-00.txt

Best regards
Jon

-----Original Message-----
From: Aaron Itskovich [mailto:[email-masked]] 
Sent: 05 January 2017 19:30
To: Jonathan Hardwick <[email-masked]>; [email-masked]
Subject: Re: [Pce] draft-ietf-pce-pce-initiated-lsp

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>

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

---

From: Julien Meuric <[email-masked]>
Date: Mon, 9 Jan 2017 17:13:05 +0100

Hi,

This topic was tackled a while ago in the context of
draft-ietf-pce-pce-initiated-lsp:
https://mailarchive.ietf.org/arch/msg/pce/wn4gGwZnTZS53pbyg1eCHw3YMVE

It looks like the I-D would benefit from clarification on this matter
before sending it to the IESG. Authors, what to do you think?

Aaron (Cyril?), while keeping feature extensions for another document
(cf. Dhruv's proposal), would you have some clarification text to
propose here?

Thanks,

Julien

---

From: Robert Varga <[email-masked]>
Date: Tue, 17 Jan 2017 20:40:16 +0100

> Hi Aaron

Hello Jon,

> I am not sure that this implies that the PCC cannot re-delegate of its own free will.  It would be useful to have that clarified in the draft.

Note that Redelegation Timeout Interval is a PCC-local value, which the
PCC can alter dynamically based on its internal state at any moment (as
per pce-stateful-pce section 2). pce-stateful-pce does not change the
fact that the PCC is in control over an LSP's state.

With pce-pce-initiated-lsp the set of options available to a PCC with
respect to having a say in LSP's shape, form and existence is limited
and involves trade-offs, but at the end of the day PCC can always assume
control of an LSP.

Specifically it can (without implying it should) legally execute the
following sequence based solely on its local policy:
1) terminate the PCEP session with the primary PCE
2) reduce Redelegation Timeout Interval to 0, effectively expiring it
3) delegate the (now orphan) LSP to a currently-connected backup PCE
4) restore Redelegation Timeout Internal back to normal

Step 3 can alternatively involve reducing State Timeout Interval, at
which point the PCC is in complete control of the LSP (can delete it or
revert it to operator-defined default per section 2).

> However, given this mechanism exists, it does raise the question about how PCEs should properly cooperate in terms of how orphaned LSPs are detected and who should request ownership.

pce-stateful-pce was designed with PCC being central authority over LSP
state and how it relates to connected PCEs.

With pce-pce-initiated-lsp there are multiple options how a set of
redundant PCEs can be realized. It may also involve a lot complex
implementation-specific trade-offs, for example in load-balancing, hence
we chose to leave inter-PCE arbitration out of scope.

As outlined above, a PCC implementation with a sufficiently smart local
policy can still act as a coordinator, although quite a limited one.

Regards,
Robert