[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