NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
Andy Malis <Andy.Malis@vivacenetworks.com>
Internet Area Director(s):
Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Internet Area Advisor:
Erik Nordmark <nordmark@eng.sun.com>
Technical Advisor(s):
David Perkins <dperkins@dsperkins.com>
Mailing Lists:
General Discussion:frnetmib@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe frnetmib
Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/
Description of Working Group:
The Frame Relay Service MIB Working Group is chartered to define a set of managed objects which will be useful for customer network management of a provider's Frame Relay Service. The working group will consider existing definitions, including the Frame Relay Forum's work in this area. The objects defined by the working group will be consistent with the SNMP framework.
The working group will coordinate with both the Frame Relay Forum, the ATM MIB Working Group, and other relevant groups.
The working group is chartered to complete four tasks:
a) consider revisions to the FRS MIB (currently published as a Proposed Standard in RFC 1604) in light of implementation experience, changes to the interface MIBs (e.g. IF-MIB, DS1-MIB, DS3-MIB, FR-DTE-MIB, creation of the DS0 and DS0 Bundle MIB modules), and evolution of the relevant non-IETF standards,
b) prepare a Recommendation to the Area Director as to the appropriate disposition of the (updated) FRS MIB, i.e. that it be advanced to Draft Standard status or that it cycle at Proposed Status,
c) develop a set of managed objects to provide the instrumentation required to manage switched-virtual circuits in a frame-relay environment.
d) develop a set of managed objects to provide the instrumentation required to manage connections that terminate on a mixture of ATM and Frame Relay interfaces, i.e. interworked connections. These objects will be the minimum necessary to provide the ability to monitor and control interworked connections and shall use existing definitions (e.g. IF-MIB, FRS-MIB, ATM-MIB, etc.) to instrument the interfaces and the "native" parts of the connections.
e) develop a set of managed object for the management of Frame Relay Service Level Definitions.
f) consider other closely related future work items.
In all cases, the working group will keep the Frame Relay and ATM Forums and the ATM MIB WG informed of its progress and will actively solicit their input.
All output of the group will be consistent with the existing SNMPv2c framework and standards, including the SNMPv2c Structure of Management Information (SMI).
Goals and Milestones:
Done |
|
Post the initial Internet-Draft for discussion. |
Done |
|
Submit the Frame Relay Service MIB to the IESG for consideration as a Proposed Standard. |
Done |
|
Solicit implementation experience for the IWF and SVC cases and 'requirements' for IWF and SVC cases/ |
Done |
|
Post summary of SVC requirements, issues, and a basic proposal for the structure of the SVC instrumentation. |
Done |
|
Post first draft of RFC1604 update as an Intenet-Draft. |
Done |
|
Post IWF MIB document and SVC MIB document as Internet-Drafts. |
Done |
|
Post revised version of RFC1604 update Internet-Draft. |
Done |
|
Meet at Montreal IETF to review RFC1604 update document and develop recommendation on advancement. |
Done |
|
Submit final version of RFC1604 Internet-Draft to Area Director, requesting Directorate review. |
Done |
|
Post revisions of IWF MIB and SVC MIB as Internet-Drafts. |
Done |
|
WG Last Call for SVC MIB. |
Done |
|
Submit SVC MIB Internet-Drafts to Area Director for referral to Directorate. |
Sep 99 |
|
WG last call on IWF MIB, submit Internet Draft to IESG for publication. |
Sep 99 |
|
Post revised version of SLD draft. |
Dec 99 |
|
WG last call on SLD MIB, submit Internet Draft to IESG for publication. |
Internet-Drafts:
· Definitions of Managed Objects for Frame Relay Service
· Definitions of Managed Objects for Frame Relay Service Level Definitions
Request For Comments:
RFC |
Status |
Title |
RFC1604 |
PS |
Definitions of Managed Objects for Frame Relay Service |
Frame Relay Service MIB WG (frnetmib) Minutes
Chair: Andy Malis <Andy.Malis@vivacenetworks.com>
The frnetmib working group met Tuesday, August 1, 2000 from 1415 to 1515.
AGENDA:
1. Administrivia, current documents status
- The following two drafts have been approved by the IESG to be Proposed Standard RFCs:
draft-ietf-frnetmib-atmiwf-06.txt,
Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function, approved by IETF for PS
draft-ietf-frnetmib-frs-mib-12.txt
Definitions of Managed Objects for Frame Relay Service, approved by IETF for PS
- The following draft is in IESG review:
draft-ietf-frnetmib-mfrmib-01.txt
Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function (review due by mid-August)
2. Rob Steinberger and Orly Nicklass, Frame Relay Circuit Interface MIB
http://www.ietf.org/internet-drafts/draft-steinberger-frsi-00.txt
This MIB provides the ability to generate ifEntries for frame circuits.
The motivation is that neither RFC 2115 nor RFC 1604 create ifEntries for DLCIs. RMON requires an ifIndex to monitor a data source, so the RMON WG requested that we do this work during the Adelaide meeting.
In addition, routing MIBs (such as the CIDR Routing Table and Net to Media table) require ifIndex to control routing. Without it, you cannot control or display the routing to or on virtual circuits in a non-proprietary manner. There is not a need to create ifIndex for every circuit, but it would be nice to have one for the interesting circuits.
Rob presented the MIB structure, which has two tables, a Circuit table and an Interface Map table.
Rob noted that the MIB requires a new ifType to be allocated by IANA.
The group consensus was to continue the work and to generalize it as much as possible, including folding in ATM.
The chair will ask on the list if there are any objections to making this a WG draft.
3. Rob Steinberger and Orly Nicklass,
draft-ietf-frnetmib-frmrelay-service-01.txt, Definitions of Managed
Objects for Frame Relay Service Level Definitions
http://search.ietf.org/internet-drafts/draft-ietf-frnetmib-frmrelay-service-01.txt
Also see http://www.frforum.com/5000/Approved/FRF.13/frf13.pdf
Since this MIB has been previously presented, no introductory slides were required.
Rob went over the list of major changes and issues that went into creating -01 as a result of working group last call on -00. Several remaining open issues were discussed. Those that resulted in action items were:
On issue 4, free running counters, the following four suggestions were made:
1) Min/Max/Avg have no meaning over time. Remove them.
2) Remove ALL free running counters.
3) Use RFC 2493.
4) Add period of relevance to the Min/Max/Avg variables.
The author had incorporated choice 4, but the consensus was to go with 1 instead.
Issue 5: table fragmentation: Don't keep availability in a separate table.
The original solution was to do nothing - needs further discussion.
Ken Rehbehn didn't see why this is a separate case, and this would be confusing in the future as well.
There was no compelling case for a separate table - having one table simplifies indexing. We decided to join the tables without changing the indexing scheme.
Issue 6: Bidirectional flows:
The solution was to change the indexing scheme and modify the reference points to show remove and local reference points. This was accepted.
However, Ken also asked for an example with a picture in the method of operations section for bidirectional flow. This will be added.
No other changes to -01 were proposed in the meeting. The MIB will be updated as discussed and forwarded to the IESG as the result of WG last call.
4. Open discussion
There being none, the group adjourned.
Agenda
Frame Relay Circuit Interfaces
Open Issues from 46th IETF