To: James Fulop who wrote (10622 ) 3/11/2001 1:38:44 PM From: Frank A. Coluccio Read Replies (1) | Respond to of 12623 James, some clarifications you requested in your last two replies to me. re: POS, yes, I was referring to Packet over SONET. I seldom use the other pos term in my posts ;) and re: trading, I did not intend to use the term "trading" to connote a brokered transaction as in bid-ask, but that is also beginning to happen now, albeit slowly. When I used the term "trading" I meant the traditional forms of "hand off" that occur from one carrier to another, as in when an interexchange carrier hands off to (it's actually a two-way deal, therefore, trading, with) a local exchange carrier. Or, when one ISP hands off to another in a transit or peering sense. Thanks for the TLAB links. Yes, I guess I was getting a bit ahead of myself there. On that note, one thing that the startups enjoy that the NT/LU/TLABs don't in this regard, is the tonnage, as in impressively large amount of weight, of legacy code that the latter breed must contend with in their OAM/P and OSS systems and overall architectural workings. Having to maintain backwards compatibility from a software perspective, as well as meeting carrier productization (services definitions) objectives that were predicated on a slower carrier-centric model, hampers the larger players in ways that the more recent optical players don't really need to contend with, unless they are vying for the same space. To explain what I mean by the same space, here I'm referring to dropping in one of the newer optical boxes into the old architecture. I.e., where they would receive instructions to create path maps, and where their peering elements were of the older generation, that sit in wait for a specific point in time for invocation. Or, where they are used to restore networks when a link fails, say. In the more conventional all-electronic digital cross-connects (and even those with optical interfaces) in many cases the path creation/restoration times are painfully slow, sometimes taking up to several hours or more to complete. A part of this has to do with the time required to do network surveillance and data collection, which are things that need to take place throughout the network if a new configuration is to be assured during re-maps. In contrast, today's network elements are equipped to be "network aware" at all times. But those older networks are operating (i.e., the speeds of executing route changes were gated) at speeds that were never intended to be lightspeed in nature, consequently far slower, although they were deemed acceptable (actually, they at one time represented a revolutionary improvement at a time when routes were patched manually, or through cross-bar switching) up until now. FWIW. FAC