CURRENT_MEETING_REPORT_

Reported by Theodore Brunner/Tektronix

Minutes of the Interfaces MIB Working Group (IFMIB)



IEEE 100 Mbps LAN Standards and MIBs for Same

The two IEEE groups (802.12/100VG and 802.3UF/100baseX) are currently
each developing their own MIB within the IEEE. By the San Jose IETF they
will be ready for a BOF, and by spring the IEEE MIBs will be stable.
The group consensus is that the two technologies are different and the
two groups should be in separate working groups.


RFC 1231 - Token Ring MIB

The chair enjoined the working group to read and review the MIB, ``IEEE
802.5 MIB'' (draft-ietf-ifmib-tokenringmib-00.txt), (posted in the
Internet-Drafts directory since mid July) and post messages to the list,
prior to it being promoted out of the working group.


Token Ring Source Route MIB

This draft document was circulated on the mailing list immediately
before the IETF. (Ed:  The document has since been posted to the
Internet-Draft directories as ``IEEE 802.5 Station Source Routing MIB''
(draft-ietf-ifmib-ssr-mib)).  It is directly derived from a proprietary
MIB posted to the list.

The following editorial comments were made:  add a reference clause,
explain what the bits mean in route control, explain the syntax in route
descriptor, and add display hints if possible.

A new draft will be posted soon.


Generic Connection MIB

The document, ``Management Information Base for Management of Network
Connections'' (draft-ietf-ifmib-conntable-02.txt), has been posted in
the Internet-Drafts directories since mid-July.  The author discussed
various issues regarding its design.

A discussion evolved around the ``recursive model,'' e.g., as applied to
the ATM and Frame Relay (FR) MIB for CNM purposes, which could also be
used by the connection MIB. In it, a MIB may be used to represent a
cloud/service or a switch/constituent element.  The same objects (e.g.,
interfaces) are reinterpreted in the two representations.  For
implementation purposes an explicit model should be used for a
correlation between an object in one representation with an object in
another.  This model is not explicitly specified.  This may need to be
fixed, but not in the context of the connection MIB.

It was decided to drop the notion of a non-coordinated MIB. Both FR and
ATM can be coordinated with the addition of a pointer through the
AUGMENTS mechanism.  The X.25 MIB uses a very different model (i.e., not
Henrietta double prime) than do FR, ATM and interworking; it cannot be
coordinated.  Future MIBs can be coordinated when developed.

A clearer definition of coordinated must be introduced into the text.

It was pointed out that the MIB must spell out very clearly what an NMS
must do to manage connections, and what an NMS may do additionally to
manage connections, for both pure and interworked connections.  There is
not yet agreement within the working group on this issue.

It was decided that the connection ID space will be coalesced into a
single pool for FR, ATM and interworking.  The MIB must state this
clearly.  Similarly, the text should explicitly outlaw the (clearly
improper) duplication of ifIndex for the FR, ATM and interworked
interface space.

It was decided that the mirroring principal was a good thing for the
case of interworked connections.  With it, several rows exist to
represent the connection in the media specific MIBs, and additionally,
several rows exist to represent the connection in the interworking MIB.
The interworking MIB has a complete picture of the connection, (e.g.,
all endpoints and all connections) while the media-specific MIBs have a
picture of their media-specific portion (e.g., the endpoints).  No
decision was taken on pure connections.

There was discussion on simplifications to the connection MIB. Why is
there an endpoint table at all?  Couldn't the connection table include
pointers to the media-specific endpoint table rows?

Why does the connection table have five index variables?  It uses two
variables (e.g., LowIfIndex and LowCnID) to identify a single endpoint
table row.  It only really needs one variable.

The notion of replacing, in the connection table, integer index
variables with OID pointers was rejected (the concept was likened to a
``sucking chest wound'').  It was decided that the text should capture
the reasons behind this design choice.

The Network Management Area Director offered a suggestion to the working
group.  Since it appeared that there were some design decisions left to
make, and since in his estimation the working group had been going
around on this MIB for quite some time, he proposed the creation of a
design team to report back to the working group.  The suggestion was
accepted and volunteers experienced with the issues were called for.
Andy Malis, Ken Rodemann, and James Watt volunteered.


Connection MIB Design Team Meeting

The IFMIB Working Group's connection MIB design team met on Thursday.

The following people attend:


   o Ted Brunner
   o Ken Rodemann
   o Andy Malis
   o James Watt
   o Manu Kaycee
   o Ron Presti
   o Steve Buchko


This message was delivered from the Network Management Area Director to
the design team, by the working group chair:


   o The connection MIB was started in Spring '93, and has had
     significant meeting time in Spring '94 and Summer '94.

   o The working group is not yet unified on its model.  E.g., will
     there be an endpoint table?  What are the indexes of the connection
     table?  This creates the perception of more design work left to do.

   o The working group is not yet agreed on conformance.  E.g., which
     portions of the connection and the media-specific MIB are relevant
     under what circumstances?  Which does an application use?  This
     creates the perception that the working group has more consensus
     left to achieve.

   o The notion of ``recursive use'' expressed in this MIB, (although
     borrowed from the ATM MIB) is not yet fully understood nor modeled.
     In particular the inter-relationship between views of the same
     systems, with different ``granularities,'' is unknown.

   o The director and directorate can see only one clearly expressed use
     for this MIB: ATM to Frame Relay interworking.


