Changes between RFC 1315 and draft version 4 Frame Relay MIB and my comments

Alan Bartky <alan@xylan.com> Thu, 03 August 1995 18:42 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20205; 3 Aug 95 14:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20201; 3 Aug 95 14:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21513; 3 Aug 95 14:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20112; 3 Aug 95 14:42 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa20105; 3 Aug 95 14:40 EDT
Received: from xylan.XYLAN.COM by CNRI.Reston.VA.US id aa21457; 3 Aug 95 14:40 EDT
Received: from omni.xylan.com by xylan.com (4.1/SMI-4.1 (xylan-mgw 1.0)) id AA01557; Thu, 3 Aug 95 11:41:12 PDT
Received: from bluejay.UUCP by omni.xylan.com (4.1/SMI-4.1 (omni 1.1)) id AA17521; Thu, 3 Aug 95 11:41:10 PDT
Received: from robin.xidc by irvine.XYLAN.COM (4.1/SMI-4.1) id AA29045; Thu, 3 Aug 95 11:20:41 PDT
Date: Thu, 3 Aug 95 11:20:41 PDT
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Bartky <alan@xylan.com>
Message-Id: <9508031820.AA29045@irvine.XYLAN.COM>
To: cbrown@wellfleet.com, cbrown@baynetworks.com, fred@cisco.com, carvallho@cisco.com
Subject: Changes between RFC 1315 and draft version 4 Frame Relay MIB and my comments
Cc: iplpdn@CNRI.Reston.VA.US, alan@xylan.com

To drafters of the next Frame Relay DTE MIB:

I have now gone through the entire draft and have summarized
the differces between the March 1995 draft (version 4) and 
RFC 1315

Major Changes between RFC1315 and current draft are:

1) Updated to SNMPv2.  Changes include
   A) Several changes from INTEGER to Integer32, COUNTER to Counter32,
   ACCESS to MAX-ACCESS
   
2) Removed dash characters '-', from value names (I assume
   this is because some MIB compilers don't like them).

3) Compliance section added.

4) Several new objects added.

5) Some values for objects were added, some were deprecated.
   (in the current draft, most were not properly deprecated)

******************
General Comments:
******************

1) It needs to be kept as much as possible with RFC 1315.  There
are several cases of objects being re-numbered, and values being
deleted/renumbered.  Use of deprecating values and/or objects
must be properly handled.

2) The RFC must be drafted in accordance to RFC1573 which states
that new MIBs must state things such as how the Interface 
MIB for this sub layer is handled (e.g. Which octects are
counted for ifInOctects).  A lot of this text and
guidelines can be borrowed from RFC 1604 (The Frame Relay
DCE MIB).

3) The MIB still refers to "Draft" ANSI standards.  I believe
many (if not all) these documents are no longer draft (Frame
Relay has been out for a while now).

*******************
Specific Comments:
*******************


Need to change:

>                    Charles Carvallho
>            Postal: Advanced Computer Communications
>                    315 Bollay Drive
>                    Santa Barbara, California 93117
>            Tel:    +1 805 685 4455
>            E-Mail: charles@acc.com"
> 

Comments: Need to change Charles Carvallho's contact information 
(no longer at ACC).  Also Wellfleet should be changed to
Bay Networks (regular and email address).

<                  ansiT1-617-D    (3),  -- ANSI T1.617 Annex D
<                  ansiT1-617-B    (4)   -- ANSI T1.617 Annex B

Was changed to :

>             ansiT1_617_D    (3),  -- ANSI T1.617 Annex D
>             ansiT1_617_B    (4),  -- ANSI T1.617 Annex B
>             ccitt_933_A     (5)   -- CCITT Q933 Annex A

'-' changed to '_' and ITU-T (CCITT) Recommendation Q.933 Annex A  added

Currently RFC 1604 has a similar object and is:

 frLportVCSigProtocol OBJECT-TYPE
     SYNTAX  INTEGER {
               none(1),
               lmi(2),
               ansiT1617D(3),
               ansiT1617B(4),
               ccittQ933A(5)
             }

Comment: I would suggest that to make it consistent between RFC 1604 and the 
current draft Frame Relay DTE MIB that the same names be used from
frLportVCSigProtocol in RFC 1604 (even though the CCITT is now 
the ITU-T, it is better to keep things consistent where possible
between the two RFCs).

frDlcmiStatus was added:

>     frDlcmiStatus OBJECT-TYPE
>         SYNTAX   INTEGER    {
>                     running      (1),    -- init complete, system running
>                     fault        (2),    -- error threshold exceeded
>                     initializing (3)     -- system start up
>                     }
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "This indicates the status of the  Frame  Relay
>            interface  as  determined by the performance of
>            the dlcmi.  If no dlcmi is running,  the  Frame
>            Relay  interface will stay in the running state
>            indefinately.  "
>        ::= { frDlcmiEntry 3 }

