[Pce] RE: Comments on draft-lee-pce-global-concurrent-optimization-03.txt

Hi all, 

Thanks for your comments and rather intense discussions on various points.
Let me recapitulate all the discussion points here before the next version
would be updated.  

(i) Applicability section
- The applicability section clearly and thoroughly states the detail
scenarios to which GCO can be applied, highlighting potential problems
associated with GCO application such as scalability, synchronization,
failure impact during re-optimization, etc.  
- There shouldn't be, however, any assumptions that preclude GCO from the
applicability to specific networks or scenarios. 

(2) "Real-time" lingo. 
- We will delete "real-time" from the original statement at the minimum. 
- Add some statement associated with an NMS based approach when a large
number of LSPs fails.

(3) Is PCC = NMS for GCO application? 
- We can add "The PCE GCO application is primarily an NMS based solution" in
abstract/introduction. 
- I don't believe we need to say that the PCC for GCO MUST be an NMS. 

(4) "Green-field" issue
- Switch the order in Section 3 such that Re-optimization of an existing
network appears before "green-field" application. 
- Rephrase to add:
	(i) "Green-field application is a special case when there is no LSP
setup. Once 	the LSPs are setup, it is not a green field." 
	(ii) "The need for green-field application arises when network
planner will want 	to make use of computation servers to plan the LSPs
that will be provisioned 	in their network." 

(5) "Sequential re-optimization ... will unlikely to produce substantial
improvements in overall network optimization except in very sparsely
utilized networks."
- We will rephrase the statement. 

(6) Multi-Session Object
- We agreed that this will move this feature to the second phase.

(7) "Multi-step" rerouting
- We agreed that we will add the potential impact by this feature. 

(8) Objective Function 
- We are in sync 100%. 

Thanks for your comments. 

Best Regard, 

Young 

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
Sent: Friday, May 11, 2007 9:02 AM
To: JP Vasseur
Cc: Young Lee; 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Eiji Oki'; 'Daniel King'
Subject: Re: Comments on draft-lee-pce-global-concurrent-optimization-03.txt

Hi,

[PCE list removed]

>> Define "real-time".
>>
>> The applicability to the problem space is clear. A well-known set of
>> LSP has been impacted by a network failure. Rather than compute new
>> paths on demand from the head-end LSPs with the consequent resource-
>> contention blocking problems, there may be considerable benefit in
>> computing the paths of the LSPs as a set. (Of course, this assumes
>> the availability of certain information, but an NMS might reasonably
>> have access to this and make the bulk computation request.)
>>
>> Thus, if there is any modification to make, I suggest only deleting
>> "in real-time".
>
> I guess that we can agree on the fact that centralized system provide
> more qualitative output in term of path quality but are typically fairly
> slow and not appropriate for "real  time" processing.

I think that Dan and I are bound to argue about "fairly slow".

But it does depend on the definition of "real time".
On the whole, n CSPF computations can be expected to take n times the time 
of one CSPF computation.
Bulk computations can be made to scale far better than linearly with the 
number of paths.

> Now of course, we could argue for ever on:
> * More qualitative: by how much ?
> * What do we mean by path quality or optimality ?
> * What does "slow" mean ?
> We could certainly find scenarios where the delta in term of
> optimality is fairly negligible and centralized systems
> are extremely slow, and vice versa.
> So my point was to not "promote" such system for "real-time" processing.

OK.
Well I'd turn it around and say "do promote such systems for offline 
processing" and allow them to be used on-line if someone wants to and if 
they are observed to work.

And finally, reoptimization and recovery after FRR do not need the same 
"insant" action that unprotected recovery needs. So I think it is probaly OK

to not push "real time" as I suggested.

[SNIP]

