Subject: [RAM] Re: Impending publication: draft-iab-raws-report-01.txt

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Mar 2007 17:52:08 +0200 (EET)

On Wed, 7 Mar 2007, Leslie Daigle wrote:
> The IAB is ready to ask the RFC-Editor to publish
>
>        Report from the IAB Workshop on Routing and Addressing
>                      draft-iab-raws-report-01.txt
...
> Please direct any comments to improve the clarity of
> the report to the IAB ([email-masked]) by April 4, 2007.

Comments below.

substantial
-----------

Section 3.1.1 (Traffic Engineering)

    BGP and the common IGPs (OSPF, IS-IS) provide few tools for traffic
    engineering, so network operators usually achieve traffic engineering
    by "tweaking" the processing of routing protocols to achieve desired
    results. ...

==> This is not quite right as written.  Both OSPF and IS-IS have TE
extensions (OSPF even multiple ones AFAIR).  It's not clear how TE 
extensions of IGPs help here so removing that part might clarify that 
part of this.  It might also be arguable if BGP really provides only 
'few tools for TE', given that people are using it in numerous ways 
today (e.g., AS-path prepending, de-aggregation, NOPEER and NOEXPORT 
communities, your upstreams' communities which control the route 
propagation properties and preferences). Maybe you were referring to 
(some vaguely defined) 'explicit' TE tools which would have been 
included in the protocol just for TE in mind?

3.2.  IPv6 and its potential impact on routing table size

    Due to the increased IPv6 address size over IPv4, a full immediate
    transition to IPv6 is estimated to lead to the RIB and FIB sizes
    increasing by a factor of about four.  he size of the routing table
    based on a more realistic assumption, that of parallel IPv4 and IPv6
    routing for many years, is less clear.

==> I wouldn't go as far as to imply that the first sentence is clear, at
the very least it requires a reference.  Are you referring to the amount of
memory required or the number of entries?  Nonetheless I have trouble
understanding this figure even if the current TE patterns persisted in the
hypothetical full immediate transition to IPv6, given that ISPs and sites
have a much smaller number of prefixes as with IPv4.

4.1.1.  DRAM

    In routers, DRAM is used for storing the RIB and, in lower end
    routers, is also used for storing the FIB.

==> here and elsewhere in the draft the assumption seems to be that a high-end
router cannot be built using DRAM.  A recent presention by John Scudder in
Apricot seems to indicate that this is possible though.  While this may have
been the conclusion in the workshop, a better wording might be more useful
(e.g., examining whether the documents conclusions still hold even if DRAM
was being used; toning down the language of off-chip SRAM necessity).

7.2.3 TE and IP overload

    On the surface, traffic engineering induced prefix de-aggregation
    seems orthogonal to the locator-identifier overloading problem.
    However this may not necessarily be true.  Had all the IP prefixes
    been topologically aggregatable to start with, it would make re-
    aggregation possible or easier, when the finer granularity prefix
    announcements propagate further away from their origins.

==> I do not see how this conclusion is supported.  If a customer uses PI,
the advertisement _requires_ a DFZ slot.  If a customer uses a subset of PA
aggregate, a DFZ slot is not strictly required if the user doesn't wish to
do TE.  But if the customer wants to do TE, at least some TE slot is needed. 
So, given the assumption that we can't do away with TE, I don't see how
topologically aggregatable would change the result.

7.3.  Routing Convergence

==> Sections 7.1 and 7.2 were titled 'Problem [12]: ...', yet this one and
the ones that follow aren't.  Somewhat similar in 2.1-2.3.  Were routing
convergence (and the following sections) identified as problems or not?
Some clarification to the titles and the text might be helpful.

editorial
---------

The document still has a number of '[Editor's note: ...]' paragraphs.  Are
these intended to be removed prior to publication or reworded somehow?

4.5.  Summary

    Given the uncontrolled nature of it's growth rate, there is some

==> s/it's/its/

7.2.1.  Definition of Locator and Identifier

    Roughly speaking, the Internet comprises a transit backbone network
    and a large number of customer networks containing hosts that are
    attached to the backbone.  Viewing the Internet as a graph, transit
    networks have branches and customer networks with hosts hang at the
    edges as leaves.

==> in the first sentence, 'a transit backbone network' might be misleading. 
A better way would be to say 'a large number of transit networks' or even
'thousands of transit networks' (applying Geoff's data and assuming transit
network is one that provides transit to another AS number).

   From an ISP's viewpoint, identifiers identify customer networks and
    customer hosts.  Note that the word identifier used here is
    definedEin the contextEof the Internet routing system;

==> something strange in the second sentence ('E' * 2)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Tony Li <[email-masked]>
Date: Sun, 18 Mar 2007 17:45:08 +0100

Pekka,

> extensions of IGPs help here so removing that part might clarify  
> that part of this.  It might also be arguable if BGP really  
> provides only 'few tools for TE', given that people are using it in  
> numerous ways today (e.g., AS-path prepending, de-aggregation,  
> NOPEER and NOEXPORT communities, your upstreams' communities which  
> control the route propagation properties and preferences). Maybe  
> you were referring to (some vaguely defined) 'explicit' TE tools  
> which would have been included in the protocol just for TE in mind?

Perhaps a fix would be to describe it as "few tools for inter-domain  
traffic engineering".

> memory required or the number of entries?

I believe it refers to the size of the entry.

> Nonetheless I have trouble
> have a much smaller number of prefixes as with IPv4

The comment stipulates a "full" transition to IPv6.  While that might  
decrease the number of prefixes somewhat, one would still expect  
there to be an interestingly sized FIB and RIB.  A lot of the really  
depends on address allocation policies and the actual address  
uptake.  In a full transition where all sites get a PI prefix, I  
think that the number quoted above is extremely conservative, perhaps  
laughably so.

> Apricot seems to indicate that this is possible though.

It should be noted that John's presentation points to the use of  
RLDRAM.  This is not your garden variety, consumer electronics store,  
stuff it in your PC yourself DRAM.

> While this may have

A more specific phrasing, such as "commodity DRAM" would make the  
document more accurate.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 18 Mar 2007 15:42:12 -0700

Thanks for the comments, Pekka!
(I was worried that none would come before the deadline:)

On Mar 18, 2007, at 8:52 AM, Pekka Savola wrote:

> ......

Looks like we can just take Tony's suggested fix here.

> have a much smaller number of prefixes as with IPv4.

Read all the exchanges I saw so far. I agree that those "non- 
contiguous prefixes" from historical/legacy allocations are an issue  
today (e.g. UCLA has 5 or 6 prefixes)   and a "clean slate  
allocation :)" of IPv6 addresses could help here.
However,
- our measurements have also shown that recently allocated
   IP blocks got fragmented as well (and the trend is increasing).
- you surely know all these requests for PI prefixes...
   (I have not heard anyone who prefers PA to PI)

> was being used; toning down the language of off-chip SRAM necessity).

again Tony's suggestion of "commodity DRAM" seems clarifying the  
concern here?

> do TE.  But if the customer wants to do TE, at least some TE slot  
> is needed. So, given the assumption that we can't do away with TE,  
> I don't see how

do you see topologically aggregatable prefixes would have a better  
chance of re-aggregation?
(I know there may be other subtle issues here but lets not go there)

> Some clarification to the titles and the text might be helpful.

To strive for a faithful report of the workshop outcome, Section 7.3  
ends with the following paragraph:

     The workshop participants hold different views regarding (1)
     the severity of the routing convergence problem; and (2)
     whether it is an architectural problem, or an implementation
     issue. However, people generally agree that if we solve the
     routing scalability problem, that will certainly help reduce
     the convergence delay or make the problem a much easier one
     to handle because of the reduced number of routes to process.

Isn't this clear enough to answer your question above?
If not, any suggestions of how to revise it?

> editorial

We'll make sure to fix all the editorial issues you pointed. and Many  
thanks for this!

Lixia

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Mar 2007 01:28:54 +0100

> stuff it in your PC yourself DRAM.
Perhaps not stuffed in a PC for CPU memory, but stuffed in a video card 
doesn't seem far-fetched.

Googling...

http://www.ausmedia.com.au/HC3000%20_mitsubishi.html

"Mitsubishi HC3000 Home Theatre Projector" (street price $1695)

"High-Speed LVDS (low-voltage differential signals)
Equipped with high-speed memory (RLDRAM) increases data transmission
efficiency and high-speed LVDS drive to produce a high caliber gradation
for a clean and clear image."

In any case, I think we need to decide whether this document is about 
accurately recording what was said at the workshop, or trying to make 
all statements in the document accurate upon wider review. Which is it?

- Mark

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 18 Mar 2007 22:03:34 -0700

Lixia,

[clipped...]

> again Tony's suggestion of "commodity DRAM" seems clarifying the  

I do not think Tony's suggestion is sufficient. The document
needs to clearly spell out the implications of using RLDRAM
instead of DRAM. Specifically, whether the document conclusions
still hold even if one uses RLDRAM.

Yakov.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 19 Mar 2007 16:14:45 +1100

>still hold even if one uses RLDRAM.

At some point this exercise ceases to be a report on the workshop and 
becomes something different. I don't recall any substantive 
discussion during the workshop on the implications of  using RLDRAM 
in preference to DRAM.

regards,

    Geoff

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Mar 2007 06:25:56 +0100

> still hold even if one uses RLDRAM.

Yakov,

The implications of RLDRAM depend very much on the price history and  
long-term scalability of that particular technology in terms of  
latency and capacity.  I'm very sorry, but I don't have such data  
currently.

I hypothesize that the lower volumes of this specialized family of  
parts will take it off of the mass-market price curve and that  
Moore's law will not apply.  Hard data here that would give us a read  
on the constant-cost growth of this technology would be very  
constructive.

Regards,
Tony

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Mar 2007 09:04:52 +0100

Pekka,
> have a much smaller number of prefixes as with IPv4.

As Vince noted, there's a lot of detail behind this point that we
could get into. For parallel deployment, the report only says
that the situation is unclear. Vince's mail seemed
to indicate that the hypothetical switch-to-ipv6-only situation
would result in 100K prefixes. This seems to double the table
size (200K*4 vs. 100K*16). Is that a change that we should make,
or are there other factors that should be counted in? Note that
the parallel deployment, which Vince's and Jason's analysis
looks at is a different case.

> was being used; toning down the language of off-chip SRAM necessity).

FWIW, I got a very different picture about the router design alternatives
in Amsterdam than I have gotten since, listening to presentations like
John's or talking directly or indirectly to various hardware engineers. I
think it is important to know that there are different approaches to
building routers, and that some approaches are nearer commodity
hardware curves than others. I could take a look at the text and
suggest some changes (without changing the journalistic nature
of this report, of course).

Jari

---

From: Ross Callon <[email-masked]>
Date: Mon, 19 Mar 2007 08:39:59 -0400

>still hold even if one uses RLDRAM.

To me it seems like our understanding of the problem, and of
potential solutions, continues to evolve over time (particularly
as we look into the details more closely). As one example, I
personally was not aware of the distinction between RLDRAM
and regular DRAM when in Amsterdam, nor was this difference
discussed in Amsterdam, but I have learned about this since
returning from the workshop.

This leads to a question: To what extent is the workshop report
supposed to be an accurate description of what went on at the
workshop, and to what extent is it supposed to be an accurate
description of what we *now* feel is the problem and range of
possible solutions? I haven't sent in detailed comment on the
report because I think that it is an accurate description of what
was discussed at the time in Amsterdam, and also because I
don't think that our understanding of the problem will become
static for quite a while (so if the document needs to reflect
current improved understanding, it won't be fully stable for quite
a while).

The document's abstract states:

       This document reports the outcome of the Routing and Addressing
       Workshop which the Internet Architecture Board (IAB) held on
       October 18-19, 2006 in Amsterdam, Netherlands.
       ...
       Note that this document is a report on the proceedings of the
       workshop. The views and positions documented in this report are
       those of the workshop participants and not the IAB.

According to the first sentence of the abstract I would not expect
the document to be an accurate description of the more detailed
or more precise work that has gone on since the workshop, nor
an accurate reflection of the greater level of understanding that has
occurred since (which to me appears to still have a long way to go).
In fact, the last sentence is not quite right, since the views and
positions documented in the report are those that were stated by
workshop participants at the time, and do not necessarily reflect
the *current* views of at least some of the workshop participants.

Perhaps we should add an additional sentence to either the
abstract or to the last paragraph of section 1 that says:

       Work on issues related to this workshop report is continuing,
       and this document does not intend to accurately reflect the
       increased understanding of issues nor to discuss the range of
       potential solutions that may be the outcome of this ongoing work.

Ross

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 19 Mar 2007 09:23:29 -0400

Ross, everyone,

As has been noted by a few folks already, the purpose
of this document is strictly and uniquely to document
the discussion that occurred at the workshop.

Lixia has already provided pointers to some of the
disclaimer text in the document.

The IAB is eager to publish the workshop report for
the very reason that discussion and thinking have
clearly moved on in the intervening months. It is
time to close the workshop chapter and focus on
the subsequent ones.

Comments that help clarify the text as a representation
of what was discussed at the event will be gratefully
accepted for the document.  Everything else -- is
input to the current discussions (on RAM, RRG,
ROAP, etc).

Thanks,
Leslie.

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 19 Mar 2007 12:12:26 -0400

Clearly we need consensus on this report and where we as a collective
body do not believe the report accurate.  If it just one section then
lets fix it if people believe the entire report is bugged-out then
please say that here.  I do believe some enhancements need to be made
for clarity around the routing nomenclature and statements regarding
microprocessor deployment claims for sure, but other than that I think
the document is pretty much spot on.  

/jim 

> -----Original Message-----
> From: Ross Callon [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 8:40 AM
> To: Yakov Rekhter; Lixia Zhang
> Cc: [email-masked]; [email-masked]
> Subject: Re: [RAM] Re: Impending publication: 
> needs to 
> >clearly spell out the implications of using RLDRAM instead of DRAM. 
> >Specifically, whether the document conclusions still hold 
> even if one 
> >uses RLDRAM.
> >
> >Yakov.
> 
> potential solutions, continues to evolve over time 
> (particularly as we look into the details more closely). As 
> one example, I personally was not aware of the distinction 
> between RLDRAM and regular DRAM when in Amsterdam, nor was 
> this difference discussed in Amsterdam, but I have learned 
> about this since returning from the workshop.
> 
> This leads to a question: To what extent is the workshop 
> report supposed to be an accurate description of what went on 
> at the workshop, and to what extent is it supposed to be an 
> accurate description of what we *now* feel is the problem and 
> range of possible solutions? I haven't sent in detailed 
> comment on the report because I think that it is an accurate 
> description of what was discussed at the time in Amsterdam, 
> and also because I don't think that our understanding of the 
> problem will become static for quite a while (so if the 
> document needs to reflect current improved understanding, it 
> won't be fully stable for quite a while).
> 
> According to the first sentence of the abstract I would not 
> expect the document to be an accurate description of the more 
> detailed or more precise work that has gone on since the 
> workshop, nor an accurate reflection of the greater level of 
> understanding that has occurred since (which to me appears to 
> still have a long way to go).
> In fact, the last sentence is not quite right, since the 
> views and positions documented in the report are those that 
> were stated by workshop participants at the time, and do not 
> necessarily reflect the *current* views of at least some of 
> the workshop participants.
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 20 Mar 2007 09:52:10 +1100

>       potential solutions that may be the outcome of this ongoing work.

Adding additonal paragraphs about what a document is not tends to be 
a never-ending task! Personally I thought that the document was 
already adequately clear about its scope as a workshop report.

   Geoff

---

From: Ross Callon <[email-masked]>
Date: Tue, 20 Mar 2007 14:42:57 -0400

>time to close the workshop chapter and focus on

I understand the desire to publish the report and be done with it.

My concern has two closely related parts: One part is that the
discussions that we had in Amsterdam are in some significant
ways at odds with what I have since heard from multiple engineers
from more than one company who are actually building the devices
that the workshop was discussing. The second part of this is that
the result of this discrepancy is that the report is more alarming
than what I now believe is the reality (based on the best growth
projections that I have seen as reported on this list, and based on
what hardware engineers and software engineers tell me they are
actually building with specific time lines for delivery).

I am a little bit concerned that this might cause undue alarm among
engineers reading the report.

I am much more concerned about the admittedly less likely possibility
that this might cause concern that shows up in the popular press. I
don't want the New York Times to have a headline on their Sunday
Technology page saying "the Internet is about to fail", regardless of
whether this is true, but especially since I believe that it is not
imminently true.

This does not in any way reduce my interest in seeing people work
on the problem and come up with better solutions (if better solutions
exist that don't cause other problems), but it does mean that I want
to be careful about any publication that appears important enough
for the popular press to have some chance of picking it up.

Ross

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Mar 2007 23:07:23 +0100

Ross,

> that the workshop was discussing.

I assume that your concern is more specifically directed at my  
presentation and the subsequent discussion.  Unfortunately, the  
engineers that you're talking to haven't had the decency to discuss  
their differences of opinion directly with me and present me with any  
hard factual data to the contrary.  In fact, of all of the  
discussions that I've subsequently had, my concerns about DRAM and  
BGP convergence have only been reinforced.

> The second part of this is that

I'm having any trouble finding any conclusions in the report that are  
in any way alarming.   Perhaps if you were a bit more specific, we  
could address any text that seems to be at issue.  I stated in  
Amsterdam and have consistently maintained since that we do not have  
a short-term issue.

> whether this is true, but especially since I believe that it is not

Nor is there anyone else that I know of that believes that it is  
true.  Can you cite any language that seems to imply that there is a  
concern?  Or could even be interpreted that way?

Tony

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 21 Mar 2007 10:27:58 +0100

Tony,

On Mar 20, 2007, at 11:07 PM, Tony Li wrote:
> their differences of opinion directly with me and present me with  
> any hard factual data to the contrary.  In fact, of all of the  

I take it you're referring specifically to section 4.1.1?  In re- 
reading that I notice there's a factual error:

    In processing a
    BGP update, a BGP speaker receives a path and must compare it to all
    of the other paths it has stored for the prefix.

That's how a naive implementation might do it, but a decent  
implementation typically won't.  As I'm sure you know (but other  
readers of the report may not) there are various optimizations that  
can be done, which fall into at least two major categories.  One is  
to use of previous knowledge about the state of a given route from a  
given peer (if a peer re-advertises a route to me which was not  
previously best, and the only change to that route was that e.g.  
LocalPref got worse, then I know without any further comparisons that  
it will not become best -- when applicable this type of optimization  
can make processing of a given update O(1)).  The other is to make  
use of ordering over routes (basically, you can insertion sort routes  
for a given prefix, modulo MED).  Granted that in the end, selection  
is still O(n) in the number of paths for a given prefix, but the  
statement as quoted is not quite right.  As a meta-point, I think  
this demonstrates that back-of-envelope analysis of this particular  
issue -- even in the small -- is not straightforward and that  
intuition is not necessarily to be trusted.

(At the risk of spinning us off on a tangent, I think it's also  
important to consider the behavior of the control plane as a system  
when under load -- not just the behavior of a single CPU.  It's my  
contention that the behavior that emerges from the system when loaded  
is not as dire as one might be led to believe by examining just a  
single CPU's behavior and noticing that "the streams cross".  I hope  
to say a few words about this at tomorrows routing area meeting.)

Regarding your overall point above ("concerns about DRAM and BGP  
convergence") as relates to the workshop report, it's easy for the  
reader to completely miss it.  The workshop report (and specifically,  
section 4) dwells at length on the FIB and the claim that

    Since high end
    routing is based on low volume technology, the cost advantages that
    the bulk of the broader computing industry sees based on Moore's law
    are not directly inherited.

While the discussion of DRAM speed and access patterns as relates to  
BGP is potentially interesting, it's limited to five sentences in a  
single subsection of the report, not called out in the summary (of  
section 4, or of the overall document).  For this reason, or perhaps  
because the readers are just dense (always a possibility) the message  
actually conveyed by the report is primarily about the FIB and the  
DRAM-vs-BGP conversation hasn't risen above the background noise level.

In that context, I think Ross's comments make good sense.

--John

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Mar 2007 11:00:01 +0100

John,

> to use of previous knowledge about the state of a given route from  
> a given peer (if a peer re-advertises a route to me which was not  
> LocalPref got worse, then I know without any further comparisons  
> that it will not become best -- when applicable this type of  
> optimization can make processing of a given update O(1)).  The  
> other is to make use of ordering over routes (basically, you can  
> insertion sort routes for a given prefix, modulo MED).  Granted  
> that in the end, selection is still O(n) in the number of paths for  
> a given prefix, but the statement as quoted is not quite right.  As  
> a meta-point, I think this demonstrates that back-of-envelope  
> analysis of this particular issue -- even in the small -- is not  
> straightforward and that intuition is not necessarily to be trusted.

I'm not sure I'd call it a factual error, it's more of a  
generalization.  You're still performing the function of a  
comparison, you're just listing some of the ways in which you can  
optimize the comparison.  I wasn't getting into that level of detail  
because frankly, as it wasn't relevant to the argument.  Whatever the  
complexity of doing best path evaluation, it's still multiplied by  
the number of prefixes.  The access pattern is still unfortunately  
random, so convergence time is still going to be dominated by DRAM  
latency.

> contention that the behavior that emerges from the system when  
> loaded is not as dire as one might be led to believe by examining  
> just a single CPU's behavior and noticing that "the streams  
> cross".  I hope to say a few words about this at tomorrows routing  
> area meeting.)

No one was claiming 'dire'.

> reader to completely miss it.

Agreed.  Unfortunately, as resources are finite, there's only so much  
that one can say.

> The workshop report (and specifically, section 4) dwells at length  
> on the FIB and the claim that
>
>    Since high end
> While the discussion of DRAM speed and access patterns as relates  
> to BGP is potentially interesting, it's limited to five sentences  
> in a single subsection of the report, not called out in the summary  
> (of section 4, or of the overall document).  For this reason, or  
> perhaps because the readers are just dense (always a possibility)  
> the message actually conveyed by the report is primarily about the  
> FIB and the DRAM-vs-BGP conversation hasn't risen above the  
> background noise level.
>

Perhaps I'm being dense, but I'm still failing to see how any of that  
language could possibly induce panic.

Regards,
Tony

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 21 Mar 2007 06:05:49 -0400

Ross,

And I'm sympathetic to the desire not to make the
discussion harder by text in the workshop report.

But, this is fear, uncertainty & doubt;  to echo
one of Tony's points below, if you have specific
concerns/suggestions:  send text!

Leslie.

Tony Li wrote:
> hard factual data to the contrary.  In fact, of all of the discussions 
> that I've subsequently had, my concerns about DRAM and BGP convergence 
> have only been reinforced.
> 
> 
> I'm having any trouble finding any conclusions in the report that are in 
> any way alarming.   Perhaps if you were a bit more specific, we could 
> address any text that seems to be at issue.  I stated in Amsterdam and 
> have consistently maintained since that we do not have a short-term issue.
> 
> 
> Nor is there anyone else that I know of that believes that it is true.  
> Can you cite any language that seems to imply that there is a concern?  
> Or could even be interpreted that way?
> 
> Tony
> 
>

---

From: Ross Callon <[email-masked]>
Date: Wed, 21 Mar 2007 07:54:25 -0400

At 06:05 AM 3/21/2007 -0400, Leslie Daigle wrote:
>...to echo

a very reasonable request.

Rereading the report yet again, I think that it is quite well
written. It is somewhat of an art form to predict what external
reaction might or might not occur to any given report. However,
I think that it would probably be a good idea to add to the end
of the abstract the sentence:

       Work on issues related to this workshop report is continuing,
       and this document does not intend to reflect the increased
       understanding of issues nor to discuss the range of potential
       solutions that may be the outcome of this ongoing work.

Ross

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Mar 2007 13:09:04 +0100

>       solutions that may be the outcome of this ongoing work.

I can support that.

Tony

---

From: Loa Andersson <[email-masked]>
Date: Wed, 21 Mar 2007 13:32:34 +0100

>>       solutions that may be the outcome of this ongoing work.

sure it won't do any harm, the only problem is that it refers to a
discussion totally outside the report...

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Thu, 22 Mar 2007 05:50:55 +1100

>>       solutions that may be the outcome of this ongoing work.

ditto

   Geoff

---

From: "Chris L. Morrow" <[email-masked]>
Date: Thu, 22 Mar 2007 09:41:00 +0000 (GMT)

> No one was claiming 'dire'.

just to clarify, what is 'dire'? (not asking tony specifically more of a
survey question) is 2 years 'dire'? 5 years? 10 years?

When looking at design/build/purchase/test/deploy/depreciate timeframes of
+7 years things get 'interesting' quickly.

thanks
-Chris