Comment: I have no problem with this new object, but it was added as
frDlcmiEntry 3, and should have been added at the end so as not
to change the numbers of the other frDlcmiEntry objects within the
table.  It should be changed to frDlcmiEntry 12.  This will restore 
all the other objects 3 through 11 to the original RFC 1315 order.
Also change "indefinately" to "indefinitely" (spelling).


For frDlcimAddressLen

<                      two-octets (2),
<                      three-octets (3),
<                      four-octets (4)

was changed to:

>                 twoOctets (2),
>                 threeOctets (3),
>                 fourOctets (4)

rfc 1604 has a similar object:

 frLportAddrDLCILen OBJECT-TYPE
     SYNTAX  INTEGER {
      twoOctets10Bits(1),
      threeOctets10Bits(2),
      threeOctets16Bits(3),
      fourOctets17Bits(4),
      fourOctets23Bits(5)
    }


Comment: With the widespread use of RFC1315, and the imcompatibilities
between the two sets of values, it does not make
sense to align the two sets of values.  However it
is important to at least comment on how many bits per
byte is meant in the replacement for RFC1315.  This
is important because for three octet and four octet
values there are two bit length options.


frDlcmiRowStatus was added:

> 
>     frDlcmiRowStatus OBJECT-TYPE
>         SYNTAX   RowStatus
>         MAX-ACCESS   read-write
>         STATUS   current
>         DESCRIPTION
>            "SNMP Version 2 Row Status Variable."
>        ::= { frDlcmiEntry 12 }
>

Comment:  This object should be made as frDlcmiEntry 13 (last
object).
 
Text for frCircuitState was changed:

<                 temporarily disable a given circuit."
---
>            temporarily disable a given circuit.
> 
>            The use of 'invalid' is deprecated in this SNMP
>            Version 2 MIB, in favor of frCircuitRowStatus."

The full object and text in the new draft are as follows:

   frCircuitState OBJECT-TYPE
        SYNTAX   INTEGER    {
                    invalid (1),
                    active (2),
                    inactive (3)
                 }
        MAX-ACCESS   read-write
        STATUS   current
        DESCRIPTION
           "Indicates whether the particular virtual  cir-
           cuit  is operational.  In the absence of a Data
           Link Connection Management  Interface,  virtual
           circuit  entries  (rows) may be created by set-
           ting virtual  circuit  state  to  'active',  or
           deleted by changing Circuit state to 'invalid'.

           Whether or not the row actually  disappears  is
           left  to the implementation, so this object may
           actually read as 'invalid' for  some  arbitrary
           length  of  time.   It is also legal to set the
           state of a virtual  circuit  to  'inactive'  to
           temporarily disable a given circuit.

           The use of 'invalid' is deprecated in this SNMP
           Version 2 MIB, in favor of frCircuitRowStatus."
       DEFVAL { active }
       ::= { frCircuitEntry 3 }


Comments:  If Invalid is truly drepecated (is it??) for
both read and write than first the  line:

                    invalid (1),

Should be changed (as in other updated MIBs) to:

                    invalid (1), -- deprecated

And the Description text needs to be properly reworded.

If it is still possible to use invalid for writes, or to
get invalid for reads, then it is not really deprecated.

We must state how invalid applys (if at all).


Text for frCircuitReceivedFECNs was changed:

<                 circuit was created."

Was changed to:

>            circuit was created.  This occurs when the  re-
>            mote  DTE  sets the FECN flag, or when a switch
>            in the network enqueues the frame  to  a  trunk
>            whose transmission queue is congested."

Comment: OK.

Text for XXXX was changed:


<                 circuit was created."

Was changed to:
>            circuit was created.  This occurs when the  re-
>            mote  DTE  sets the BECN flag, or when a switch
>            in the network receives the frame from a  trunk
>            whose transmission queue is congested."

Comment: OK.

New frCircuitEntry objects were added.  Comments added
below within the text:

>     frCircuitMulticast OBJECT-TYPE
>         SYNTAX   INTEGER    {
>                     unicast   (1),
>                     multicast (2)
>                     }
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "This indicates whether this VC is  used  as  a
>            multicast VC or a single destination"
>        ::= { frCircuitEntry 15 }

Comments: Currently the Frame Relay Forum Multicast Implementation
agreement defines several types of Multicast.  You might want to
change this to:
                      unicast         (1),
                      oneWayMulticast (2)
                      twoWayMulticast (3),
                      nWayMulticast   (4)

