Conference 7.286::fddi

>>"Require availability of a driver to support 802.3 (vs 802.2) data link 
>>layer frame type (eg. as provided for int 3COM FDDI adapter cards)."
    
    There is not, and will not be a ODI driver for the Digital FDDI
    controllers that supports the illegal "raw 802.3" frame type.  This has
    been made very clear by Novell, who have stated that they will not
    NetWare certify any ODI driver that supports frame types other than the
    ones that are defined for the given media type.  In the case of FDDI,
    the defined frame types are FDDI_SNAP and FDDI_802.2.  Period.
   
    Even without Novell's compelling business argument against supporting a
    "FDDI_RAW" frame type, we (Digital) have argued that the ETHERNET_802.3
    frame type is non-standard and that these packets (once bridged onto
    FDDI) violate the FDDI standard by not having legal LLC headers.  This
    argument is a compelling one and one which we firmly stand behind.
    
    Customers have a number of choices open to them to avoid these illegal
    FDDI frames:
    
    	1. Transition their Ethernet IPX nodes from the non-standard
    	   ETHERNET_802.3 to a standards-based ETHERNET_II or
           ETHERNET_802.2 frame type.  Note: Novell has agreed with this
    	   in principle by changing the default frame type in ODI drivers
           from ETHERNET_802.3 to ETHERNET_802.2.
    	2. Use IPX routers.  By using either a stand-alone IPX router,
           or by binding IPX to a second frame type on one or more
           NetWare servers, you can allow your ETHERNET_802.3 nodes
           to communicate with FDDI_SNAP or FDDI_802.2 nodes.
    	3. Enable the special "Raw IPX" bridging function in the Digital
    	   FDDI-Ethernet bridges.  Our bridges support an optional feature
           that allows it to convert the non-standard ETHERNET_802.3
           frames into standard FDDI_SNAP frames, and vice-versa.  This
           has the side-effect of causing ETHERNET_II IPX frames to come
           back as ETHERNET_802.3, but that situation can be prevented.
    
    I have worked this issue with many customers since I started
    development on the NetWare FDDI drivers.  I would be more than happy to
    explain to the customer the thousands of reasons why "raw 802.3"
    packets are invalid and possibly detrimental to an FDDI network.
    
    Regards,
    
    Larry Stefani
    Networks Engineering
    DTN: 226-5843

    	Is there anyone else in the market that has taken the stance that 
    Novell is flat-out wrong here? 
    
    	We seem to be intensely standards oriented (rightly so) while other
    vendors may not. IMHO, Novell should be squelched on the defense of
    "raw 802.3 mode". It smells of arrogance and is too much of a P.I.T.A.
    to accomodate.
    
    Phil

 >>  	Is there anyone else in the market that has taken the stance that 
 >>   Novell is flat-out wrong here? 
              
 >>	We seem to be intensely standards oriented (rightly so) while other
 >>   vendors may not. IMHO, Novell should be squelched on the defense of
 >>   "raw 802.3 mode". It smells of arrogance and is too much of a P.I.T.A.
 >>   to accomodate.
 
    To Novell's defense, they have taken the first step by changing the
    default frame type from ETHERNET_802.3 to ETHERNET_802.2.  Personally,
    I don't think it's enough (I'd rather see ETHERNET_802.3 frame support
    abolished entirely) but I understand their reasons for backwards
    compatibility.
    
    It seems today that the most that Digital and other vendors can do is
    to prevent a "raw IPX" frame type from being supported on anything but
    Ethernet.  Also, when we work on new NetWare customer installations,
    make the decision up front not to support ETHERNET_802.3.  Eventually
    with a little bit of education and butting up against the limitations
    of this non-standard frame type, use should die down.
    
       - Larry