[Pce] Comments on draft-lee-pce-global-concurrent-optimization-03.txt
JP Vasseur <jvasseur@cisco.com> Thu, 10 May 2007 00:58 UTC
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlwzc-0001ix-VU; Wed, 09 May 2007 20:58:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlwzb-0001gT-A1 for pce@ietf.org; Wed, 09 May 2007 20:58:51 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlwza-0003GC-MH for pce@ietf.org; Wed, 09 May 2007 20:58:51 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2007 20:58:50 -0400
X-IronPort-AV: i="4.14,512,1170651600"; d="scan'208,217"; a="59852410:sNHT98276122"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4A0won1003246; Wed, 9 May 2007 20:58:50 -0400
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4A0wnlG000081; Thu, 10 May 2007 00:58:49 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:58:49 -0400
Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:58:47 -0400
Mime-Version: 1.0 (Apple Message framework v752.2)
To: Young Lee <ylee@huawei.com>, LE ROUX Jean-Louis RD-CORE-LAN <jeanlouis.leroux@orange-ftgroup.com>, Eiji Oki <oki.eiji@lab.ntt.co.jp>, Daniel King <daniel.king@aria-networks.com>, pce@ietf.org
Message-Id: <BE738FD5-AD83-4D78-96A0-4328D23F131E@cisco.com>
From: JP Vasseur <jvasseur@cisco.com>
Date: Wed, 09 May 2007 20:58:44 -0400
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 10 May 2007 00:58:47.0989 (UTC) FILETIME=[5DD22650:01C7929E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16401; t=1178758730; x=1179622730; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Comments=20on=20draft-lee-pce-global-concurrent-optimization- 03.txt |Sender:=20 |To:=20Young=20Lee=20<ylee@huawei.com>, =0A=20=20=20=20=20=20=20=20LE=20RO UX=20Jean-Louis=20RD-CORE-LAN=20<jeanlouis.leroux@orange-ftgroup.com>, =0A= 20=20=20=20=20=20=20=20Eiji=20Oki=20<oki.eiji@lab.ntt.co.jp>, =0A=20=20=20= 20=20=20=20=20Daniel=20King=20<daniel.king@aria-networks.com>, =20pce@ietf. org; bh=YmZ1mxbhxoOe2D8KPWBqumjR6Np2DMno9+wZ93xscJU=; b=TQgUIo4bUi8IjmVbtljUkNtfqdTDDMXWhu00g2bAGrpLg2ICey6oMVNsmN400MNNqa2cFPPY XFp5R73r+BpvpxGeitNmVhRpLI9KuFSZX6VICPfl/8iVcqby6DlM4sKo;
Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
Cc:
Subject: [Pce] Comments on draft-lee-pce-global-concurrent-optimization-03.txt
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Computation Element <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0216875676=="
Errors-To: pce-bounces@lists.ietf.org
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 Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce