Subject: (FRNETMIB) Comments on draft-ietf-frnetmib-atmiwf-02.txt document

From: Sushil Pandhi <[email-masked]>
Date: Wed, 01 Sep 1999 09:50:09 -0400

Hi !

The attached text file lists the comments on the draft  FRF.8 MIB
document.   We plan to support FRF.8 Interworking function and
would like to see the changes mentioned in the attachment.

Please note that I sent this information earlier, but the attachment in
my  earlier  mail was a Microsoft WORD file, I have changed the
attachment to a text file in this document.

- Sushil

COMMENTS ON  IETF DRAFT MIB FOR FRF.8 

We plan to provide FRF.8 services on our product and would like to support the 
FRF.8 MIB.   However, we have the following four issues/comments on the draft-
ietf-frnetmib-atmiwf-02 document.

--------------------------------------------------------------------------------
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. 

------------------------------------------------------------------------------- 
Issue #2 - Oversized Frame Count : If the Fragmentation/Reassembly feature is 
disabled, the frames which are larger than the maximum frame relay size allowed 
will be dropped.   A count for the oversized frames (in both direction) when 
fragmentation/ reassembly is disabled will be useful.  The oversized frames and 
Unrecognized frames can be combined into a performance table object which can 
augment the frAtmIwfConnectionTable. 

--------------------------------------------------------------------------------
Issue #3 - Point-to-multipoint Connection: The FRF.8 Implementation Agreement 
(Aug. 14, 1995) does not mention the point-to-multipoint connections.  The 
agreement mentions (on Page 10, section 4.5) that one-to-one mapping between the 
DLCI and VPI/VCI is used for service interworking.  The draft MIB supports 
point-to-multipoint connection and explains the point-to-multipoint connection 
on page 18 and 19.  There will be no problem with the MIB supporting the 
multipoint connection, if the MIB document made it clear that the point-to-
multipoint connection support is not required per FRF.8 Implementation 
Agreement.

--------------------------------------------------------------------------------
Issue #4 Encapsulation Mapping - We think that the encapsulation mapping object 
should by default   support all mappings or the mapping mode object should have 
a value which would mean translate-all.  This will make the provisioning task 
easier for typical users.   I have already discussed this issue with Kenneth 
Rehbehn.

This is an important issue for us.