Hi,
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. 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).
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.
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.
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
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.
6) A Multi-Session Indicator: I'm not exactly sure that we should
overload the machinery even more w/o more experience on how such
feature could actually help. May I suggest to potentially add it in a
second phase?
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, ....) ?
8) Objective functions should be moved to PCEP, as discussed.
9) LSP ordering is always requested by the PCC but it might be
desirable to have the PCE indicating whether ordering is in fact
required or not. For example, the NMS could send a reoptimization
request to which the PCE would reply with a ordered or non-ordered
set of computed paths.
Thanks.
JP.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