>> Why would the procedures not be applicable to a head-end LSR
>> requesting bulk reoptimization of the set of LSPs for which it acts
>> as ingress? (I.e. a subset of all LSPs in the system.)
>>
>> We already accept that such an LSR should be allowed to issue
>> individual LSP reoptimization requests. And we already accept that
>> a PCReq may contain multiple computation requests that are 'linked'.
>>
>> So, if JP's request is that an LSR should not issue an optimization
>> request for an LSP for which it is not the head-end, I can see the
>> point. Although I might want to rephrase this because the important
>> question is what use is made of the computation response - that is,
>> if the PCC is unable to make use of the computed path, there is no
>> value in performing the computation.
>>
>> Clearly, NMS is a primary application of this work, but it is not
>> the only application. Another key use would be the VNT Manager
>> component discussed in the multi-layer PCE drafts.
>
> This is an important point, on which we may not 100% agree. If now
> one want to use this model where each LSR is a PCC so as to globally
> optimize the path  computation of a set of TE LSPs, that clearly
> requires very significant synchronizations between the PCE and each
> of those PCCs (which is not the base with synchronized path
> computation request  such as diverse path computations
> originated by a single LSR. In other words, consider the case where
> a PCC requires to resize one of its TE LSPs and sends a request to
> the PCE, which in turn triggers the reroute of hundreds of TE LSPs
> to satisfy that demand. See the number of synchronizations that this
> does require between the PCE and all PCCs. And there are many
> other scenarios where such model could have limitations that the draft
> should point out.
>
> Are we agreeing ?

Completely, but...

You must not assume that there is only one point of provisioning control for

any LSP. And you must not assume that there is only one PCC for any head-end

of an LSP.

So, for example, when an LSP is requested, the NMS may or may not act as a 
PCC to find a path for the LSP.
Thus the message sent by the NMS to the head-end LSR may or may not contain 
a full path.
Thus the head-end LSR may not or may act as a PCC and consult a PCE.

So, on recovery, there are options:
1. The head-end LSR acts as PCC for a single LSP
2. The head-end LSR acts as PCC for a batch of LSPs
3. The head-end LSR acts as PCC for a single distributed request
    for global reoptimization, including LSPs for which it is not
    head-end
4. As 1 or 2, but the PCE is responsible for coordinating all
    requests from PCCs and treating them as one
5. The NMS is responsible for determining all LSPs that need
    to be recomputed.

I would not speak in favor of options 3 and 4.
I would speak in favor of options 1, 2 and 5.

Dimitry would, of course, be worried about the fact that we are potentially 
taking intelligence that was previously distributed into the control plane 
and putting it back into the "management" plane. For options 1 and 2, I 
would say this is not true. For option 5, this is clearly true, but it is 
the cost of full optimization.

[SNIP]

> So it is a green field for a very short period of time.

Such is the nature of *all* green fields. Otherwise, what would be the 
point? :-)

>>>>> 5)
>>>>>
>>>>>     Note that sequential re-
>>>>>     optimization of such TE LSPs is unlikely to produce
>>>>>     substantial improvements in overall network optimization
>>>>>     except in very sparsely utilized networks.
>>>>>
>>>>> Well, that DEPENDS ! I could show you distributed algorithms where
>>>>> sequential reoptimization allows for a significant improvements. I
>>>>> would suggest to remove that statement.
>>
>> Actually, I think that the sequential algorithms that JP refers to
>> are actually *global* reoptimization. That is, they sequence through
>> the set of LSPs making optimization improvements. The fact that the
>> algorithms are distributed is neither here nor there.
>
> We keep facing that terminology issue with the word "distributed"
> where this could apply to the algorithm itself or the fact that path
> computations may be performed by different engine (e.g. case
> where each LSR is its own PCE). I was referring to the "unlikely to
> produce substantial ..." statement.
> Techniques exist that produce good results with sequential re-
> optimization, thus my suggestion to delete that statement, or
> please refine it.

Well, certainly the text that stands is a little too definitive.

But there is a simple 6-node networks where sequential processing simply 
will not produce a solution unless there is coordination between the LSP 
computations, and since the LSPs have separate head-ends, a favorable result

can only be achieved using coordinated requests, or a central request.

In no way does this say that you must always do this, just that in order to 
get best results you may want to.

>>> Yes, it actually depends on the topology, the traffic matrix, the
>>> online algorithm used, etc. We will delete this statement.
>>
>> So rather than deleting the statement, I suggest qualifying it.
>> Of course, the potential for network-wide gains from reoptimization
>> of LSPs one-by-one is dependent on the network usage and size of the
>> LSPs being reoptimized. But the key point remains: if you only
>> compute the reoptimized path of one LSP at a time, and if you give
>> no consideration to the other LSPs in the network when you do it,
>> you run the risk of significant devaluation of the process.
>
> See it is always difficult to avoid "significant", ... That really
> depends. For example, dynamic preemption schemes based
> on LSP size can be designed to get close to the results given
> by a global CSPF applied by placing TE LSPs in decreasing
> sizes, which itself can be fairly close to some centralized
> algorithms.

True.
But hard to justify such schemes in the same thread where you talk about the

importance of minimising traffic loss and jitter.

>>> I mentioned
>>> a trade-off between optimization versus network impact. Indeed, if
>>> you can reoptimize the set of TE LSPs in order to reduce the max
>>> link  utilization by 5% but this requires to reroute two hundreds
>>> TE LSPs with on the average 4 reroutes per TE LSP, this may not be
>>> a good idea.
>>
>> Well, that would depend, wouldn't it? If the network is unable to
>> place any more LSPs, one might think that retrieving 5% was
>> pretty cool :-)
>
> Ah I was referring to a reoptimization case (not failure): " if you
> can reoptimize the set of TE LSPs in order to reduce the max link
> utilization by 5% ..."

Yup.
I, too, am talking about the reoptimization case.

Oh, this *is* fun.
Well more fun than my real job ;-)

Cheers,
Adrian 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce