Re: Counting Send DE Frames for Frame Relay MIB
Fred Baker <fred@cisco.com> Tue, 22 August 1995 03:28 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00466; 21 Aug 95 23:28 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00462; 21 Aug 95 23:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00828; 21 Aug 95 23:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00441; 21 Aug 95 23:28 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00437; 21 Aug 95 23:25 EDT
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa00798; 21 Aug 95 23:25 EDT
Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id UAA00832; Mon, 21 Aug 1995 20:26:31 -0700
X-Sender: fred@stilton.cisco.com
Message-Id: <v0213050bac5ef80816e6@[171.69.128.114]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 21 Aug 1995 20:25:32 -0700
To: Caralyn Brown <cbrown@baynetworks.com>
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fred@cisco.com>
Subject: Re: Counting Send DE Frames for Frame Relay MIB
Cc: Alan Bartky <alan@xylan.com>, iplpdn@CNRI.Reston.VA.US
At 6:01 PM 8/21/95, Caralyn Brown wrote: >As for the following suggestion, how would a network manager make use of this? >Personally, I would like not to add this, but if there is good reason to add >it and others like it, what the heck. My personal opinion (which James has heard before at some length): This is a DTE MIB. If the switch is correctly implemented, when the DTE sets DE, the switch is very likely to simply discard the traffic, due to the way excess burst is usually configured. Therefore, setting DE is, in most cases, asking the switch to discard the traffic. Therefore, I can think of very few good reasons for the DTE to ever set DE. I can think of (have heard) a few that sound good until you think through the traffic timing, but none that (a) actually prioritize traffic and (b) do not cause it to be lost in the network. Therefore, I don't see the point of counting such errors, either. >> frCircuitSentDEs OBJECT-TYPE >> SYNTAX Counter32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "Number of frames sent to the network in- >> dicating that they were eligible for discard >> since the virtual circuit was created. This >> occurs when the local DTE sets the DE flag, >> indicating that during Network congestion situations >> those frames should be discarded in >> preference of other frames sent without the >> DE bit set." >> REFERENCE >> "Draft American National Standard T1.618-1991, >> Section 3.3.4" >> ::= { frCircuitEntry xx } having said which, if the world at large absolutely must have this object, go 4 it. And I want $1 for every router sold that, six months after installation, is actually configured to set DE. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you're looking to find the key to the Universe, I have some bad news and some good news. The bad news is -- there is no key to the Universe. The good news is -- it has been left unlocked.
- Counting Send DE Frames for Frame Relay MIB Alan Bartky
- Re: Counting Send DE Frames for Frame Relay MIB Caralyn Brown
- Re: Counting Send DE Frames for Frame Relay MIB James Watt
- Re: Counting Send DE Frames for Frame Relay MIB Fred Baker
- Re: Counting Send DE Frames for Frame Relay MIB Alan Bartky
- Re: Counting Send DE Frames for Frame Relay MIB artb
- Re: Counting Send DE Frames for Frame Relay MIB James Watt
- Re: Counting Send DE Frames for Frame Relay MIB Fred Baker
- Re: Counting Send DE Frames for Frame Relay MIB Alan Bartky
- Re: Counting Send DE Frames for Frame Relay MIB Caralyn Brown