Therefore the Network Management Area Director suggests that:


   o The target status for this MIB should be experimental.

   o The RFC title and text should explicitly target the ATM to Frame
     Relay case; the object names and the model should not.

   o If and when another clear use of the MIB can be expressed, it
     should be folded in.


From the design team came several comments:


   o The experimental status was ok, as long as the work didn't stay
     experimental forever.

   o The focus on ATM and Frame Relay was ok, as long as other cases
     could be done in the future.

   o Experience implementing the ATM MIB is just coming out now; there
     is no experience managing systems with it.  It may be best to learn
     more about using the media specific MIBs before designing a
     standard interworking MIB.

   o We cannot drop this work, because ATM to Frame Relay interworking
     is a requirement.


After this, the discussion turned toward design issues.  Several points
were agreed upon.

A management application that sets up connections in either the pure ATM
case, or the pure Frame Relay case, must work with no modifications on
an agent that supports Frame Relay to ATM interworking.  This is a firm
requirement.  One issue to consider is how to evolve a pure connection
into an interworked connection.  Where is the locus of control over the
connection as it evolves:  media-specific MIB or interworking MIB?

The unification of the connection MIB's number space (cnConnectcnIndex
and cnEndptCnIndexValue) with both the ATM space (atmVcCrossConnectIndex
and atmVclCrossConnectIdentifier) and with the Frame Relay space
(frPVCConnectIndex and frPVCEndptConnectIdentifier) is very important.
Implementing three separate connection numbering spaces is too messy.
To support ATM/FR interworking the ATM and FR agents have to be brought
together anyway, so this has minor impact.

The indexing of the cnConnectTable should be as the current draft 
f cnIndex, LowIfIndex, LowEndptID, HighIfIndex, HighEndptID g where the
pair f ifIndex EndptID g identify an endptTable row.  There are three
reasons:


   o The LowEndptID and HighEndptID are merely unique per interface, so
     there is no need for centralized administration of them (across all
     interfaces and across ATM, FR, and interworking)

   o One could use the DLCI or the combined VPI and VCI as the ID. They
     are unique per port.  This is a natural choice.

   o It matches the model used in the Frame Relay and ATM MIB.


The only role of cnEndPtTable is to identify the media-specific endpoint
table row (atmVclTable and frPVCEndptTable).  It does so through an OID
pointer.  The cnConnectTable identifies cnEndPtTable rows, through a set
of integer indexes shared between cnConnectTable and cnEndPtTable f
ifIndex cnID g.  The option of removing the cnEndPtTable exists.  Then
the two OID pointers would exist in the cnConnectTable, in addition to
the five index variables.  However the thought of replacing the last
four of the five index variables with two OID pointers is too horrible
to contemplate.

The case of circuit-emulation over ATM interworking and Frame Relay over
ISDN interworking were discussed.  In both cases, what is carried as
service on one endpoint (DS3 circuit-emulation, or FR frames) is
interworked with what is fabric (DS3, or Frame Relay) on the other
endpoint.  This involves a layer mismatch, but at least the interfaces
evolution MIB allows naming of all relevant layers.  Such an
interworking is more complex than ATM/FR interworking, where both
endpoints are fabric.

The draft's introduction provides the normative text of how to use the
MIB. However a cookbook of the preferred method of using the connection
MIB in common cases should be included in the MIB itself.  The ATM and
FR MIBs can be used (partially cloned) for this.

The meeting ended and the following is an outline of the connection MIB,
as the design team left it.  (I have re-named some of the objects,
hopefully an improvement in clarity.)


cnIndexValue                    Integer32

cnEndptTable INDEX {    ifIndex
                       cnEndptID }

     cnEndptID               Integer32       -DLCI / VPI<<16 + VCI
     cnEndptIndexValue       Integer32       -link to cnConnectTable
     cnEndptMediaSpecificEndptPtr   InstancePointer
     cnEndptName             DisplayString   - not required. perhaps useful.
     cnEndptRowStatus        RowStatus

cnConnectTable INDEX {  cnConnectIndex
                       cnConnectLowIfIndex
                       cnConnectLowEndptID
                       cnConnectHighIfIndex
                       cnConnectHighEndptID }

     cnConnectIndex                  Integer32
     cnConnectLowIfIndex             InterfaceIndex
     cnConnectLowEndptID             Integer32       -DLCI / VPI<<16 + VCI
     cnConnectHighIfIndex            InterfaceIndex
     cnConnectHighEndptID            Integer32       -DLCI / VPI<<16 + VCI
     cnConnectAdminStatus            INTEGER
     cnConnectL2HOperStatus          INTEGER
     cnConnectH2LOperStatus          INTEGER
     cnConnectL2HLastChange          TimeStamp
     cnConnectH2LLastChange          TimeStamp
     cnConnectDirectionFlow                         -not required? use?
     cnConnectRowStatus              RowStatus