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

[Igor Bryskin <[e-mail]>]

Hi,

Please, see my comment in line. Look for IB>>

Cheers,
Igor



----- Original Message ----
From: Adrian Farrel <[e-mail]>
To: [e-mail]; [e-mail]; [e-mail]
Sent: Monday, August 11, 2008 1:24:50 PM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'


Hi,
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.

IB>> There is an important difference in requirements for advertising of TE link information vs. advertising TE link lambda availability. When OSPF TE speaker advertises TE link info it, apart from link statical information, is pretty much saying : "I have 70% of bandwdith availbale on priority p". For the path computer (say, PCE) it is almost always not important if the link has actually 75%, 70% or 60% of available bandwidth. However, lambda availability (like pregnancy) is boolen: either it is there ot it is not. PCE which perfoms path computation in terms of lambdas, unfortunately. must have almost momentarily lambda availability states. With the speed of TE info flooding current IGP-TE protocols have to offer, such mechanism will not work on dynamic networks. And in any case one can never rely on PCE during recovery path computations. These limitations. I think, should be clearly stated in the document.

[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.
[Adrian] Certainly, from the point of view of someone coming at this without an implementation (I used to have one :-), the concern is that adding the RWA information to the IGP might mean that there was simply too much information to be distributed. What Dan's draft is trying to do is show the dimensions of the information and how dynamic it is. From this, we can quickly see how things will scale.
I do not believe that there is an issue with the interaction with IP routing, but I guess we should consider that it is possible that the DCN will be a real IP network carrying other traffic and that we need to not disrupt IGP convergence in that network. Mechanisms exist (or are being developed) to make that safe, and Dan's I-D should be able to tell us how important it is to use them.
 
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.
[Adrian] This is an important point which you raised in conversation with me in Dublin: it is possible to consider using link-local scope flooding of RWA information from PCC to PCE so that it goes no further. But there is a clear trade-off... with how many PCCs will a PCE be required to maintain an IGP association? There is also a quesiton to be answered about the function required for restoration - how much information does the head-end LSR need to perform rapid, "best-effort" path computation to restore LSPs after a network failure? This information *does* need to be flooded. The informaiton model I-D is intended to help with this question.

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.
[Adrian] Yes. You are both right. We should treat "static" as truely static and not needing refresh. We can handle node-down and link-down events without the need to time out the LSAs containing the static data if we link the behavior to the time-out of other node/link information. But we *do* need to consider the amount of information that will be held in LSA DBs and need to be flooded at start of day and in node restart as below.

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.
[Adrian] An important point to consider (in OSPF) is what happens in a lossy environment if the LSA gets very large. In this case it will be fragmented into very many IP packets and there will be a good statistical likelihood of at least one packet being lost. That means that the LSA might never get delivered whiled the DCN will get hammered. One solution (thanks, Igor) is to break the information down into smaller LSAs. Since the information is essentially lists or matrices, this is quite easy to do.

Could you please let me know if the above is within the current scope? I believe that these are important. 
[Adrian] Very much in scope!
 
Cheers,
Adrian