Re: [EFM] Standards assumptions - was PMD considerations
Hugh,
I do not think any of us service providers expect or want the standards body
to simply "rubber stamp" EoVDSL, 100Base-Cu, or 10Base-T4. I would hope the
IEEE will define a standard that incorporates the best features of all, not
a standard that is convenient just because it happens to be identical to
somebody's existing model.
I think we are also all intelligent enough to realize that each vendor
(whether they have a "bridge" logo or a swooshy "e" logo) will be looking
out for their own best interest.
I would agree with your statement that we service providers are taking a
risk by implementing "non-standard" or "pre-standard" technology in a
real-world environment. Nonetheless, as an equipment vendor I am sure that
you have a certain appreciation for those of us who are willing to take that
risk -- whether it be a particular flavor of EFM technology or the yet-to-be
solidified MPLS standard (Which certain vendors are already "guaranteeing"
will be fully compatible with the resultant standard).
We service providers fully realize that not all technologies succeed,
however, if we wish to remain competitive, we must take "calculated risks"
and look to new technologies that not only appear to be promising but also
appear likely to succeed. We all took a risk when PCM modem technology was
first introduced - including the equipment vendors. Then the service
providers cursed the equipment vendors while the battle dragged on between
X2 and K-Flex. We all breathed a sigh of relief when V.90 was decided upon.
Fortunately for us all, the ITU had the good sense to dictate that there
should be some degree of backward compatibility between the new V.90
standard and the existing "pre-standard" technologies.
I think the V.90 experience has a great deal of relevance to the current EFM
over copper situation. A standard needs to be defined ASAP because there is
already a great deal of equipment in the field that is similar in concept
and functionality, but is not compatible. Furthermore the IEEE should show
the same good sense as the ITU in dictating that the eventual EFM standard
should provide some sort of backward compatibility for the interim period
until all equipment is upgraded to the new standard.
I think Fletcher's points are equally valid whether he purchases
pre-standard equipment from vendor E or from vendor C. I don't think it is
all that unreasonable of Fletcher to expect that his pre-standard equipment
will in some fashion be compatible with the new standard. Whether I buy from
vendor E or vendor C, I would expect them to either fit their equipment to
the new standard, or buy back my old equipment, or lose my business to
vendor XYZ.
If we look back a few years, there were a lot of ISP's and consumers who
were already using K-Flex modems and a lot who were already using X2 modems.
Nobody seemed to think back then that it was OK to tell all those consumers
with "pre-standard/non-standard" equipment that they were just SOL when the
standard was defined.
I do not mean to imply that the standards process should be driven by what
any ISP, CLEC, or ILEC is already doing in their network, but we cannot
escape the fact that there are a lot of ISP's and consumers who are already
using "pre-standard" equipment and that the longer it takes the IEEE to
define a standard, the more "pre-standard" equipment there will be out there
to contend with.
Best regards,
Bradford Martin
Ace Communications Group
----- Original Message -----
From: "Hugh Barrass" <hbarrass@xxxxxxxxx>
To: <fkittred@xxxxxxx>
Cc: <stds-802-3-efm@xxxxxxxxxxxxxxxxxx>
Sent: Tuesday, December 18, 2001 8:00 PM
Subject: [EFM] Standards assumptions - was PMD considerations
>
> Fletcher,
>
> You are making the assumption that the standard will "rubber stamp" an
existing
> product. That almost never happens - mostly because it is rarely in the
> interests of vendors to approve the standardization of a competitor's
product.
> It is much more likely that the standard will resemble an existing product
but
> will be incompatible. Many examples of this are available.
>
> So, with that said - some responses to your points:
>
> Fletcher E Kittredge wrote:
>
> > On Tue, 18 Dec 2001 14:26:29 -0800 Hugh Barrass wrote:
> > > 2. If the customer has a solution which they are deploying, what is
> > > their purpose in requesting a standards effort? It seems that they
> > > have a supplier and a product that meets their needs.
> >
> > If I understand the question, as someone in a similar solution, we
> > would like a standard because:
> >
> > 1) Our investment would be protected because we could resell the
> > equipment. Example: try selling a LAN City modem vs selling a
> > DOCSIS modem, If it is a standard piece of equipment, we can
> > depreciate over the standard 3 years. If it is proprietary
> > equipment, then we don't know that we can resell it, so it has to
> > be paid for in one year! Make that model work.
>
> When you buy it, it is proprietary. A standard made later will be
incompatible -
> you lose!
>
> (e.g. what you are buying now is a LAN City modem, prior to the DOCSIS
standard)
>
> >
> > *
> > *2) Our investment will be protected because if the vendor goes out of
> > * business, we can buy from alternate vendors.
> > *
>
> The later standard (which is supported by multiple vendors) is
incompatible -
> you lose!
>
> (if the vendor doesn't go out of business, they may decide to make a
> backward/forward compatible version. Then again they may decide to drop
the old
> version & leave you in the lurch anyway).
>
> >
> > 3) Better documentation will be available,
>
> You should buy equipment with better documentation! If you rely on a
standard
> (for a PHY) for your system documentation you will be sorely disappointed.
>
> >
> > **
> > ** 4) It will be easier to sell because customers will have been
educated
> > ** in the product,
> > **
>
> It will probably be the case that overall adoption of the technology will
> increase comfort levels. The "rising tide which raises all boats" will
help the
> pre(non)-standard product. Some products are not going to float on the
tide -
> they're already sunk...
>
> >
> > 5) Investors will understand your business,
>
> "investors" and "understanding" rarely go together :-) Pre-standard DSL
saw
> Northpoint & Rythms stock prices soar - as the standard settled the stock
sunk
> without trace...
>
> >
> > 6) We will be able to hire personnel already trained in the standard,
>
> Again, same argument as for the documentation. I hope you are not equating
PHYs
> with systems.
>
> >
> > 7) We will be able to find open source and third party software to
meter,
> > monitor and manage the equipment,
>
> You may be able to persuade your vendor to implement standard MIBs for
> pre(non)-standard equipment. However, if 2) is taken into account, you may
be
> sunk.
>
> >
> > 8) In the long run, equipment should be cheaper and more of it should
> > be sold.
> >
>
> But if you are installing equipment now (as in my example) you will not
benefot
> from this. Your more cautious competitors may benefit - to your
detriment...
>
> I don't mean to sound negative (well, actually I do!) - many system
customers
> are disappointed in this manner. You should view the standards effort as a
means
> to define the type of product that you would like to buy when the standard
is
> finished - not as a means to recover mis-spent capital on
pre(non)-standard
> equipment. Also, if a vendor tells you that their equipment is compatible
with a
> yet to be written standard - DO NOT TRUST THEM! (even if they are a big
> networking vendor with a bridge logo).
>
> Hugh.
>
>
>