The IP Over NBMA (ION) Archive

[roy.spitzer@adn.alcatel.com (Roy Spitzer)]

James,

I agree with the philosophy that the incorporation of fields are not necessary
unless there is a proven need.  It is unforturemate that some of the suggested
fields were placed in the network provider's code because it was deemed
necessary for support of unbalanced traffic that the user could offer.  If
it is not configuable by network management in the FR DTE, the feature
cannot be offered.

This MIB should be looked at from an Entriprise management viewpoint.
Isolation of a problem must be seen from both ends (sides) of a link.
>From an operations perspective incomplete information is present if one
cannot match the DTE side of the interface with DCE side of the interface.

> 
> roy.spitzer@adn.alcatel.com writes:
> |
> |Carolyn, Fred, and Charles,
> |
> |I am sorry that these comments are so late.  I just found out about this
> |new iteration of RFC1315 at the last Frame Relay Forum meeting from Andy
> |Malis.  At the same time our offices was moving and I just was able to retrieve
> |a copy of the proposed MIB for the Montreal IETF June 24, 1996.
> |
> |How do I get on the proper distribution list for these discussions.  Andy
> |gave me ion and it did not seem right.  Please forward this mail to the
> |proper distribution list.
> |
> |Comments:
> |
> |1.      We believe that a definition of frTrapState at the interface
> |        basis is more useful for some vendors than for all interfaces.
> |        Some interfaces may be managed by different agents than others.
> |        I would suggest that frDlcmiTrapState be added to the frDlcmiTable.
> |
> |2.      The frDlcmiTable does not support bidirectional signalling.  Will
> |        this be a problem for the future?  Currently, I know of no DTE
> |        vendor that supports bidirectional signalling.
> +-------
> In general things are only added when there is a demonstrated need.  If there
> aren't such DTEs, unless someone is about to release one, defining the objects
> is work for no reward.
> 
> +--------
> |3.      frClcmiAddressLen is not adequate.  Since the MIB is going to be
> |        changed, I suggest the same definition as frLportAddrDLCILen from
> |        RFC 1604 be used.
> +-------
> Are you suggesting we need to add two more values - as this is an update
> to an existing MIB we can only add, not change.
> 
> Has anyone deployed equipment using either of the two missing values ?
> +------
> |4.      The MIB does not support different quality of service parameter
> |        (CIR, Bc, Be) on a per direction basis.  Is this a problem for the
> |        future.
> +--------
> Again, when the need arises, the change can then be made.
> 
> +----------
> |5.      The following statistics would be helpful in the frDlcmiTable:
> |
> |  frDlcmiLinkRelErrors OBJECT-TYPE
> |     SYNTAX  Counter32
> |     MAX-ACCESS  read-only
> |     STATUS  current
> |     DESCRIPTION
> |             "The number of user-side local in-channel
> |             signaling link reliability errors (i.e., non-
> |             receipt of Status/Status Enquiry messages or
> |             invalid sequence numbers in a Link Integrity
> |             Verification Information Element) for this UNI/NNI
> |             logical port.  If the logical port is not
> |             performing user-side procedures, then this value
> |             is equal to noSuchName."
> |     REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D"
> |     ::= { frDlcmiEntry 13 }
> |
> |  frDlcmiProtErrors OBJECT-TYPE
> |     SYNTAX  Counter32
> |     MAX-ACCESS  read-only
> |     STATUS  current
> |     DESCRIPTION
> |             "The number of user-side local in-channel
> |             signaling protocol errors (i.e., protocol
> |             discriminator, message type, call reference, and
> |             mandatory information element errors) for this
> |             UNI/NNI logical port.  If the logical port is not
> |             performing user-side procedures, then this value
> |             is equal to noSuchName."
> |     REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D"
> |     ::= {frDlcmiEntry 14 }
> |
> |  frDlcmiChanInactive OBJECT-TYPE
> |     SYNTAX  Counter32
> |     MAX-ACCESS  read-only
> |     STATUS  current
> |     DESCRIPTION
> |             "The number of times the user-side channel was
> |             declared inactive (i.e., N392 errors in N393
> |             events) for this UNI/NNI logical port. If the
> |             logical port is not performing user-side
> |             procedures, then this value is equal to
> |             noSuchName."
> |     REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D"
> |     ::= { frDlcmiEntry 15 }
> +--------
> See comments below.
> 
> +---------
> |6.      What is the interrelationship between frCircuitMulticast and
> |        frDlcmiMulticast?  Can frCircuitMulticast be set to anything
> |        other than unicast if frDlcmiMulticast is nonBroadcast?  Can the
> |        same interface have both unicast and multicast DLCI?  If so,
> |        what is the setting of frDlcmiMulticst set?
> +--------
> a) One says what the interface is capable of.
> b) No.
> c) Yes
> d) broadcast
> 
> +-------
> |7.      What provisions are being made for SVCs or is it out of the
> |        scope of this MIB modification?
> +------
> Out of scope.  Show up at the FRS MIB WG meeting in Montreal to discuss
> what should/will be done about SVCs for both the DTE and switch cases...
> 
> +---------
> |8.      The following statistics would be useful either as part of frDlcmiTable
> |        or part of a separate table:
> |
> |   frErrorUserLinkRelErrors OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION -- (from RFC1604 frMgtVCSigUserLinkRelErrors)
> |             "The number of user-side local in-channel
> |             signaling link reliability errors (i.e., non-
> |             receipt of Status/Status Enquiry messages or
> |             invalid sequence numbers in a Link Integrity
> |             Verification Information Element) for this UNI/NNI
> |             logical port.  If the logical port is not
> |             performing user-side procedures, then this value
> |             is equal to noSuchName."
> |       REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D"
> |       ::= { frErrorEntry 1 }
> |
> |  frErrorUserProtErrors   OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION  -- (from RFC1604 frMgtVCSigUserProtErrors   )
> |             "The number of user-side local in-channel
> |             signaling protocol errors (i.e., protocol
> |             discriminator, message type, call reference, and
> |             mandatory information element errors) for this
> |             UNI/NNI logical port.  If the logical port is not
> |             performing user-side procedures, then this value
> |             is equal to noSuchName."
> |       REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D"
> |       ::= { frErrorEntry 2 }
> |
> |  frErrorChanInactive   OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION  -- (from RFC1604  frMgtVCSigUserChanInactive )
> |             "The number of times the user-side channel was
> |             declared inactive (i.e., N392 errors in N393
> |             events) for this UNI/NNI logical port. If the
> |             logical port is not performing user-side
> |             procedures, then this value is equal to
> |             noSuchName."
> |       REFERENCE "ITU Q.933 Annex A and ANSI T1.617 Annex D"
> |       ::= { frErrorEntry 3 }
> +--------
> I'm not sure I can see the point of these in a DTE.  On the switch
> side they somewhat make sense (watch out for "interesting" DTEs) but
> I'm not sure what I'd do if these counters started going up in my
> DTE if it were anywhere other than on the lab bench...
> 
> +------
> |  frErrorRcvdShort   OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION
> |           "The number of frames that were to short to be legal
> |            frame relay frames"
> |       ::= { frErrorEntry 4 }
> |
> |  frErrorRcvdLong   OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION
> |            "The number of frames that were longer than the length
> |             specified in the ifTable by ifMtu for this interface."
> |       ::= { frErrorEntry 5 }
> +-------
> The previous two simply sound like a partitioning of the ifInErrors
> counter - how would I use the extra information ?
> 
> +---------
> |   frErrorRcvdIllegalDLCI   OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION
> |           "The number of frames received with an illegal Data Link
> |            Connection Identifier (DLCI)."
> |       ::= { frErrorEntry 6 }
> |
> |  frErrorRcvdUnknownDLCI   OBJECT-TYPE
> |       SYNTAX Counter32
> |       MAX-ACCESS read-only
> |       STATUS current
> |       DESCRIPTION
> |           "The number of frames received with an unknown Data Link
> |            Connection Identifier (DLCI)."
> |       ::= { 6fdnVsFrErrorEntry 7 }
> +-----------
> How would I use these counters ?  Or more accurately, how would it make
> fault isolation easier than simply sifting through the error table ?
> 
> 
> Regards,
> -james
> 
> ____________________________________________________________________________
> James W. Watt,     james@newbridge.com                   Ph: +1 613 591-3600
> Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680
> 
Regards,
Roy


==========================================================================

Roy Spitzer				Roy.Spitzer@adn.alcatel.com
Alcatel Data Networks			(703) 724-2412
44983 Knoll Square			FAX: (703) 724-2005
Ashburn, VA 20147