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

Hi,

On May 11, 2007, at 4:26 PM, Young Lee wrote:

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

Yes as long as the flags are in place to indicate when such  
mechanisms could
be fairly "dangerous" in some deployment scenarios in term of network  
stability.

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

Yes.

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

In that case, you would need to explain in more details what are the  
consequences
of applying such a model to the case where each LSR is a PCC. In  
particular, I'm
referring to the synchronization issues between all PCCs and the PCE  
for GCO,
including the case where an LSR fails to signal a TE LSP after the  
GCO has been
performed.

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

Thanks ... How ?

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

OK.

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

OK, will wait for your text.

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

Thanks.

JP.

> 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