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

[Dan Li <[e-mail]>]

Hi Tony, Igor,

I think we should separate two points for this discussion.

1) The amount of information advertised
The amount of information carried and the stability of that information is similar to that used in TE networks today. In those networks, when a TE LSP is set up or torn down, there is a change in the bandwidth availability on all links traversed. This causes an update to the TE information advertised in the IGP for those links.

In general, this is not seen as a critical issue. There are several possibilities to reduce the impact of TE advertisements if they become a problem. For example, as implemented in some of our current IP network, each router can impose a threshold (time and/or bandwidth delta) before which it will not re-issue an advertisement.

In networks that require IGP convergence (for IP data traffic) and TE advertisement (for MPLS-TE traffic) there is some concern that the distribution of TE information might impact the IGP convergence time. In these cases, implementations may prioritise normal LSAs ahead of opaque LSAs, or may use separate protocol instances.

Note that in WSON networks the only likely use of the IGP except for TE/RWA information is for the DCN. In this case, distinguishing the two convergence times is less of a concern.

2) Speed of convergence of wavelength availability
In a TE network, the need for an up-to-date TED depends to a good degree on the relative size of LSPs and residual bandwidth, and on the rate of arrival of new LSPs. Increasingly, core TE LSPs may be quite large, but in general, the rate of arrival of large LSPs is quite low, and the holding times are quite high.

So, the bottom line in a TE network is that when an LSP needs more bandwidth than is actually available, it is crucial that the TED is up-to-date (or "real-time" like some folks may call it).

But as Igor has pointed out, this is impossible to achieve in a distributed system. Indeed, it is impossible to achieve even in a centralised system since network failures may occur. That means that there is always a possibility that a computed path will be signaled and will fail to be established. We should be familiar with this situation in scenarios such as contention during restoration after network failure, and the signaling protocols are designed to fail and try again (usually using "crankback"  information about the failed link, but also assuming that the IGP may have converged in the mean time).

As Igor also points out, the situation in RWA is slightly more sensitive because a lambda is either there or not. Actually, this situation is just the same as the marginal bandwidth problem just desribed for TE networks. Since lambda availability information cannot be distributed instantly, there is always the chance that a computed path will fail because the lambda is not actually available. In the case of multiple points of computation, there is always the chance of contention for a lambda and so we must accept that some LSP setup attempt will fail - again, crankback and recomputation will normally ease the situation.

We can look at a couple of things:
- What is the arrival rate of lambda LSPs?
- What is the required setup time of lambda LSPs?

With the exception of restoration LSPs, I think we may say that a 5-10 second delay in LSP setup time for 1 in 50 LSPs would be acceptable, but you may have a different experience.

Regards,

Dan

  ----- Original Message ----- 
  From: Tony Li 
  To: 'Igor Bryskin' ; 'Dan Li' ; [e-mail] ; [e-mail] ; [e-mail] 
  Sent: Tuesday, August 19, 2008 3:43 AM
  Subject: RE: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'



  Igor, Dan,

  Perhaps there's an important distinction to be made here.  Typically, having an IGP carry lambda connectivity status isn't a significant issue, as that should only change when there is a significant failure.  Debouncing techniques should be used to prevent any connectivity oscillations.

  However, carrying lambda utilization status in the IGP is not going to prove practical, as the continued series of updates would easily lead to IGP thrash if done at anything approaching real-time.  Note that carrying utlization on a low-frequency basis (e.g., cycle time of 1 minute) is probably not an issue for networks of reasonable scale.  This of course won't match many folks' requirements for 'real-time'.

  Tony




----------------------------------------------------------------------------
    From: [e-mail] [mailto:[e-mail]] On Behalf Of Igor Bryskin
    Sent: Monday, August 18, 2008 8:15 AM
    To: Dan Li; [e-mail]; [e-mail]; [e-mail]
    Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'


    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