Hi,
On May 10, 2007, at 4:11 PM, Young Lee wrote:
Hi J-P,
Thanks for your valuable comments and suggestions. I believe all of
your
comments and concerns have been carefully looked at and clarified.
Thanks for addressing my comments - see in line,
Please
see inline for our response.
Best Regards,
Young
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 11:00 AM
To: [email protected]
Subject: Pce Digest, Vol 33, Issue 7
Send Pce mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://www1.ietf.org/mailman/listinfo/pce
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pce digest..."
Today's Topics:
1. Comments on
draft-lee-pce-global-concurrent-optimization-03.txt (JP Vasseur)
2. Description of OpenWait state ([EMAIL PROTECTED])
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 May 2007 20:58:44 -0400
From: JP Vasseur <[EMAIL PROTECTED]>
Subject: [Pce] Comments on
draft-lee-pce-global-concurrent-optimization-03.txt
To: Young Lee <[EMAIL PROTECTED]>, LE ROUX Jean-Louis RD-CORE-LAN
<[EMAIL PROTECTED]>, Eiji Oki
<[EMAIL PROTECTED]>, Daniel King
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
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).
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.
OK Thanks.
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.
OK
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.
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.
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.
Yes, it actually depends on the topology, the traffic matrix, the
online
algorithm used, etc. We will delete this statement.
Thanks.
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?
OK. We can move this feature to a second phase.
OK Thanks.
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.
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.
as discussed.
Just for clarification, in Prague, it was agreed with Jerry and the
authors of the PCE-OF draft that all the objective functions listed
in 4657
will be defined in the PCE-OF draft provided that PCE-OF draft
would be
adopted as WG doc. It was also agreed that any new application driven
objective functions will be defined in the application draft via
the OF code
point mechanism specified in PCE-OF draft.
This includes the following Objective Functions from 4657:
Extract from 4657 section 5.1.17:
Also, the PCECP MUST support at least the following "synchronized"
objective functions:
- Minimize aggregate bandwidth consumption on all links
- Maximize the residual bandwidth on the most loaded link
- Minimize the cumulative cost of a set of diverse paths
in GCO we defined 3 OF
1 Minimize the sum of all TE LSP costs (min cost)
2 Maximize the residual bandwidth on the most loaded
link
3 Evenly allocate the network load to achieve the
most uniform link utilization across all links*
Actually function 2 is listed in 4657 and will have to be moved to
the OF
draft. Other functions (1 and 3) are not listed in 4657 and should
stay in
the GCO draft.
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.
Yes, we can accommodate your request in the new version.
Good thanks. I'll wait until you respin the ID and then will pool the
list.
JP.
Thanks.
JP.
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
End of Pce Digest, Vol 33, Issue 7
**********************************
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
