home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / frnetmib / frnetmib-minutes-96jun.txt < prev   
Text File  |  1996-10-07  |  5KB  |  127 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4. Minutes of the Frame Relay Service MIB Working Group June 24, June 
  5. 28, 1996
  6. 36th IETF, Montreal
  7.  
  8.  
  9. I. RFC1604: Editor: David Fowler
  10.  
  11. The following issues about RFC1604 were discussed at the working 
  12. group meeting. Some of the issues were raised on the mailing list.
  13.  
  14. 1) Can we admit that this works for switches too? 
  15. - Yes. This includes any changes required to allows R/W in the logical 
  16. port table. Since the existing objects cannot be changed, the objects will 
  17. be cloned. Maria Greene will post text to the list.
  18.  
  19. 2) The description of frPVCEndptInDiscards description is not clear 
  20. about whether bits discarded with DE are counter. 
  21. - Congestion discards are not counted. Discards due to policing are the 
  22. only ones counted.
  23.  
  24. 3) There is no description of the values for frPVCRcvdSigStatus. In 
  25. particular, deleted in unclear. 
  26. - Andy Malis will send text to the mailing list describing deleted. 
  27. Descriptions for all will be added to the document. 
  28.  
  29. 4) frPVCConnectStatusChange trap is missing a varbind. For the PVC, 
  30. there is the oper status of both directions, but only one RcvdSigStatus is 
  31. included.
  32. - A second instance of RcvdSigStatus will be added to the trap and the 
  33. description will clarify that the first one is for the low end and the 
  34. second is for the high end. 
  35.  
  36. 5) The default for ifLinkUpDownTrapEnable is implementation 
  37. specific. However, since the occurrences of the PVC trap are dependent 
  38. on the frLport (i.e. no PVC traps are sent when the frLport goes down), 
  39. the default for trap enable should be true for frLports
  40. - change the mapping for frLports to put traps on and add a 
  41. recommendation that the underlying physical layer be turned off, since 
  42. both are not required.
  43.  
  44. 6) The values for procedures are limited to network side and 
  45. bidirectional. The related counters have descriptions that include 
  46. references to user and network side procedures that are confusing.
  47. - Clarify that bidirectional means that the frLport is using both user 
  48. and network side procedures. User side counters are only valid for 
  49. bidirectional, while network side counters are always valid. Replace 
  50. noSuchName with noSuchInstance. 
  51.  
  52. 7) When an underlying T1 goes to fail/test or the frLport goes to 
  53. fail/test, the values for frPvcEndptRcvdSigStatus and 
  54. frPVCConnect[h2l|l2h]Operstatus are unclear. 
  55. - Make the following clarification: return a value of 'none' for 
  56. frPvcEndptRcvdSigStatus if the "underlying" frLport is down (either 
  57. due to LMI or DS1 failure) AND return the appropriate value for 
  58. OperStatus (inactive if the DS1 or LMI failed, testing in the testing 
  59. case). 
  60.  
  61. 8) There is no easy way to find the next available DLCI. The NMS must 
  62. getNext all the frPVCEndptTable entries for a frLport and find a free 
  63. DLCI.
  64. - Create an object like frPVCConnectIndexValue for DLCIs. 
  65.  
  66. 9) Add a ifStackTable example.
  67.  
  68. 10) Missing counters for PVCs
  69. - Add InDiscardsDESet.
  70. - Add In/OutBECN, In/OutFECN. In counters are only for NNI while 
  71. Out counters are for NNI and DTE. Dave to post object text to list.
  72.  
  73. 11) There are no names for PVCs.
  74. - Add 2 new name: Service Provider Name (read/write, read/only 
  75. minimum) and Service User Name (read/write). Dave to post object text 
  76. to list.
  77.  
  78. 12) Alternate PVC Configurations:
  79. The current MIB does not allow an endpoint to have more than one 
  80. configuration. Therefore, a user cannot more than one configuration for a 
  81. pair of endpoints. For service level management, it is quite likely that 
  82. there is different speeds for different times of the day, or for disaster 
  83. recovery. 
  84. - A new MIB module in a new document will be created. Dave will post 
  85. the text to the list. The new MIB module will allow many combinations 
  86. of cir/bc/be for PVCs. The last active combination will be stored in the 
  87. frPVCEndptTable. 
  88.  
  89. II. Frame Relay/ATM Interworking:
  90.  
  91. The working group agreed that interworking will be restricted to the 
  92. modeling of FRF.8 type connections. A previous attempt to model 
  93. FR/ATM connections and James will post this to the list for information 
  94. purposes.
  95.  
  96. Arian Yair has a proprietary implementation which he shared with 
  97. the group. The table kept the FR endpoint always on one side and the 
  98. ATM endpoint always on the other. A new separate connection table 
  99. indexed by ifIndex (FR), DLCI, ifIndex(ATM), VPI, VCI will be created 
  100. that contains the traffic descriptors and status values.
  101.  
  102. Point to multipoint connections were mentioned but no discussion 
  103. resulted.
  104.  
  105. III. Accounting
  106.  
  107. The working group decided to use the framework created by the 
  108. atommib working group. Billing parameters will be discussed on the 
  109. mailing list. The existing accounting group in RFC1604 requires 
  110. additional text to clarify it's purpose. 
  111.  
  112. IV. SVCs
  113.  
  114. An internet-draft was published by Don Cochrane that described an 
  115. extension to the FR DTE MIB for SVCs and data compression. A 
  116. presentation was given on his behalf by Adrian Orozco of Cabletron. 
  117. Don has volunteered to edit the SVC MIB. It was noted that the 
  118. proposal was similar to the atommib approach to SVCs. It was also 
  119. decided that the interworking effort would not deal with SVCs at this 
  120. time. SVCs will deal with the DTE side.
  121.  
  122. V. Misc.
  123.  
  124. The working group agreed to ask the area director for a charter change 
  125. that would allow the group to deal with data compression and voice 
  126. over frame relay. Both of these are largely DTE issues.
  127.