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

Dan Li <> Mon, 11 August 2008 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0AAB3A6A43 for <>; Mon, 11 Aug 2008 10:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8c0s+B4Nx+dY for <>; Mon, 11 Aug 2008 10:47:21 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::62]) by (Postfix) with ESMTP id 6C4EB3A67EF for <>; Mon, 11 Aug 2008 10:47:21 -0700 (PDT)
Received: from majordom by with local (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1KSbPh-000DEC-HO for; Mon, 11 Aug 2008 17:42:37 +0000
Received: from [] ( by with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1KSbPb-000DCh-Oy for; Mon, 11 Aug 2008 17:42:35 +0000
Received: from (szxga01-in []) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Mon, 11 Aug 2008 15:33:04 +0800 (CST)
Received: from ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <> for; Mon, 11 Aug 2008 15:33:04 +0800 (CST)
Received: from l37133 ([]) by (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <> for; Mon, 11 Aug 2008 15:33:04 +0800 (CST)
Date: Mon, 11 Aug 2008 15:33:01 +0800
From: Dan Li <>
Subject: Re: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
To: "Bardalai, Snigdho" <>
Cc: "Ccamp (E-mail)" <>
Message-id: <00d701c8fb84$7c2f2b20$>
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_5PjSSN4hC0APVtmjRd4l2A)"
X-Priority: 3
X-MSMail-priority: Normal
References: <>
Precedence: bulk
List-ID: <>

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.