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

[JP Vasseur <[e-mail]>]

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

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