Conference 7.286::fddi

Why do you want to do this?  The ring purger increases the reliability of
the ring at no cost to any conforming FDDI station.

	paul

    
    	Well,.. in theory that may be true. In
    implementation/practice/reality, it appears that we don't quite have 
    everything exactly as it should be.
     
    	The DEMFA (FDDI controller 400) engineering group requested that I 
    disable the Ring Purger from the VMS driver. I will probably not allow it 
    to be re-enabled until they figure our what the problems are. Something
    about interoperability and purging too much,.. but I'm not the expert
    on it. Ask them,.. or contact me off line.
    
    							/Bill
    

It's definitely not acceptable to have the ring purger hardwired off.
Time for some off-line discussion...

	paul

    
    	Paul,
    
    		I don't know why it wasn't discussed with you. I only
    	responded to the request from DEMFA engineering assuming that
    	they had good reason (and approval?) to ask for it to be disabled.
    
    		FWIW, I think it was determined that there were bugs in the
    	Ring Purger Algorithm.
    
    		Also, we currently have no management of the DEMFA/FDDI
    	under Phase IV,.. so whatever is there for defaults is all
    	"hard wired" pretty much. Not the best situation I know.
    
    							/Bill
    

Whatever the reasons are, customers need to configure the multivendor FDDI 
network. At this time, some vendor's FDDI gears could not afford to accomdate 
all the widest possible variation of FDDI specs. For example, so many void 
frames might eat up the station's CPU time. Its difinitely clear that those 
implementations are poor, but customer might want the interoperability and/or 
connectivity at some degree(not 100% complete) of quality among rather poor 
implementations and rather complete implemantations.

In order to let those customer who doesn't care the completeness but the 
interoperability be satified, I think our FDDI gears need to be changeable 
its parameters(duration of timers, Ring Purger diable/enable etc.).

regards,
kenji

    There are no bugs in the ring purger algorithm. 

    The reason to make the purger ON/OFF switch manageable is to allow
    users to disable the purger if other implementations have trouble with
    void frames.  In order to effectively eliminate purging in a ring, all
    DEC stations must have their purging function disabled.  The bridge and
    wiring concentrator products do (or soon will) allow management to
    control the purger ON/OFF switch.  Adapter products, however, do not
    plan to implement management of this function in the immediate future.
    Consequently, the position has been taken to change the purger switch
    default for adapters to OFF until such time as the function is
    manageable.  At that time, the default should be set back to ON.  This
    position will allow the purging function on the FDDI ring to be
    controlled even though our FDDI adapters are not yet fully manageable.

    Note that the standard clearly states that void frames should NEVER be
    copied, but some implementations do anyway, and therefore have a
    problem to workaround.  This 'problem' of implementations getting sick
    over voids is gradually getting better as DEC educates and assists
    those vendors with sick implementations - although it is a slow
    process.  Some vendors, using the DEC/MOTOROLA chipset have already
    begun using the purger as well *(it is part of our licensed CNS code )*

    (Re .2, 
    	Bill, you should allow the switch to be controlled by your
    management path when it becomes available.  )

Regards,

Dave.

    
    	Yah Dave, I stand corrected. I hope I added some disclaimer to
    	my "guess" about therte being bugs,.. the guess was wrong folks.
    	Dave has given the explanation, that being "broken" third party
    	products/implementations. And yes, Ring Purger is one of the
    	manageable thins we are working on. FWIW, we are in early
    	Alpha test and have some of the show stuff working right now
    	in my office. Hopefully we can get SET/SHOW in good shape for
    	Interop next week :-/
    
    	Which means I gotta get back to work!
    
    							/Bill
    
    
    	SP Paul Koning may take issue with the default for adapters being
    	   "off until further notice",.. but I'll let him speak 
    	  for himself

Thanks for the setup, Bill...  Anyway, given the existence of these broken
implementations, we do need to have the ability to disable.  Any non-manageable
node with ring purger enabled will get in the way of that.  So, much though
I dislike it, the default of disable is appropriate here. (The RIGHT answer,
of course, is to have management capability -- and that is being done...)

	paul

    
    	Paul,
    
    		I didn't mean to put you on the spot. I'm really just
    	trying to stay out of the middle on this one. Hope I didn't
    	rock your boat too bad.
    
    		Meanwhile, I'm working as fast as I can to provide the 
    	management capability so we can put it to rest FOREVER!
    
    						/Bill
    

    hi,
    
    With the release of DECmcc ELM T1.2.7 is this issue finally resolved ??
    
    Can the Ring Purger Flag be enabled/disabled on both FDDI Bridges and
    Concentrators or not ??
    
    Joe

| With the release of DECmcc ELM T1.2.7 is this issue finally resolved ??

    This is a firmware issue, not a host-based management issue.  DECmcc
    ELM supports the ring purger attributes, but it's up to the RBMS
    responder in the box to implement them (or not).

| Can the Ring Purger Flag be enabled/disabled on both FDDI Bridges and
| Concentrators or not ??

    The bridge and concentrator firmware developers will have to answer
    this.  I know they read this file.

    
    
    The DECbridges (RBMS Agent) support enabling/disabling the ring
    purger.  The recommended setting is to enable the ring purger. The
    factory default is enabled.
    
    John