Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt

From: Alia Atlas <[email-masked]>
Date: Mon, 25 Apr 2005 01:11:27 -0400

In ref to the request prioritization, I agree that discarding lower 
priority requests shouldn't generally be necessary.  At the same time, I 
think it is necessary to consider whether request starvation can occur for 
particular priorities, whether that is acceptable, and how that is handled.

For the failure response discussed in 6.3.2, is it possible for the PCC to 
believe that the PCE is unreachable - but not vice versa?  If such a 
scenario is possible, then it is necessary to have a mechanism to clear out 
old requests when communication is re-established.  A few more words here 
could be helpful.  For instance, is the assumption that the underlying 
reliable communication mechanism ensures reciprocal knowledge of liveness?

I'm not sure that we want to fully consider stateful PCEs, but assuming 
that we do at least wish to cover it somewhat, how is the success/failure 
of the computed LSP reported back to the PCE?  This seems to be a 
requirement - unless there's an assumption that all LSP signalling will 
always succeed in scenarios where there is a stateful PCE.  For that 
matter, the stateful PCE introduces the requirement for a PCE to be able to 
delete/remove a previously computed LSP.   I think that there may be 
similar requirements related to the recovery & failure scenarios.

Thoughts?

Alia

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

---

From: Zhang Renhai <[email-masked]>
Date: Mon, 25 Apr 2005 16:07:00 +0800

Hi,Alia Atlas, all 

----- Original Message ----- 
From: "Alia Atlas" <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 25, 2005 1:11 PM
Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt

> always succeed in scenarios where there is a stateful PCE. 

No matter whether it is the scope of this draft , some interesting thoughts arose:
Even with stateful PCEs, we might not hope that all computed LSPs will be
successfully established.( might we? ),there should be such possibility,even not a lot.
Using crankback, there will be some difference between the computed LSP and 
the established LSP. To keep PCEs stateful, the difference should be reported
to PCEs by ingress after the LSP has been established ,so I think some more communation 
is needed in this draft.).(between having computed and receiving this communation, the stateful 
PCE is temporarily stateless! )

Another question: what is the substaintial differece between stateful and stateless
when establishing the computed LSPs? Is it the result of establishing  the LSP or the 
possibility of successfully establishing the LSP?

Third question:Is there loose node in the computed result? if yes, then:
The more there are strict nodes in the computed LSP, the more 
possibility of unsuccessfully establishing the LSP there is.Using crankback, 
I suggest that more loose node should be included in the result, some 
small-scope computation can be distributed to mid-LSRs when establishing LSP.
For ingress, the most important thing is if there is a LSP satisfying the restriction.

Thanks,
Zhang

> For that

---

From: JP Vasseur <[email-masked]>
Date: Mon, 25 Apr 2005 06:57:49 -0400

Hi,

On Apr 25, 2005, at 4:07 AM, Zhang Renhai wrote:

> Subject: [Pce] a few comments on 
> draft-ash-pce-comm-protocol-gen-reqs-00.txt
>
>

Agree with you Alia.

>> always succeed in scenarios where there is a stateful PCE.

I do not think that this could be an assumption. In the case of 
statefull PCE, LSP status should of course be known by the PCE and thus 
be reported by PCC. Same thing, when/id head-end decides to tear an LSP 
down.

My assumption was that such requirement would be discussed in the 
context of an application-specific requirement ID whereas this ID is 
related to generic requirements. Can the DT confirm ?

> PCE is temporarily stateless! )

I'm not sure that crankback used in combination with statefull PCE is a 
very likely scenario but in any case, statefull PCE would need to know 
the LSP state for sure.

> Third question:Is there loose node in the computed result?

Could be a possibility indeed.

> if yes, then:
> possibility of unsuccessfully establishing the LSP there is.

I do not think that this is a correct statement ...

> Using crankback,