> 
>     frCircuitType OBJECT-TYPE
>         SYNTAX   INTEGER    {
>                     static  (1),
>                     dynamic (2)
>                  }
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "Indication of  whether  the  VC  was  manually
>            created   (static),   or   dynamically  created
>            (dynamic) via the data link  control  managment
>            interface."
>        ::= { frCircuitEntry 16 }
>

Comments: You might want to change "created" to "created or
configured by a network management entity".  Also "managment"
should be changed to "management" (spelling).

> 
>     frCircuitDiscards OBJECT-TYPE
>         SYNTAX   Counter32
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "The number of inbound frames  dropped  because
>            of  format  errors,  or because the VC is inac-
>            tive."
>        ::= { frCircuitEntry 17 }
> 
> 
>     frCircuitRowStatus OBJECT-TYPE
>         SYNTAX   RowStatus
>         MAX-ACCESS   read-write
>         STATUS   current
>         DESCRIPTION
>            "The SNMP Status of the rwo, used in row  crea-
>            tion."
>        ::= { frCircuitEntry 18 }
>

Comments: I would make this the last object (#19).  Also change
"rwo" to "row" (spelling)
 
> 
> 
>     frCircuitReceivedDEs OBJECT-TYPE
>         SYNTAX   Counter32
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "Number of frames received from the network in-
>            dicating  that  they  were eligible for discard
>            since the virtual circuit  was  created.   This
>            occurs when the remote DTE sets the DE flag, or
>            when in remote DTE's switch  detects  that  the
>            frame was received as Excess Burst data."
>        REFERENCE
>           "Draft American National  Standard  T1.618-1991,
>           Section 3.3.4"
>       ::= { frCircuitEntry 19 }
> 
> 
>

Comments: Change to object #18.  Also is T1.618 still a draft???

For frErrType:
<                          unknownDLCI(5),
<                          dlcmiProtoErr(6),
<                          dlcmiUnknownIE(7),
<                          dlcmiSequenceErr(8),
<                          dlcmiUnknownRpt(9),
<                          noErrorSinceReset(10)

Was changed to:

>                     dlcmiProtoErr(5),
>                     dlcmiUnknownIE(6),
>                     dlcmiSequenceErr(7),
>                     dlcmiUnknownRpt(8),
>                     noErrorSinceReset(9)

Comments: To keep backwards compatible with RFC1315, you cannot
delete unknownDLCI(5) and renumber the others.  You must deprecate
it as follows:

<                          unknownDLCI(5),       -- deprecated
<                          dlcmiProtoErr(6),
<                          dlcmiUnknownIE(7),
<                          dlcmiSequenceErr(8),
<                          dlcmiUnknownRpt(9),
<                          noErrorSinceReset(10)

and you should state why it was deprecated.(Why was it deprecated??
I'd sure like to know.)

for frErrData

<              SYNTAX   OCTET STRING
<              ACCESS   read-only
<              STATUS   mandatory

Was changed to:

>         SYNTAX   OCTET STRING (SIZE(1..1600))
>         MAX-ACCESS   read-only
>         STATUS   current

Comments: Is specifying this size for the manager?  Because
I would think it would be impractical to have systems with
multiple ports of frame relay to store large frames for every 
port in the system. 1600 bytes per port adds up very quickly.

frErrDiscards, frErrFaults, frErrFaultTime was added:

>     frErrDiscards OBJECT-TYPE
>         SYNTAX   Counter32
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "The number of inbound frames  dropped  because
>            of  format  errors  or  because  the VC was not
>            known.  Format errors, in this  case,  are  any
>            errors  which  would  prevent  the  system from
>            recognizing the DLCI and placing the  error  in
>            the frCircuitDiscard category. "
>        ::= { frErrEntry 5 }

>     frErrFaults OBJECT-TYPE
>         SYNTAX   Counter32
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "The number of times  the  interface  has  gone
>            down since it was initialized."
>        ::= { frErrEntry 6 }
> 
> 
>     frErrFaultTime OBJECT-TYPE
>         SYNTAX   TimeTicks
>         MAX-ACCESS   read-only
>         STATUS   current
>         DESCRIPTION
>            "The value of sysUpTime at the  time  when  the
>            interface  was  taken down due to excessive er-
>            rors."
>        ::= { frErrEntry 7 }
> 

Comments: OK.



 
Thats all my comments for now.  Let me know what you
think. Hopefully this message will at least get 
some comments going ;-)

Regards,

Alan

**********************************************************
Alan K. Bartky                       Email:alan@xylan.com
Principal Software Engineer          Voice:(714) 597-8042
XYLAN Corporation                    FAX:  (714) 597-8342
15707 Rockfield Avenue Suite 155F
Irvine CA. 92718
**********************************************************

P.S. I would still like to know what is the status of
this draft??  Is it still in progress??  Is anybody 
listening to my comments??  A return response from
one of the author/editors at least acknowledging
that they received it would be nice.