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

From: Igor Bryskin <[email-masked]>
Date: Mon, 18 Aug 2008 08:15:26 -0700 (PDT)

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 <[email-masked]>
To: Igor Bryskin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
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 <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
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

---

From: "Tony Li" <[email-masked]>
Date: Mon, 18 Aug 2008 12:43:27 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: Monday, August 18, 2008 8:15 AM
To: Dan Li; [email-masked]; [email-masked];
[email-masked]
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 <[email-masked]>
To: Igor Bryskin <[email-masked]>; [email-masked];
[email-masked]; [email-masked]
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 <mailto:[email-masked]>  
To: [email-masked] ; [email-masked] ;
[email-masked] ; [email-masked] 
Sent: Tuesday, August 12, 2008 4:25 AM
Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

Hi,

Cheers,
Igor

----- Original Message ----
From: Adrian Farrel <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]
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

---

From: Dan Li <[email-masked]>
Date: Wed, 20 Aug 2008 11:15:53 +0800

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' ; [email-masked] ; [email-masked] ; [email-masked] 
  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: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Bryskin
    Sent: Monday, August 18, 2008 8:15 AM
    To: Dan Li; [email-masked]; [email-masked]; [email-masked]
    Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

    Dan,

    Igor

    ----- Original Message ----
    From: Dan Li <[email-masked]>
    To: Igor Bryskin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
    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: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
      Sent: Tuesday, August 12, 2008 4:25 AM
      Subject: Re: Comments on 'draft-li-ccamp-wson-igp-eval-01.txt'

      Hi,

      Cheers,
      Igor

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

      Hi,

         

        Cheers,
        Adrian

---

From: "Tony Li" <[email-masked]>
Date: Tue, 19 Aug 2008 22:22:49 -0700

Hi Dan,

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. 

True.  However, typically the number of TE LSPs that are established is a
static number.  Even in extreme cases, folks typically use O(n^2) LSPs to
form a complete mesh of their nodes.
 
In the applications that I think that you're contemplating, there are many
more links, with the ability of end users to set up their own links
throughout the network.  Please correct me if I'm misunderstanding.

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. 

Effectively rate limiting the link state database flooding, which is the
goal.

 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. 

The former is more difficult in IS-IS, as TE information is typically
distributed as part of the same LSP that carries the physical link
information.  Separate protocol instances is of course possible, but it
would seem like it would become more of a manageability issue (do you need
identical topologies?) and would not obviate the need for CPU cycles.

 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). 

I'm not sure that I would characterize it as 'crucial'.  It would seem like
there is always going to be *some* window where remote nodes have imperfect
information, just due to speed of light delays.  Ergo, the head end must
always be prepared for its path to be rejected during setup and then
recompute the path based on new information.

 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). 

Note that crankback (recomputing the path DURING setup) is not always
necessary.  Sometimes recomputation at the head end will suffice.

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. 

In my experience nearly static LSPs are perfectly acceptable, and setup time
is not an issue.  ;-)
 
My concern however is simpler: limiting the rate of link state database
flooding.  This is vital to ensure the stability of the IGP.
 
Regards,
Tony

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Aug 2008 11:01:05 +0100

Hi Tony,

(and by the way, welcome to CCAMP)

> throughout the network.  Please correct me if I'm misunderstanding.

I think there is some misunderstanding here.
It is true that in a private lambda model, the end-user may request the 
establishment of the LSP (where the end-user might be a packet network), but 
I don't think we should assume that the connectivity is worse than that in a 
TE network. Indeed, it is likely to be much less. This is in part due to the 
expense of equipment, the topology of the network, and the constraint of the 
number of lambdas supported on any link. That means that a single PE will 
only connect to a realtively small number of other PEs.

Of course, this may vary in time as technology improves and as networks get 
larger and have greater use.

> identical topologies?) and would not obviate the need for CPU cycles.

Yes. The Gen-App work in IS-IS is specifically to address this issue, I 
believe. CPU cycles will remain an issue for everyone. But if you build a 
box for a specific environment, you had better buiold a big enough box!

> recompute the path based on new information.

Absolutely.

And the signaling protocols are specifically designed to handle this case.

Nevertheless, for customer experience (TM) we would hope to make this window 
relatively small.

And, indeed, the debate lower down the email is really about how likely we 
are to fall through the window. If it happens for every LSP setup attempt, 
something clearly needs to be done in the protocols. If it happens less than 
1% and only in really busy networks, this may be acceptable.

> necessary.  Sometimes recomputation at the head end will suffice.

Yes. It all depends on whether the TED has converged in the mean time. If 
so, then reporting the failure and triggering recomputation is needed. If 
not (or if you can't be sure) it is best to recompute with the knowledge of 
which link caused the failure in the original setup. That's crankback (RFC 
4920).

> In my experience nearly static LSPs are perfectly acceptable, and setup 

Exactly.

What we find at the moment, however, is that there is a lot of discussion 
about moving the transport network from a "nearly static" animal to 
something that is semi-dynamic, or even "on-demand".

This changes the boundaries, but it is still not clear to me that 
"on-demand" means sub-second as I would expect all lambda LSPs to go through 
a testing phase before being put in service (even if this is an automatic 
phase). And I would expect such a phase to take a number of seconds.

That said, restoration is a different question.

> flooding.  This is vital to ensure the stability of the IGP.

Agreed, but let's be careful to understand the size of the network, the 
amount of information, and the rate of change of that information. This is 
really what Dan's I-D is starting to look at, so contributions to helping 
with that understanding are welcome.

If, as you say, most of these LSPs are nearly static, we obviously don't 
have to worry about the amount of flooding. It is only when LSPs come and go 
(or when nodes/links come and go) that we will see a change in flooding. I 
think that what Dan said in this email points out that the amount of 
flooding (but not necessarily the amount of information flooded) is similar 
to what we already see in TE networks. We should certainly look to see what 
the stability experience is with those networks - my understanding is that 
they are deployed and functional.

Cheers,
Adrian