Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"

Dan Li <danli@huawei.com> Mon, 11 August 2008 16:33 UTC

Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9EF3A6C06 for <ietfarch-ccamp-archive@core3.amsl.com>; Mon, 11 Aug 2008 09:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.106
X-Spam-Level: **
X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQFWvlukUtAj for <ietfarch-ccamp-archive@core3.amsl.com>; Mon, 11 Aug 2008 09:33:18 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 852043A6C29 for <ccamp-archive@ietf.org>; Mon, 11 Aug 2008 09:33:17 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KSaBg-0000a0-N3 for ccamp-data@psg.com; Mon, 11 Aug 2008 16:24:04 +0000
Received: from [119.145.14.66] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <danli@huawei.com>) id 1KSaAZ-0000Lh-B2 for ccamp@ops.ietf.org; Mon, 11 Aug 2008 16:23:03 +0000
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5E007GSYDPZW@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 09:49:02 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K5E000AQYDPJ6@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 09:49:01 +0800 (CST)
Received: from l37133 ([10.70.77.57]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K5E00ED8YDP8H@szxml03-in.huawei.com> for ccamp@ops.ietf.org; Mon, 11 Aug 2008 09:49:01 +0800 (CST)
Date: Mon, 11 Aug 2008 09:48:59 +0800
From: Dan Li <danli@huawei.com>
Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
To: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>, "Ccamp (E-mail)" <ccamp@ops.ietf.org>
Message-id: <003c01c8fb54$6c656c70$394d460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
Content-type: multipart/alternative; boundary="Boundary_(ID_wtxRu+dsbOCs4s+C5Gq0CA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <A278CCD6FF152E478C3CF84E4C3BC79D03A20260@rchemx01.fnc.net.local>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

Comments on "draft-li-ccamp-wson-igp-eval-01.txt"Hi Snigdho,

I copied the original text here for easy read. See my comments below.

=====
Hi Adrian and Dan, 

I have the following comments on this draft. I was wondering what were the objectives for the IGP evaluation. IMHO the evaluation from WSON perspective should address the following:
1. IGP usage in the context of traditional distributed solutions for WSON 
[Dan] With the situation that TE information is already be carried by IGP, it's nature to think that the wavelength information can also be carried by IGP. I am not saying it should be, but it's worth to look at.
[Bardalai, Snigdho] Do you see any particular issues with using the IGP for this purpose ?
[Dan] From the result of the simulation, the OSPF convergency time takes a liitle bit longer when the entire network restarts. Because the WSON information is added in the OSPF LSA. During the network running normally, the update of wavelength availability information doesn't impact the IGP performance obviously.
 
2. IGP usage in the context of PCE solutions for WSON
[Dan] It's a potential way for PCE to get the wavelength information.
[Bardalai, Snigdho] Since the PCE is the location where path-computation takes place is it possible to limit LSA advertisements from PCC to PCE neighbors, instead of to every PCC neighbor?
[Dan] You are right, PCC which doesn't do the path-computation doesn't need this kind of information.

3. Flooding and refresh of static and dynamic link state updates
[Dan] Try to figure out the impact to the performance of IGP.
[Bardalai, Snigdho] Is it possible to limit refreshing of static LSA? Ex. using the OSPF "do not age" concept?
[Dan] Yes, it's possible to take this way to reduce the protocol traffic. But we should consider the scenario when a node gets restart or goes down, so the HELLO message may still need to be kept.

4. Data base sync-up during node restarts
[Dan] Yes, this should be considered. Especially the very large amount of data will be sent to the restarting node. We may consider the point to point data exchange instead of flooding the LSA updates. Or slice the big data packet into small pieces.
[Bardalai, Snigdho] This is little tricky, I would be interested to see if there is a clean solution.

Could you please let me know if the above is within the current scope? I believe that these are important. 
Thanks, 
Snigdho