The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Jun> msg00142



[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

  • From: fred@cisco.com (Fred Baker)
  • Date: Mon, 17 Jun 1996 12:22:57 -0700
  • Cc: ion@nexen.com

At 2:31 PM 6/17/96, Roy Spitzer wrote:
>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.

We've been working on this in the background for over two years, and it
seems like just about the time everyone comes to closure and signs off, We
get a set of comments that start with "I am sorry that these comments are
so late". Do me a favor - if there's anyone else that you know that wants
their input in this document, please get them to read the draft and comment
on it, OK?

>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.

which is, I take it, a boolean that enables or disables traps?

>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.

I'm confused. What *DTE* specifications call for NNI signalling?

>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.

I'll look at it.

>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.

I dunno, is it? Nobody has ever explained to me the value of incoming QoS
values in the first place, in a DTE. If stuff successfully gets across the
frame relay network and it arrives at 9 KBPS when I'm configured for 8,
should I toss the traffic?

Seems like the principal use of this would be to display it so an NMS could
read it. Is that the objective?

>5.      The following statistics would be helpful in the frDlcmiTable:
>
>  frDlcmiLinkRelErrors OBJECT-TYPE
>  frDlcmiProtErrors OBJECT-TYPE
>  frDlcmiChanInactive OBJECT-TYPE

My standard question regarding counters is "what is the network manager
expected to do when it counts?". In what way do these help him run is
network? Are they actually useful (network managers especially please
respond) or are they "interesting numbers to have"?

>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?

frDlcmiMulticst indicates whether the DTE supports Frame Relay multicast.
frCircuitMulticast indicates whether a DTE that supports Frame Relay
Multicast is using a particular circuit as a multicast circuit.

>7.      What provisions are being made for SVCs or is it out of the
>        scope of this MIB modification?

Let me turn it around. What provision that is not currently in the MIB do
you see as necessary for SVCs?

>8.      The following statistics would be useful either as part of frDlcmiTable
>        or part of a separate table:
>
>  frErrorUserLinkRelErrors OBJECT-TYPE
>  frErrorUserProtErrors   OBJECT-TYPE
>  frErrorChanInactive   OBJECT-TYPE
>  frErrorRcvdShort   OBJECT-TYPE
>  frErrorRcvdLong   OBJECT-TYPE
>  frErrorRcvdIllegalDLCI   OBJECT-TYPE
>  frErrorRcvdUnknownDLCI   OBJECT-TYPE

My standard question regarding counters is "what is the network manager
expected to do when it counts?". In what way do these help him run is
network? Are they actually useful (network managers especially please
respond) or are they "interesting numbers to have"?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
No me deja botar el Mickey Mouse Network en el Recycle Bin.
(It won't let me toss the Microsoft network into the Recycle Bin.)