Conference 7.286::fddi

    
    Kenji
    
    I believe the issue may be something to do with the reliability factor
    of the CON and Bridge devices. ie. the CON is relatively simple in
    function and will be easier to build with a high MTBF, while the Bridge
    is far more complicated/sophisticated in its functions and thus more
    difficult to engineer with the same level of MTBF.
    
    I don't have the MTBF figures (I heard some mentioned in a PID session and
    they were quite high) but the difference between these two devices was
    of the order of 10:1 (CON:Bridge). Any comments anyone ?
    
    The fact that a failed Bridge in a Bridge-CON setup can be swopped
    without affecting the rest of the BACKBONE should also count for
    something in any serious network design.
    
    Regards
    
    Rog 

Re: .1

Rog,
I agree with your opinion as far as a customer understand the importance of 
reliability in terms of MTBF of the node/station on a backbone.

Usually I'm flustrated with many customers who think of only the economics of 
FDDI and tend to say us that your FDDI solution is more expensive than others 
becuase you say we need CONs as well as Bridges to integrate the existing 
Ethernet.

I dont't like to discuss against those customers who never agree with our 
product/system strategy. But if we have DAS -based bridge, then I could say a 
customer "Please use our brdiges in a dual ring, but also please recognize 
that the MTBF of bridge is relatively low, that means your configuration(dual 
ring only) might be separeted more often than our proposed "tree" 
configuration using CONs."

So I think it would be better for us to have DAS bridge in terms that we 
never lose a business.


Re: .2

Peter, 50% means that the MTBF of DEFEB is 50% less than DEFCN(full config)?

Thanks replies and regards,
kenji

    kenji
    
    I have heard rumours that such issues are being considered (a DAS
    bridge), however this does contradict the statements which have been
    used in numerous PID sessions I've witnessed. ie. DEC will only
    implement the "robust" backbone SAS+CON Ring of Trees....
    
    Time will tell.
    
    Rog
    

If you look at the costs of various concentrator configurations, it should
be obvious that DAS is much more expensive than SAS, in particular, the DAS
module has only two ports that support one connection while the SAS module
provides 4 connections.  Also, DAS requires management capability.  So, for
DAS support you need more logic which will require more power and box space
and since it will cost more, will have a smaller volume and therefore have
a larger per unit cost for engineering, support, logistics, etc.  My guess
is that it would add $10K for DAS support by the time you account for
everything which means that there would be no savings.

FDDI technology is not cheap, especially when you build it to DEC product
requirements.  We learned the hard way that when you build comm products
that don't perform at the maximum speed of the link, then you're headed for
certain trouble.  We saw that with our routers and we say that with our
Ethernet controllers.  If you can find a FDDI to Ethernet bridge or router
that supports DAS at a lower network cost over a range of sizes, then one
of the following is certainly true:
	1. the product does not match DEC's product performance which will
	   result in network problems if the FDDI and Ethernet capacity is
	   actually used
	2. the product has been built with newer technology than was available
	   when DEC designed its product
	3. they have the advantage looking at, and improving on DEC's design
           as well as an established market developed by DEC�

So, the question is `how much more are they willing to pay for DAS in bridges?'
If the answer is zero, then they're obviously being unrealistic.  If the answer
is $10K, then the next obvious question is `How do you see that being cheaper
than the current combined product solution?'.  Another question would be `If
the cost of DAS was an option that increased the cost by 20%, would you buy
all DAS units, a mix, or none?'  When you get some idea of the answers, then
feed that back to FDDI product management so they can use it in planning
the next generation of FDDI products.

-----------
The value, and cost, of DEC engineering the FDDI products can't be
underestimated.  Sometimes it isn't clear whether devoting significant resources
to things like architiecture and standards pays off.  However, I think I can
point to one particular feature if the DECbridge 500 which is the result of
actions that go back about five years.  When the 802.2 standard was being
developed, the handling of different protocols by the standard was much
different than that of Ethernet, so DEC worked to modify the standard.
The modification was SNAP.  SNAP had just been approved when I attended an
ARPA Internet implementer's conference where one of the problems raised was
how to deal with 802; I suggested the `obvious' solution of using SNAP rather
than the ARPA SAP by just mapping the Ethernet protocol types to the vendor
ID of zero.�  After this was proposed as an RFC, DEC then extended the idea
further and came up with the idea of translating bridges, based on the RFC.
A new RFC is being drawn up to incorporate the model used by DEC's 10/100
bridge.  Now, DEC is not the first to offer a 10/100 bridge, but DEC is the
first to solve the problem of Ethernet packet on FDDI and other LANs in a
clean way.  That happened because DEC has a long term commitment to
communications technology.

You should also note that while others had 10/100 bridges on the market first,
they now are seen to be `non-standard'.  Will the vendor of these products
make them conform, and at what cost?

---------
�This was a spur of the moment idea.  I argued that either the Ethernet protocol
types would be or had been `grandfathered' with that ID, or they should be.
Given that ARPA had been denied representation in the relevant standards groups,
I argued that the best way to ensure that this was the case was to adopt it as
an ARPA standard.  My interest at the time was rather personal because I was
involved in development of UCX and the other proposals for handling 802 were
rather ugly, in my opinion.

Please note that MTBF figures are confidential.

	paul