It is application specific and there won't be *one* model of statefull 
PCE. Consider the case of a GMPLS network where a statefull PCE is used 
to compute optimal paths satisfying multi-constraint criterions for a 
limited number of LSPs that do not change very often. Then in this 
case, computing path with strict hops only is certainly the most 
desirable scenario and loose hops with cranback would certainly lead to 
less optimal paths and increased signalling overhead/call set up time.

Again, I'm afraid that there won't be one model capable of addressing 
all scenarios.

Hence, I think that the model of specifying a generic protocol 
requirements followed by more specific requirements ID is a good 
approach.

Thanks.

JP.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 25 Apr 2005 08:26:46 -0400

Hi,

At 06:57 AM 4/25/2005, JP Vasseur wrote:
>I do not think that this could be an assumption. In the case of statefull 
>PCE, LSP status should of course be known by the PCE and thus be reported 
>by PCC. Same thing, when/id head-end decides to tear an LSP down.
>
>My assumption was that such requirement would be discussed in the context 
>of an application-specific requirement ID whereas this ID is related to 
>generic requirements. Can the DT confirm ?

My assumption is that all stateful PCEs would impose some basic 
requirements on learning the results of an LSP set-up.  I agree that there 
may be additional application-specific requirements, but the basics for 
maintaining/obtaining state info would be the same.

>very likely scenario but in any case, statefull PCE would need to know the 
>LSP state for sure.

I also don't see crankback with a stateful PCE as very likely.

>Again, I'm afraid that there won't be one model capable of addressing all 
>scenarios.
>
>requirements followed by more specific requirements ID is a good approach.

Absolutely.  I just think there are some generic requirements imposed by 
statefulness.

Alia

---

From: "Igor Bryskin" <[email-masked]>
Date: Mon, 25 Apr 2005 08:34:54 -0400

Alia,

See my comments in-line.

Igor

----- Original Message ----- 

To: <[email-masked]>

Sent: Monday, April 25, 2005 1:11 AM

Ø      In ref to the request prioritization, I agree that discarding lower
> particular priorities, whether that is acceptable, and how that is
handled.

Ø      IB>> Agreed

Ø
> reliable communication mechanism ensures reciprocal knowledge of liveness?

Ø      IB>> Agreed

> of the computed LSP reported back to the PCE?

IB>> PCE does not compute LSPs, rather, paths for LSPs. There could be
multiple reasons why a path is not materialized as an LSP taking this path.
To name a few:

Ø      PCC may do pre-computation - just request a path for an LSP to get an
idea how it will be routed without actually triggering the setup;

Ø      PCC may request paths from several PCEs and choose the most suitable
response;

Ø      PCE may not be involved at all - the path for the LSP could be
explicitly specified by management;

Ø      LSP could be rerouted because of some failure during or after the
setup

Ø      ...

Hence, stateful PCE does not need  PCCs to report LSPs, rather, there should
be some mechanism to feed PCE with LSPs and their actual paths no matter how
the LSPs end up taking these paths. This is something that very difficult to
achieve in a timely and scalable manner. One approach is to have PCE use
SNMP sessions with each and every LSR in the network and query LSPs that
they have originated.

Igor

  This seems to be a

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 26 Apr 2005 11:06:03 +0800

Hi,JP

