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

[Tidied up from Digest response thread]

<chair hat firmly OFF>

>>> The authors requested the WG to adopt draft-lee-pce-global-
>>> concurrent-optimization-03.txt as a PCE WG document but before
>>> pooling the list, >>> I'd like to make a few comments/requests:
>>>
>>> This solution is indeed compliant with RFC4655 and as pointed out in the 
>>> ID, PCEP already supports synchronized path computation requests through 
>>> the use of the SVEC object.
>>>
>>> 1) The PCEP extensions defined in this document are quite
>>> reasonable and do not substantially overload the protocol
>>> itself. That being said, the exchange of a substantially large
>>> amount of data will unavoidably stress the machinery in a significant 
>>> way. Scalability of solutions trying to achieve
>>> global optimization have been discussed in length so I won't propose to 
>>> re-open a fairly old debate but it is well-understood
>>> that such solutions do not scale well and the major bottleneck is not 
>>> just the path computation itself but the bulk of data
>>> that must be exchanged, synchronization issues, failures during
>>> reoptimization and so on.

Indeed, the path computation bottle-neck is clearly an algorithmic
issue that is out of scope here, and I know some would argue that
solutions exist that remove that bottle-neck.

I think that the other items listed would valuably be the subject of
health warnings in an applicability statement as JP suggests, but it
should be noted that this does not limit the applicability based on
the network size or the set of LSPs being reoptimized. Rather, it
limits the applicability to how the reoptimization is being used and
coordinated by a management plane.

The difference between a global reoptimization and a bulk re-route
are subtle. It may appear that for bulk re-route all existing
services have failed and so the worst case is that connectivity is
not restored, but in packet networks FRR may be in use, so bulk
re-route failures are significant. The applicability in *that* case
includes make-before-break to ensure no disruption to traffic.

But it is also commonly accepted that restoration or re-route after
failure has two problems. The first is system congestion which is
at least as bad as global concurrent reoptimization because each
LSP-to-be restored is the subject of a PCReq and a PCRep as well as
signaling. The second is that the sequential nature of the path
computations will almost inevitably lead to blocking.

So, while I agree that the gco draft should have a very thorough
applicability section that should highlight the potential problems,
I don't think that there should be an assumption of non-applicability
to specific networks or scenarios.

>>> Thus I'd suggest to add some applicability
>>> section to this ID that would discuss the context in which such
>>> solution would apply (e.g. network with thousands of packet LSPs
>>> (hopefully not!), optical LSPs with a few hundreds of LSPs with multi-
>>> constraints optimization problems where bandwidth fragmentation is a
>>> real issue because of a limited number of discrete bandwidth values).
>>>
>> We can add applicability section to elaborate this request. We can
>> indicate that this mechanism applies specifically to GMPLS optical 
>> networks with a few hundreds of LSPs.

I would be very concerned about that limitation.
It is great to hear that you have specific intention to apply this work
to optical networks, but I do not see anything in the I-D or what JP said
that forces us to constrain the applicability in this way.
By all means, cite optical networks with a limited number of nodes as a
good example of where you might use this technique, but otherwise, you
should structure the applicability section with regard to the potential
problems, not the dataplane technology.

>>> 2)
>>>
>>>     It is also envisioned that network operators might
>>>     require a global concurrent path computation in the event of
>>>     catastrophic network failures, where a set of TE LSPs need to
>>>     be optimally rerouted in real-time.
>>>
>>> I do not think that such model could be used for "real-time"  rerouting.
>>>
>>  I agree with you. We can remove this statement.

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

