[Pce] FW: Pce Digest, Vol 33, Issue 7

[Young Lee <[e-mail]>]

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. Please
see inline for our response.

Best Regards,

Young

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Thursday, May 10, 2007 11:00 AM
To: [e-mail]
Subject: Pce Digest, Vol 33, Issue 7

Send Pce mailing list submissions to
	[e-mail]

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
	[e-mail]

You can reach the person managing the list at
	[e-mail]

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 ([e-mail])


----------------------------------------------------------------------

Message: 1
Date: Wed, 9 May 2007 20:58:44 -0400
From: JP Vasseur <[e-mail]>
Subject: [Pce] Comments on
	draft-lee-pce-global-concurrent-optimization-03.txt
To: Young Lee <[e-mail]>,	LE ROUX Jean-Louis RD-CORE-LAN
	<[e-mail]>,	Eiji Oki
	<[e-mail]>,	Daniel King
<[e-mail]>,
	[e-mail]
Message-ID: <[e-mail]>
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. 

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. 

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. 

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. 

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

8) Objective functions should be moved 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. 

Thanks.

JP.
_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce


End of Pce Digest, Vol 33, Issue 7
**********************************



_______________________________________________
Pce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pce