Thank you for your replay.
See in line.

  ----- Original Message ----- 
  From: JP Vasseur 
  To: Zhang Renhai ; Alia Atlas 
  Cc: [email-masked] 
  Sent: Monday, April 25, 2005 6:57 PM
  Subject: Re: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt

  Hi,

    Hi,Alia Atlas, all 

    ----- Original Message ----- 
    From: "Alia Atlas" <[email-masked]>
    To: <[email-masked]>
    Sent: Monday, April 25, 2005 1:11 PM
    Subject: [Pce] a few comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt

  Agree with you Alia.

  I do not think that this could be an assumption. In the case of statefull PCE, LSP status should of course be known by the PCE and thus be reported by PCC. Same thing, when/id head-end decides to tear an LSP down.

  My assumption was that such requirement would be discussed in the context of an application-specific requirement ID whereas this ID is related to generic requirements. Can the DT confirm ?

  I'm not sure that crankback used in combination with statefull PCE is a very likely scenario but in any case, statefull PCE would need to know the LSP state for sure. 
  [zrh] Why not ?Think of crankback's funtion.
         In spite of which kind of PCE the LSP is established through(stateful or stateless),
         not all nodes or links on the LSP can be local repaired for some reason,
         crankback will be a good substitute. Otherwise, the failure of these nodes or links
         may lead to the LSP's end-to-end restoration.

    if yes, then:

  I do not think that this is a correct statement ...
  [zrh]By saying this, I mean that, for example, in a ospf TE area, node A can get to C through B or D, 
         if two stateful PCEs serve this area, and two computation request are *simultaneously and respectively*
         done by these two PCEs, resouces competiton may occur when establishing LSPs, the two
         computed LSP may all go through B or through D, perhaps the B's or D's resource can only serve one LSP,but another is enough.
         one of the two LSPs will fail. With loose node information,this may be avoided,because the A can compute in-order.

         I think that there will be much issue on stateful PCE for the duration between computing and establishing LSP.       

    Using crankback, 

  It is application specific and there won't be *one* model of statefull PCE. Consider the case of a GMPLS network where a statefull PCE is used to compute optimal paths satisfying multi-constraint criterions for a limited number of LSPs that do not change very often. Then in this case, computing path with strict hops only is certainly the most desirable scenario and loose hops with cranback would certainly lead to less optimal paths and increased signalling overhead/call set up time.

  Again, I'm afraid that there won't be one model capable of addressing all scenarios.
  [zrh] agree 

  Hence, I think that the model of specifying a generic protocol requirements followed by more specific requirements ID is a good approach.
  [zrh] Agree .

  Thanks
  Zhang

  Thanks.

  JP.

    Thanks,
    Zhang

      For that 

      Thoughts?

      Alia

---

From: JP Vasseur <[email-masked]>
Date: Thu, 28 Apr 2005 12:08:12 -0400

Hi,

On Apr 25, 2005, at 11:06 PM, Zhang Renhai wrote:

>> Subject: Re: [Pce] a few comments on 
>> statefull PCE, LSP status should of course be known by the PCE and 
>> thus be reported by PCC. Same thing, when/id head-end decides to tear 
>> an LSP down.
>>
>> I'm not sure that crankback used in combination with statefull PCE is 
>> a very likely scenario but in any case, statefull PCE would need to 
>> know the LSP state for sure.

But this is a different scenario than relying on a statefull PCE to 
return loose hops ... You "may" use crankback for partial repair and in 
this case, you need to keep the statefull PCE updated of course. Note 
that another alternative (probably more efficient) is to rely on local 
protection, followed by end to end reoptimization.

>>        if two stateful PCEs serve this area, and two computation 
>> request are *simultaneously and respectively*
>>        computed LSP may all go through B or through D, perhaps the 
>> B's or D's resource can only serve one LSP,but another is enough.
>>        one of the two LSPs will fail.

Well if you refer to the case of using N non synchronized statefull 
PCEs then the race condition issue is not the more challenging ;-) 
(furthermore note that distributed CSPF path computation leads to race 
condition also (and there are solutions to help there) and I do not 
think that the use of loose hops is the way to address the problem.

>> With loose node information,this may be avoided,because the A can 
>> compute in-order.
>>  
>>        I think that there will be much issue on stateful PCE for the 
>> duration between computing and establishing LSP.      
>>    
>>
>>
>>> Using crankback,
>> It is application specific and there won't be *one* model of 
>> statefull PCE. Consider the case of a GMPLS network where a statefull 
>> PCE is used to compute optimal paths satisfying multi-constraint 
>> criterions for a limited number of LSPs that do not change very 
>> often. Then in this case, computing path with strict hops only is 
>> certainly the most desirable scenario and loose hops with cranback 
>> would certainly lead to less optimal paths and increased signalling 
>> overhead/call set up time.
>>

JP.