Subject: (FRNETMIB) Issue #1 - Unrecognized Frames Count

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Wed, 1 Sep 1999 17:56:41 -0400

> Issue #1 - Unrecognized Frames Count :   This count in IETF 
> draft-01 was 
> maintained on per connection basis.   However, in the second 
> draft this count 
> has become a scalar object and represents a total of 
> unrecognized frames from 
> all the FRF.8 connections.  This scalar object belongs to an 
> error group that 
> has other objects which provide  information about the last 
> unrecognized frame 
> including the   translation error dump  (useful for trouble shooting).
> 
> 
> This new arrangement has the following problems, as we see it:
> 
> * The Unrecognized count information is not specific and 
> therefore not useful:  
> At a service provider, one Network Element (NE) will support 
> many (hundreds of) 
> FRF.8 connections and this connections will be implemented on 
> different cards in 
> the NE.   Since these connections will be from different 
> customers and on 
> different cards in the NE, one count for all the connections 
> does not provide 
> useful information for the service provider or a customer.  
> We strongly feel 
> that this count needs to be on per connection basis to be useful.  
> 
> (Secondly, if the count is per connection basis, the SNMP 
> Agent can retrieve 
> this count from the card as and when needed and provide the 
> information to the 
> manager.   If the count is for all the connection, then the 
> SNMP Agent  needs to 
> use more system resources  to gather this information from 
> each of the cards and 
> aggregate this information - and even then the  information 
> is not useful.) 
> 
> * The Translation Error Dump object for the last error is a 
> nice idea but it 
> will requires more system resources for an SNMP Agent to get 
> this information 
> from many cards in the system (NE).   Secondly, the 
> information provided by this 
> object can provide trouble-shooting help; but this seems to 
> be non-conformant 
> with the many of the IETF MIBs that do not provide for 
> objects for trouble 
> shooting.   
> 
> Summarizing, we would like the MIB to have 1) the 
> unrecognized frame count on 
> per connection basis -- one for each direction between FR and 
> ATM side and 2) no 
> error dump object.   This means : 
> * PDU translation Error Group shown in draft-02  is not needed 
> * The count for Unrecognized frames will be on a per DLCI 
> basis as in draft-01 
> except that   there will be two counts - one for each direction.  
> 
> This is an important issue for us. 
> 

My approach was to provide more information for troubleshooting what should
be a rare problem.  By expanding the breadth of information available, I
felt it was important to NOT do this for all the connections.  It is a
simple trade off.

There has been no discussion about my proposal until this equally valid
comment.  I propose reverting back to the original text unless compelling
reasons exist to retain the troubleshooting information.

Ken
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.