Editor's note: These minutes have not been edited. Minutes of the Frame Relay Service MIB Working Group June 24, June 28, 1996 36th IETF, Montreal I. RFC1604: Editor: David Fowler The following issues about RFC1604 were discussed at the working group meeting. Some of the issues were raised on the mailing list. 1) Can we admit that this works for switches too? - Yes. This includes any changes required to allows R/W in the logical port table. Since the existing objects cannot be changed, the objects will be cloned. Maria Greene will post text to the list. 2) The description of frPVCEndptInDiscards description is not clear about whether bits discarded with DE are counter. - Congestion discards are not counted. Discards due to policing are the only ones counted. 3) There is no description of the values for frPVCRcvdSigStatus. In particular, deleted in unclear. - Andy Malis will send text to the mailing list describing deleted. Descriptions for all will be added to the document. 4) frPVCConnectStatusChange trap is missing a varbind. For the PVC, there is the oper status of both directions, but only one RcvdSigStatus is included. - A second instance of RcvdSigStatus will be added to the trap and the description will clarify that the first one is for the low end and the second is for the high end. 5) The default for ifLinkUpDownTrapEnable is implementation specific. However, since the occurrences of the PVC trap are dependent on the frLport (i.e. no PVC traps are sent when the frLport goes down), the default for trap enable should be true for frLports - change the mapping for frLports to put traps on and add a recommendation that the underlying physical layer be turned off, since both are not required. 6) The values for procedures are limited to network side and bidirectional. The related counters have descriptions that include references to user and network side procedures that are confusing. - Clarify that bidirectional means that the frLport is using both user and network side procedures. User side counters are only valid for bidirectional, while network side counters are always valid. Replace noSuchName with noSuchInstance. 7) When an underlying T1 goes to fail/test or the frLport goes to fail/test, the values for frPvcEndptRcvdSigStatus and frPVCConnect[h2l|l2h]Operstatus are unclear. - Make the following clarification: return a value of 'none' for frPvcEndptRcvdSigStatus if the "underlying" frLport is down (either due to LMI or DS1 failure) AND return the appropriate value for OperStatus (inactive if the DS1 or LMI failed, testing in the testing case). 8) There is no easy way to find the next available DLCI. The NMS must getNext all the frPVCEndptTable entries for a frLport and find a free DLCI. - Create an object like frPVCConnectIndexValue for DLCIs. 9) Add a ifStackTable example. 10) Missing counters for PVCs - Add InDiscardsDESet. - Add In/OutBECN, In/OutFECN. In counters are only for NNI while Out counters are for NNI and DTE. Dave to post object text to list. 11) There are no names for PVCs. - Add 2 new name: Service Provider Name (read/write, read/only minimum) and Service User Name (read/write). Dave to post object text to list. 12) Alternate PVC Configurations: The current MIB does not allow an endpoint to have more than one configuration. Therefore, a user cannot more than one configuration for a pair of endpoints. For service level management, it is quite likely that there is different speeds for different times of the day, or for disaster recovery. - A new MIB module in a new document will be created. Dave will post the text to the list. The new MIB module will allow many combinations of cir/bc/be for PVCs. The last active combination will be stored in the frPVCEndptTable. II. Frame Relay/ATM Interworking: The working group agreed that interworking will be restricted to the modeling of FRF.8 type connections. A previous attempt to model FR/ATM connections and James will post this to the list for information purposes. Arian Yair has a proprietary implementation which he shared with the group. The table kept the FR endpoint always on one side and the ATM endpoint always on the other. A new separate connection table indexed by ifIndex (FR), DLCI, ifIndex(ATM), VPI, VCI will be created that contains the traffic descriptors and status values. Point to multipoint connections were mentioned but no discussion resulted. III. Accounting The working group decided to use the framework created by the atommib working group. Billing parameters will be discussed on the mailing list. The existing accounting group in RFC1604 requires additional text to clarify it's purpose. IV. SVCs An internet-draft was published by Don Cochrane that described an extension to the FR DTE MIB for SVCs and data compression. A presentation was given on his behalf by Adrian Orozco of Cabletron. Don has volunteered to edit the SVC MIB. It was noted that the proposal was similar to the atommib approach to SVCs. It was also decided that the interworking effort would not deal with SVCs at this time. SVCs will deal with the DTE side. V. Misc. The working group agreed to ask the area director for a charter change that would allow the group to deal with data compression and voice over frame relay. Both of these are largely DTE issues.