>>> 3)
>>>
>>>     The main focus of this document is to highlight the PCC-PCE
>>>     communication needs in support of a concurrent path computation 
>>> application and to define protocol extensions to
>>>     meet those needs.
>>>
>>> You may want to stress the fact that in your ID the PCC is an NMS
>>> system and this is key. Indeed, one can define models where the PCCs are 
>>> LSRs and the PCE is used to provide globally optimal
>>> solutions ... Such models suffers from drastic scalability and
>>> robustness issues.
>>
>> The PCE GCO is primarily an NMS based solution. In section 3.3
>> (Application of PCE architecture) of the current draft clearly  spells 
>> out that GCO is NMS based solution.  With GCO, a PCC has
>> to know all LSP requests, hence this cannot be a LSR.
>
> Well that could be done with PCC=LSR thanks to complex  synchronization 
> (which I'm NOT advocating of course)
> hence my comment. Could you restate in the abstract/Introduction that in 
> your proposal the PCC is indeed an NMS.

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.

>>> 4) Green field: not sure to buy this argument since as soon as
>>> the TE LSPs are set up, the network is no longer in this green
>>> field state
>>>
>>  OK.  The main use of GCO application is re-optimization of an  existing 
>> network.

Well, I would be very worried if you deleted the green-field
applicability. But I do agree that it should be put lower down the
list (although I guess it comes first in the list because it comes
first in time). And it should be rephrased, because it is not
"reoptimization" since (as JP points out) you can't reoptimize LSPs
that don't exist, and once the LSPs do exist it is not a green field.

But noting that the draft is titled "PCE Global Concurrent
Optimization" not "PCE Global Concurrent Re-optimization" I have zero
problem with the existence of this section, and I believe that
network planners will want to make use of computation servers to plan
the LSPs that they will provision in their network. This might arise
either in the green field condition or when rolling out a new
customer on top of an existing network.

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

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

This may be far more visible in networks with a low ratio of potential
LSPs per link (such as in an optical network), and far less visible in
packet networks with micro-flow LSPs.

[SNIP]

>>> 7) A word of cautious here
>>>
>>>           During a reoptimization it may be required to move a LSP
>>>           several times so as to avoid traffic disruption.  The 
>>> response message must allow indicating the path sequence
>>>           for each request.
>>
>> We all know that in some cases, traffic disruption may be avoided
>> thanks to a multi-step rerouting approach where some TE LSP may be
>> rerouted N times. This is another example where such model may have
>> significant impact on the network and even when traffic disruption
>> can be avoided, there is still an impact in term of control plane,
>> traffic shift (=> jitter) although this can be another constraint
>> taken in to account when computing the various rerouting steps. For
>> example, would you want to add a paragraph listing the drawbacks of
>> such approach (e.g. trade-off between optimization gain and network
>> impact, ....) ?
>>
>> We can add a paragraph to indicate the potential impact by this  feature.
>> By the way the trade-off is not optimization vs. network impact. It
>> is traffic disruption vs. network impact. If we want to avoid traffic 
>> disruption, we need this multiple rerouting, which is the
>> price to pay at the expense of network impact.
>
> OK let me restate my comment here: the point I was trying to make is  the 
> following: even if the set of TE LSPs can be reoptimized with no
> traffic loss for example, the need for multiple reroutes has a
> cost in term of traffic impact (jitter, ...) + control plane stress.  It 
> may be worth mentioning that aspect also, this is why 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 :-)

But I *do* think that a paragraph warning about the risks of re-routing
LSPs is valuable. It is often assumed that make-before-break is hitless,
and it is not. As JP points out, even in packet networks where the re-
route can occur between packets, there may be a momentary jitter impact
at the point of switch-over. This applies to *all* reoptimization and
re-route activities including FRR.

So obviously there is a trade-off to be highlighted and put under
policy control. Maybe only some LSPs are subject to re-routing - others
need to preserve their QoS.

And clearly, multiple "shuffling" of LSPs to make space is going to
increase the impact on the network. This means both that there should
be cost-benefit analysis of the reoptimization, and that such
reoptimization is unlikely to be a continuous process.

>>> 8) Objective functions should be moved to PCEP,
>
> I typed too fast: I indeed meant to refer to the objective function 
> draft, as agreed with Jerry since I was pushing myself for not adding
> more to PCEP.

[SNIP]

JP, are you saying that all objective function definitions should go
into the one objective function I-D? Or should that I-D define the
functions that we have in hand, create the code point registry, and
leave the definition of new objective functions for future I-Ds?

But still, the requirements for the objective functions need to stay
in the gco draft. So it is just a question of where the objective
functions are described in detail.

[SNIP]

Thanks,
Adrian

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