Subject: la minutes

From: Ted Brunner <[email-masked]>
Date: Tue, 07 Apr 1998 12:22:36 -0700

Here is my draft of the minutes of the working group's
meeting in los angeles.  Please check it for omissions
and inaccuracies.

If you missed the meeting be sure to
look at the final section on open systems
and the inverse stack table.

Thanks.

Ted Brunner		Video and Networking Division
			Tektronix
			MS 50-490
[email-masked]	14150 SW Karl Braun
503.627.1317		Beaverton OR 97005	
		
----------------------------
41st IETF Los Angeles 

Minutes of the Interfaces MIB Working Group
April 2nd 4:14 - 6:15

(0) Agenda Bashed

There was concern from Kevin Koenig (Ascend), supported by
John Shriver (Shiva), that the interface model does not
scale well to several hundreds of interfaces.
The case of DS0 was cited.  This topic returns below.

(1) The Tunnel MIB - Dave Thayler (Microsoft)

The tunnel MIB has been developed with the support and critical oversight
of various people working on specific tunnel MIBs (eg. L2TP MIB)
and was presented in the PPP Extensions Working Group.
It was thought that the IFMIB working group would be a better
administrative home for it.

The OID subtree for the MIB is pointed to by the ifType of tunnel(131),
in the same manner as other media specific mibs.
The tunnel mib identifies further encapsulations, if any 
(eg. none, L2TP, GRE, L2F).
(Note that, as of April 6th,
IANA had not published the assignment tunnel(131) in the IANAifType module
ftp://ftp.isi.edu/mib/ianaiftype.mib)

During Dave's presentation, it was suggested that
the method of choosing the value of ifIndex be cloned from the LANE MIB.

The tunnel MIB was accepted as an official draft of the working group,
and after the suggested changes are made it can be offered as
a proposed standard.

(2) Implementation Experience with RFC2233 - Jeff Johnson (Red Back Networks)

On the list, Jeff had pointed out various editorial errors in 2233.
These had been noted by the editor.

Jeff pointed out two potential implementation problems with sparse tables.
ifIndex		ifName		ifInOctets
1		ethernet1	2356
2		serial1		-
...		...		...
257		serial256	-
258		tokenring1	5439

Gotcha 1:
In response to a getnext ifInOctets.1
the agent should not sucessively call each serial driver (1 - 256)
only to discover there is no ifInOctets.
The agent should check that ifInOctets exists for the interface
before calling the serial driver for a value.
Gotcha 2:
In response to a getnext ifInOctets.1, ifName.1
the agent, after calling the correct driver for ifInOctets,
should not use that call for ifName - and return tokenring1.

By way of explaining his implementation concerns,
Jeff described the box he worked on.
Called a subscriber management system, it accepts
parallel frame relay or parallel atm circuits from a digital subscriber
line access multiplexor (DSLAM) and creates a circuit to an outgoing
frame relay or atm circuit.

Some discussion followed, leading to an accepted interface layering model
for this box:
-multiple interface stacks (eg. ppp over atm, ppp over frame relay),
-a router with virtual interfaces and physical interfaces (atm and fr),
-and a programmable cross connect between the two.
With this model, a manageable stacking of interfaces follows,
allowing the ifStack table and the interface state to be kept
with acceptable complexity.

Discussion followed on the usefulness of the lowerLayerDown state
of ifOperStatus.  It was accepted as useful.

Discussion followed on the advisiblity of making a DS0 circuit
an interface.  Two wg members said they did not.  It was accepted
that 2233 gave sufficient leeway to implementors so that they
may make this choice.

Jeff reported that he had implemented 64bit counters and the
ifStack ifXTable.  He had not implemented write capability,
nor the ifRecvAddrTable.

(3) Implementation Experience with RFC2233 - Bob Stewart (cisco)

The correct contact person is Sandra Durham who is not yet finished.

(4) Implementation Experience with RFC2233 - Kevin Koenig (Ascend)

The implementation is 2 months away.

(5) Implementation Experience with RFC2233 - Ken White (IBM)

Ken reported that the System 390 implementation includes
64bit counters, particularly with ATM, and the ifStack table,
but not the ifRecvAddr table.

(6) Implementation Experience with RFC2233 - Joan Cucchiara (Bay)

The correct contact person is John Seligson.
Bay has implemented 64bit counters, the ifStack table
and the ifRecvAddr table.

(7) Implementation Experience with RFC2233 - Jeff Case (SNMP Research)

Jeff discussed "open systems" in which a master agent
is purchased from one vendor and several interface cards
each with a subordinate agent are purchased from other vendors.
The prime examples are multihomed Unix and NT systems.

His reasoning goes as follows:
In an open system the ifStack Table is simply not implementable.
Such systems are therefor not in compliance with RFC 1573 or 2233.
RFP writers generally quote RFC numbers, not conformance statements
within the RFC.  Given the state of the network management market,
we should be making SNMP as market friendly as possible.
In general the working group agreed.

Several options were discussed
- the hard line: ifStack table is useful and open systems are not capable,
- the softy: make ifStack table optional,
- an administrative shuffle: put ifStack in a separate RFC,
- MIB magic: write a new conformance statement.

At the same time the wg also considered an inverse stack table,
which reverses the indeces of the ifStack table,
thereby showing the interface layering from the bottom up.
It is a recurring request, and has gained more support.
As the number of interfaces increases the advantages
of supporting inverse sorting has increased,
but the cost of supporting it may increase with large
numbers of interfaces.

Several straw polls were taken to assess the feeling of the wg,
leading to a first choice and second choice for resolving this.

First choice:
-split the document as follows,
-remove the ifStack table from the current internet draft,
-the module name ifMIB remains unchanged,
-this edited text moves forward to draft standard.
-create a second internet draft with the ifStack table,
-add the inverse stack table,
-this new text moves forward to proposed standard.

Second choice:
-don't split the document.
-in the compliance module ifCompliance2, object ifStackStatus,
  change the MIN-ACCESS to not-accessible,
-edit the compliance/conformance appropriately,
-the module name ifMIB remains unchanged,
-this edited text moves forward to draft standard.
-create a second internet draft with the inverse stack table,
-this new text moves forward to proposed standard.

The working group chair took the responsibility for speaking
with the appropriate area directors to figure out whether
we progress with choice one or choice two.