RE: [EFM] EFM P2MP - Discussion of higher layers
I have been watching this discussion with great interest, and everyone is
correct. I believe the market will dictate the need for a monopoly or not
and time and history gives us the clues and facts to decide. As far as the
hooks, the silicon building blocks in the forwarding plane can provide this
information to the service provider in the control plane if needed, to
protect, service, or even invade the consumer's well being. Does it really
matter if it is DCHP or PPoE? Does it really matter if it is copper or fiber
and where is the wireless crowd? Who for that matter even said Ethernet is
the win, might be the place or show no guarantees has been my experience.
Ethernet is mature and inexpensive so it may win, the copper is there, but
the bandwidth is not, and the fiber is coming and not fast enough. Even as
we debate, the content and service providers are positioning, lobbying and
litigating for their piece of the pie, I believe the feeling is that email
or web hosting is not a good enough reason (read high enough margin) to
migrate to the new paradigm. This technology touches the consumer; if you
regard the EFM as the network bit that resides from the core edge to the
consumer it needs to be more than just a new way to transport bits. What is
the compelling reason? What makes it attractive? What are the distinguishing
features? Time to market is critical, but so are products that generate
revenue. Sorry for the ramble it’s early here and my coffee is extra strong
this morning. Comments welcome.
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Fletcher E
Kittredge
Sent: Thursday, September 06, 2001 6:24 AM
To: limb@xxxxxxxxxxxx
Cc: stds-802-3-efm@ieee.org
Subject: Re: [EFM] EFM P2MP - Discussion of higher layers
On Wed, 5 Sep 2001 11:23:43 -0400 "John Limb" wrote:
> In summary, to make sure that we come up with a MAC/Phy solution that
> service providers will be able to use we need to consider the services
that
> they want to provide and make sure that if they need hooks at the lower
> layers for cost effective implementation, that we provide them.
John;
I am a Service Provider (SP.) The reason I am suddenly
investing so much time in this group is that I am convinced this
standard is really important, i.e. a standard done right is worth tens
millions of dollars to me. So oddly enough, it is worth more to
participate in an obscure standards process rather than focus on
acquiring the corpses of our former competitors, massaging key
customers or preparing for the next board meeting. We live in a
changed world, eh?
If someone comes up with a burning SP requirement that
requires a change to the MAC/Phy layer, I will argue passionately for
its inclusion. But any change to the MAC/Phy layer runs smack up
against the greatest requirement of all:
>>>>> Time To Market <<<<<
It is very late in the game for ILECs. They are far behind
and if they slip much further, there will be only one network in town:
the legacy CATV network. We are an IP over CATV provider, but if we don't
have the ILEC network to balance the CATV network, it will be a
monopoly world with all the pain and suffering associated with
monopolies.
I believe that any complication of the 802.3ah spec will
result in a longer time to reach consensus and a longer time to
produce the equipment. ILECs, and the companies like us dependent on
ILECs, need the equipment *now*.
So, you are absolutely right that to rush the spec and thereby
miss some key requirement would be a mistake causing pain for decades.
However, Ethernet has been in use for over a quarter of a century.
The requirements for systems are fairly well known. The cost of
adding additional features at the MAC/Phy layer has great cost for the
reasons above.
We need to be aware of our prejudices. I suspect I can miss
things because my background is more biased towards solutions based on
higher layer protocols. Please take what I say with a grain of salt
and correct me when I am wrong. I have a great deal at stake in the
group getting this standard right.
many thanks,
fletcher
P.S. As if you can't tell from the above, my focus is on using the
current copper network.