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

[Igor Bryskin <[e-mail]>]

Dan,

That's the point. How does PCE maintain the lambda availability status? PCE architecture shyly puts this problem out of its scope, but the only known way today for the PCE is to participate in one or more IGP-TEor BGP-TE routing protocols. So, in this respect it does not matter whether paths are computed locally or via PCE service.

Igor



----- Original Message ----
From: Dan Li <[e-mail]>
To: Igor Bryskin <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Sent: Friday, August 15, 2008 1:55:04 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

 
Hi Igor,
 
You're right, when we doing the path computation, the TE link lambda 
available status should be precise and real time updated. If we do the path 
computation in distribute way, this would be a big problem because of the TE 
link lambda available status may not be updated right away. But we can do it in 
centralized way to minimized this problem. For example, using PCE and if the PCE 
can maintain the TE link lambda available status, this may not be a problem 
because all the path computation requests are in the queue of PCE, and PCE knows 
which lambda is available.
 
Regards,
 
Dan
----- Original Message ----- 
From: Igor  Bryskin 
To: [e-mail] ; [e-mail] ; [e-mail] ; [e-mail] 
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on  'draft-li-ccamp-wson-igp-eval-01.txt'

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