Comments to latest draft version 7 of the Frame Relay DTE MIB

[Alan Bartky <[e-mail]>]

Fellow Frame Relay Mibbers and Mibbettes -

This email is to comment on the latest draft to further the
effort in bringing the MIB work to closure.

I have some minor editorial comments, and comments on the latest
proposal from James at Newbridge on the ifIndex issue I raised 
previously.

As far as the ifIndex issues, it is my humble opinion that the
current MIB text and objects are fine and that the discussions
on protocol multiplexing and ifIndex can be worked on
in the future (if need be) and need not and should not
affect releasing the current draft MIB as an RFC.

*******************
Editorial comments:
*******************

1) I think it would be a good idea to add a reference to RFC 1604
(Frame Relay DCE MIB) since it has if nothing else good descriptions
on a lot of the Frame Relay functions, variables, and protocol issues
and how they are handled.

2) The second paragraph of section 4.1 is the first time the
evolution MIB is mentioned.  It needs a reference [xx]
added:

	With the extention of the interfaces MIB, it is possible to
	configure frame relay DLCs as individual interfaces and create
	ifTable entries for each.  This is not recommended and is not
	directly supported by this MIB.  Additionally, in the presence
	of demand circuits creation of individual ifEntries for each
	is not possible.

3) The text for section 4.1 is kind of a mixture between an operation
model (as the title says) and how Frame Relay relates to and gives
guidelines for operation of/with RFC 1573.  At minimum you might
want to have at least an introductory sentence or two before
the ifTable implementations guidlines table.

4) There are some places in the document that do not
conform to 80 column spacing and cause printing errors such as
line wrapping (or difficult reading on some text editors) to occur,
or have other "formatting" errors

The examples I found are:

	 ifHCInOctets     Only required when ifSpeed >= 155 Mbits/s.
	See
	                  details for ifInOctets.
	
	 ifHCOutOctets    Only required when ifSpeed >= 155 Mbits/s.
	See
	                  details for ifInOctets.
	
  
	    frErrType OBJECT-TYPE
	        SYNTAX   INTEGER    {
	                    unknownError(1),
	                    receiveShort(2),
	                    receiveLong(3),
	                    illegalAddress(4),
	                    unknownAddress(5),
	                    dlcmiProtoErr(6),
	                    dlcmiUnknownIE(7),
	                    dlcmiSequenceErr(8),
	                    dlcmiUnknownRpt(9),
	                    noErrorSinceReset(10)
	                 }
	
	    MAX-ACCESS   read-only
	    STATUS   current
	    DESCRIPTION
	"The type of error that was last seen  on  this interface:
	
	receiveShort: frame was not long enough to allow
	        demultiplexing - the address field was incomplete, or for
	        virtual circuits using Multiprotocol over Frame Relay, the protocol
	        identifier was missing or incomplete.
	
	receiveLong: frame exceeded maximum length configured for this interface.
	
	illegalAddress: address field did not match configured format.
	
	unknownAddress: frame received on a virtual circuit which was not active
	                or administratively disabled.
	
	dlcmiProtoErr: unspecified error occurred when attempting to interpret link
	                maintenance frame.
	
	dlcmiUnknownIE: link maintenance frame contained an Information Element
	                type which is not valid for the configured link maintenance
	                protocol.
	
	dlcmiSequenceErr: link maintenance frame contained a sequence number
	
	
	
	
	
	Brown & Baker                                        [Page 27]
	
	
	
	
	Draft                Frame Relay DTE MIB            April 1995
	
	
	                number other than the expected value.
	
	dlcmiUnknownRpt: link maintenance frame contained a Report Type Information
	                Element whose value was not valid for the configured
	                link maintenance protocol.
	
	noErrorSinceReset: no errors have been detected since the last
	                cold start or warm start."
	    ::= { frErrEntry 2 }
	


*************************
Comments on James' text:
*************************

> It seems to me that the only reasonable way to solve this is by layering.
> Frankly, I think that anyone who configures their box as he describes is
> worthy of their fate; they're better off with a completely point to point
> configuration in the case. But *if* they want to do this, the way to do it
> is by using the RFC 1573 stack table.
>

I have seen this case when I was working at Sync Research.  There
are cases where a customer has a large star network with Frame
Relay T1 running to multiple remote sites with different
network protocols at the different sites (i.e. complex networks
with hundreds of PVCs).

I agree that the correct solution for this involves use of the RFC 1573
stack table.
 
> Install the IP, IPX, and Bridged interfaces on generic ifEntries, associate
> other ifEntries with the DLCIs, and stack the first set on the second as
> desired.
> 
> 
>         |            |           |           |
>         |    IPX     |    IP     |   Bridge  |
>         +-----||-----+----||-----+---||------+
> 
>             ifIndex.27 ifIndex.28 ifIndex.29
> 
>                      |\    /|     /  |
>                      | \  / |    /   |
>                      |  \/  |   /    |  Stack Table Entries
>                      |  /\  |  /     |  ifStackEntry.27.10 etc.
>                      | /  \ | /      |
>                      |/    \|/       |
> 
>            ifIndex.10=  ifIndex.11=  ifIndex.12=
>                DLCI 40      DLCI 41      DLCI 42

I can see a couple of things that still need to be worked out with
this model (although it appears to be heading in the right direction).

Let's add RS-232 to the picture (it gets more complex if you
are running Frame Relay over ISDN, so let's keep the example simple
for now).

 
           |            |           |           |
           |    IPX     |    IP     |   Bridge  |
           +-----||-----+----||-----+---||------+
 
             ifIndex.27 ifIndex.28 ifIndex.29
 
                      |\    /|     /  |
                      | \  / |    /   |
                      |  \/  |   /    |  Stack Table Entries
                      |  /\  |  /     |  ifStackEntry.27.10 etc.
                      | /  \ | /      |
                      |/    \|/       |
 
            ifIndex.10=  ifIndex.11=  ifIndex.12=
                DLCI 40      DLCI 41      DLCI 42
 
                        \     |     /  
                         \    |    /   
                          \   |   /    
                           \  |  /
                            \ | / 
                             \|/
                         ifIndex.1=
                           rs-232


The issues I see with this are:

  1) There is no "generic" ifIndex type.  There is other, proprietary
     or Frame Relay.  In the above example, 27, 28 and 29 could I
     guess be proprietary multiplexing type or other (since this
     is not really proprietary, but a use of RFC1490, but there
     is no RFC1490 Multiprotocol MIB for this).

  2) At some point we need an ifIndex for the Frame Relay Management.
     I guess again that one of them could be used and the others
     could use the Logical ifIndex in the circuit table.

> 
> And we don't have to change the Frame Relay MIB to do that - nor do we have
> to change the ATM MIB when they decide to do the same thing with ATM.
> 

We (at Xylan) would obviously concur with figuring this out so
that it also would work with ATM.

> Can you imagine this with SVCs? yikes!
>

Or combined with ISDN B channels, bonding, multilink, Channelized T1,
etc., etc., etc.

The good news is this complexity keeps people like us employed ;-) !!


Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:[e-mail]
Principal Software Engineer
XYLAN Corporation                    Voice:[phone]
15707 ROCKFIELD BLVD STE 155F        FAX:  [phone]
IRVINE CA 92718-2830
**********************************************************