Re: query on draft-ietf-iplpdn-frmib-dte-04.txt

[Fred Baker <[e-mail]>]

At 3:40 PM 5/9/95, John Shriver wrote:
>How does one uses this draft MIB (or RFC 1315) to express things like:
>
>1. Novell's model of each Frame Relay DLCI is one IPX network.

You have two choices: you can associate an ifEntry with each circuit, or
you can layer the network directly on the underlying frame relay physical
interface much as you layer IP subnets on an Ethernet interface. In a
certain IPX implementation I was involved with, we did the latter, much as
one might layer several IP subnets on one interface. Both models are
allowed for in 1573, and the latter is encouraged.

Let's not confuse the network using the interface with the interface...

>2. Cisco's implementation of "subinterfaces" on a Frame Relay
>interface, allowing multiple IP nets for various aggregations of
>DLCI's.

I would suggest that you layer the subinterface on the Frame Relay
interface, and make an attribute of the subinterface be the list of
relevant DLCIs.

>It looks like the MIB evolved in the old model of "one Frame Relay
>interface :== one network layer interface :== one SNMP interface".

No, it came rather directly from the model that one frame relay interface
correlated to one physical interface, and that some number of circuits
(perhaps SVCs) were layered on that, as in X.25. We didn't want to
externalize the DLCs to the upper layers directly, as we were concerned
that they might be ephemeral.

>The description of:
>
>    frCircuitIfIndex OBJECT-TYPE
>        SYNTAX   Index
>        MAX-ACCESS   read-only
>        STATUS   current
>        DESCRIPTION
>           "The ifIndex Value of the ifEntry this  virtual
>           circuit is layered onto."
>       ::= { frCircuitEntry 1 }
>
>only binds it to the underlying FR interface.  It doesn't provide that
>this entry may be all (or part of) an SNMP interface as seen by the
>network protocols.

Huh? Why can an IP subnet or whatever not be layered onto it? How do you
handle multiple IP subnets on the same physical Ethernet interface? Take as
a corollary an X.25 interface - you certainly don't want an ifIndex value
per virtual circuit, as the VC only exists during a call. You layer the
network layer object on the X.25 interface, and deal with VCs within the
X.25 packet layer.

>In either of these, the most "RFC 1573 way" would seem to be to have
>one SNMP "interface" for each of these DLCI's or DLCI clusters.  (Somewhat
>like the way PPP runs over RS-232.  Yeah, I don't enjoy that either.)

As I read the text you have quoted following, I would say you have it
exactly backwards. RFC 1573 "strongly recommends that connection-oriented
sub-layers do NOT have a conceptual row in the ifTable for each virtual
circuit." It mentions the assignment of ifIndex values to DLCIs as an
option, but requires that if this is done "the MIB designer must present
the rationale for this decision in the media-specific MIB's specification."
It points out that it is making this decision modelled on the use of LAN
interfaces: On an Ethernet, you don't have a network per point-to-point
relationship with LAN neighbors (you don't have an interface per
ipNetToMedia Entry) and it is unreasonable to have an interface per X.25
call open, ATM neighbor, SMDS neighbor, or Frame Relay DLC.

>Although, RFC 1573 admits:
>
>   Several of the sub-layers for which media-specific MIB modules have
>   been defined are connection oriented (e.g., Frame Relay, X.25).
>   Experience has shown that each effort to define such a MIB module
>   revisits the question of whether separate conceptual rows in the
>   ifTable are needed for each virtual circuit.  Most, if not all, of
>   these efforts to date have decided to have all virtual circuits
>   reference a single conceptual row in the ifTable.
>On the other hand, RFC 1573 says:
>
>3.2.4.  Virtual Circuits
>
>   This memo strongly recommends that connection-oriented sub-layers do
>   not have a conceptual row in the ifTable for each virtual circuit.
>   This avoids the proliferation of conceptual rows, especially those
>   which have considerable redundant information.  (Note, as a
>   comparison, that connection-less sub-layers do not have conceptual
>   rows for each remote address.)  There may, however, be circumstances
>   under which it is appropriate for a virtual circuit of a connection-
>   oriented sub-layer to have its own conceptual row in the ifTable; an
>   example of this might be PPP over an X.25 virtual circuit.  The MIB
>   in section 6 of this memo supports such circumstances.
>   If a media-specific MIB wishes to assign an entry in the ifTable to
>   each virtual circuit, the MIB designer must present the rationale for
>   this decision in the media-specific MIB's specification.
>
>
>I'm opening a can of worms, aren't I?

No, you're asking a question that we thought about long and hard and came
to the place we did for a very specific set of reasons.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
computers run on smoke, it if leaks out they won't run