The IP Over NBMA (ION) Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] comments on draft-ietf-iplpdn-frmib-dte-07.txt
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
|
|