Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00703; 1 Oct 93 4:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00699; 1 Oct 93 4:02 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02028; 1 Oct 93 4:02 EDT Received: from datanet.tele.fi by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 04:02:16 EDT Message-Id: <9310010802.AA11692@thumper.bellcore.com> Received: from datanet.tele.fi by datanet.tele.fi id <12758-0@datanet.tele.fi>; Fri, 1 Oct 1993 10:02:11 +0200 To: bsimpson@morningstar.com Cc: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com In-Reply-To: <1446.bill.simpson@um.cc.umich.edu> Subject: AAL and other issues Date: Fri, 1 Oct 1993 10:02:11 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi If the ATM and/or F-R MIBs don't fit MIB-II, then they should not be standardized. It's as simple as that. or should be standardized somewhere outside the IETF. what does IETF have to do with ATM or FR anyway? it only controls the IP protocol stack and can't obviously prevent others doing what they like with their protocol stacks. the title of the MIB-II RFC is "Management Information Base for network management of TCP/IP-based internets", which clearly defines its scope. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02704; 1 Oct 93 8:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02695; 1 Oct 93 8:34 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05813; 1 Oct 93 8:34 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 08:34:08 EDT Received: from shs.xyplex.com by xap.xyplex.com id ; Fri, 1 Oct 93 08:32:05 -0500 Received: by shs.xyplex.com (4.1/SMI-4.1) id AA13565; Fri, 1 Oct 93 08:32:37 EDT Date: Fri, 1 Oct 93 08:32:37 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Sherry Message-Id: <9310011232.AA13565@shs.xyplex.com> To: if-mib@thumper.bellcore.com Subject: Re: propMultiLink / impact statements Forwarding: Mail from '"William Allen Simpson" ' dated: Thu, 30 Sep 93 17:43:42 EDT >> From: shs@shs.xyplex.com (Steve Sherry) >> What about the case where you have multilink to two different partners >> being grouped under one psuedo-multicast interface. In this case >> without the interface for multi-link, it will not be self-evident >> which interfaces are grouped with other interfaces. >> >That's very interesting, and not something I've thought about. After >all, every Ethernet interface is potentially a multicast interface, but >we don't try to keep the multicast relations in the interface MIB. > >It sounds as if you are trying to mix routing information into the MIB. > >I'd suggest having an interface for each partner, so that each partner >can be taken down separately, and group the multi-links to the partner >with the ifStack. Those sound like link management functions, which are >appropriate to a MIB. > >The routing code should take care of sending the multicast to the >correct partner interfaces, just as it would with multiple ethernet >interfaces. I don't disagree about packets that are being routed to the next hop. However, certain routing protocols use multicasts to discover each other and bridging has the concept of multicasting. In both cases, when you have three or more routers all interconnected (take Frame Relay for instance), its more efficient to treat the circuits to the other routers as a single multicast interface. To take the problem even further, there may be an additional bridge/router on the same frame relay network which is only connected to one of the other interconnected routers. There must be a separate interface for the bridging layer for this router. I haven't event discussed load balancing.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07870; 1 Oct 93 11:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07866; 1 Oct 93 11:12 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09542; 1 Oct 93 11:12 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 11:12:03 EDT Received: by xap.xyplex.com id ; Fri, 1 Oct 93 11:10:00 -0500 Date: Fri, 1 Oct 93 11:10:00 -0500 Message-Id: <9310011610.AA16457@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com In-Reply-To: Juha Heinanen's message of Fri, 1 Oct 1993 10:02:11 +0200 <9310010802.AA11692@thumper.bellcore.com> Subject: Re: Relevance of SNMP to ATM and FR (was AAL and other issues) Juha, If SNMP and MIB-II are so irrelevant to ATM and Frame Relay, why are you bothering to define an SNMP-compatible MIB? You'd get a lot more power and flexibility with GDMO and CMIP. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08478; 1 Oct 93 11:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08469; 1 Oct 93 11:40 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10078; 1 Oct 93 11:40 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 11:40:09 EDT Received: by ftp.com id AA29406; Fri, 1 Oct 93 11:40:13 -0400 Date: Fri, 1 Oct 93 11:40:13 -0400 Message-Id: <9310011540.AA29406@ftp.com> To: Juha.Heinanen@datanet.tele.fi Subject: Re: AAL and other issues Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: bsimpson@morningstar.com, if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com Bill and Juha, While it is true that the IETF has no "authority" with regard to FR and ATM, these technologies do play a role in IP-based networks. Therefore, since we are interested in managing IP-based networks, it is within our "authority" to do whatever is necessary to make these technologies manageable within the context of Internetworks. In the case of FR and ATM that means doing the work to make sure that they are manageable via SNMP; i.e. defining MIBs based on work that is done elsewhere. We have a long and honorable tradition of doing this -- the Ethernet MIB, the Bridge MIB, the 802.4 MIB, the 802.5 MIB, the RS232 port MIB, the T1 and T2 MIBs, the X.25 MIB, and so on. If the Internet network management framework can not accomodate the MIBs of other, necessary, technologies, then either A) the framework has to change, B) current MIBs have to change (such as the work being done right now on the IF mib) or C) the other technology's MIB has to change (e.g. we pruned a lot of stuff out of the IEEE's version of the Ether MIB). Both of these attitudes are A) counter productive, B) offensive, C) narrow minded, and D) short-sighted. > If the ATM and/or F-R MIBs don't fit MIB-II, then they should not be > standardized. It's as simple as that. > > or should be standardized somewhere outside the IETF. what does IETF > have to do with ATM or FR anyway? it only controls the IP protocol > stack and can't obviously prevent others doing what they like with their > protocol stacks. the title of the MIB-II RFC is "Management Information > Base for network management of TCP/IP-based internets", which clearly > defines its scope. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12511; 1 Oct 93 14:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12507; 1 Oct 93 14:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13307; 1 Oct 93 14:09 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 14:09:48 EDT Received: by xap.xyplex.com id ; Fri, 1 Oct 93 14:07:47 -0500 Date: Fri, 1 Oct 93 14:07:47 -0500 Message-Id: <9310011907.AA21022@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com In-Reply-To: (Frank Kastenholz's message of Thu, 30 Sep 93 17:50:21 -0400 <9309302150.AA12631@ftp.com> Subject: Re: propMultiLink / impact statements Well, Frank, you talked about MIBs a lot, but that wasn't what I was getting at. I'm not even hinting that we should try to do a common multilink MIB. I'm simply suggesting that various proprietary multilinks would look a bit friendlier if their ifType was 'propMultiLink' rather than 'other'. This wouldn't be a problem if the chains of backward compatibility weren't forcing us to maintain an enumerated integer where we would now put an AutonomousType object identifier. Maybe I should just be a hardhead and argue for deprecating ifType in favor or a replacement that allows more flexibility... Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12863; 1 Oct 93 14:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12859; 1 Oct 93 14:27 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13831; 1 Oct 93 14:27 EDT Received: from datanet.tele.fi by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 14:27:33 EDT Message-Id: <9310011827.AA14309@thumper.bellcore.com> Received: from datanet.tele.fi by datanet.tele.fi id <15548-0@datanet.tele.fi>; Fri, 1 Oct 1993 20:27:21 +0200 To: rlstewart@xap.xyplex.com Cc: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com In-Reply-To: <9310011610.AA16457@xap.xyplex.com> "rlstewart@xap.xyplex.com" Subject: Relevance of SNMP to ATM and FR (was AAL and other issues) Date: Fri, 1 Oct 1993 20:27:21 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi i think that SNMP is a very good protocol. all our network management is based on it. but the fact is that the whole whole concept of interfaces is broken in the IP protocol architecture and it, of course, reflects also the interface MIB. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13168; 1 Oct 93 14:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13164; 1 Oct 93 14:42 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14224; 1 Oct 93 14:42 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 14:42:37 EDT Received: by xap.xyplex.com id ; Fri, 1 Oct 93 14:40:29 -0500 Date: Fri, 1 Oct 93 14:40:29 -0500 Message-Id: <9310011940.AA21832@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com In-Reply-To: Juha Heinanen's message of Fri, 1 Oct 1993 20:27:21 +0200 <9310011925.AA21436@xap.xyplex.com> Subject: Re: Relevance of SNMP to ATM and FR (was AAL and other issues) The interface MIB evolution working group is trying to fix the well-recognized problems in the interface MIB. I'm positive that at least some of the people in that group consider ATM and FR among the technologies that must be managed. It seems at best unproductive to rail against that part of the MIB when a working group is actively trying to fix it. Are they failing? Is it because they won't listen? Or because no one has given them the necessary guidance? Or is there perhaps a conflict of cultures? X.25 was supposed to be the network layer that made all others obsolete. The most casual observer is aware that did not happen. It isn't even generally treated as a network layer, rather it's just one of many types of data links. Some people seem to believe that ATM will replace everything else, and should thus be designed in as the center of the universe. I may get hit by a meteor on the way home, but I don't expect to live to see networking become so homogenized. I honestly don't understand quite what's going on here. I spoke up because I saw inflammatory statements being cross posted. I'm beginning to suspect that I've fallen into a classic Internet tar pit with a provocateur I hadn't yet learned to recognize. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13419; 1 Oct 93 15:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13415; 1 Oct 93 15:03 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14873; 1 Oct 93 15:03 EDT Received: from synoptics.com (pobox.synoptics.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 15:03:56 EDT Received: from aladdin (aladdin.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA19989; Fri, 1 Oct 93 12:02:24 PDT Received: by aladdin (4.1/2.0N) id AA01401; Fri, 1 Oct 93 12:02:24 PDT Message-Id: <9310011902.AA01401@aladdin> Date: Fri, 1 Oct 93 12:02:24 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Donna McMaster To: Juha.Heinanen@datanet.tele.fi Subject: Re: AAL and other issues Cc: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com Juha, > If the ATM and/or F-R MIBs don't fit MIB-II, then they should not be > standardized. It's as simple as that. > > or should be standardized somewhere outside the IETF. what does IETF > have to do with ATM or FR anyway? it only controls the IP protocol > stack and can't obviously prevent others doing what they like with their > protocol stacks. the title of the MIB-II RFC is "Management Information > Base for network management of TCP/IP-based internets", which clearly > defines its scope. The IETF isn't "responsible" for ATM and FR, but it HAS been providing the SNMP expertise to define MIBs for all of the various network protocols -- otherwise how do we explain the MIB activities for IEEE 802.3, 802.5, T1, DS3, etc. In these cases, knowledgeable folks from other areas have provided the protocol-specific background and the IETF'ers have provided the MIB expertise. Seems to be working. Donna   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17726; 1 Oct 93 18:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17722; 1 Oct 93 18:43 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19768; 1 Oct 93 18:43 EDT Received: from flash.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 1 Oct 93 18:43:44 EDT Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA21281; Fri, 1 Oct 93 18:43:43 -0400 Received: from by eve (4.1/4.7) id AB10030; Fri, 1 Oct 93 18:45:33 EDT Date: Fri, 1 Oct 93 18:45:33 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9310012245.AB10030@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: AAL and other issues Cc: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com > If the ATM and/or F-R MIBs don't fit MIB-II, then they should not be > standardized. It's as simple as that. > >or should be standardized somewhere outside the IETF. what does IETF >have to do with ATM or FR anyway? it only controls the IP protocol >stack and can't obviously prevent others doing what they like with their >protocol stacks. the title of the MIB-II RFC is "Management Information >Base for network management of TCP/IP-based internets", which clearly >defines its scope. > i'm not sure that this thread is bringing us closer to a solution. my preference is to make a best effort to apply the if-mib to atm and fr. if if-mib is broken, lets fix that. if the mapping of if-mib to atm or fr environments causes a problem, lets fix that. kaj 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23821; 4 Oct 93 1:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23817; 4 Oct 93 1:39 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10348; 4 Oct 93 1:39 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 01:07:21 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA03841; Sun, 3 Oct 93 22:07:07 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA16808; Sun, 3 Oct 93 21:51:36 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310040451.AA16808@nms.hls.com> Subject: re: AAL and other issues To: Masuma Ahmed Date: Sun, 3 Oct 93 21:51:36 PDT Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9309271600.AA01829@freeze>; from "Masuma Ahmed" at Sep 27, 93 12:00 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > However, having separate ifEntries still do not solve all the AAL issues that > have been discussed in earlier emails. For example, > the interpretation of the ifSpeed for AAL, The definition of ifSpeed in the if-mib wg's Internet Draft addresses this issue. > the correlation between the > AAL failure and the virtual connection (used for carrying the AAL) failure, The failure of a VC does not cause a failure of the AAL sub-layer. I see no problem here. > the types of AAL performance monitoring parameters, Well, the ifTable counters for the AAL sub-layer count AAL frames. > and the > interpretation of the ifOutUcastPkts (which has a different meaning > from that provided in the ifMIB draft proposal), have yet to > be resolved. ifOutUCastPkts is defined by the if-mib's Internet Draft. It cannot have a different meaning. > Given that there are quite a few outstanding issues, can we > propose to take out AAL from the ATM MIB at the present time and > consider them for further study ? Please identify which MIB objects you would propose to remove. [Also note that leaving AAL out would go against the spirit/letter of this wg's charter.] > Most of the counters specified in the interfaces > draft proposal (9/23/93) are not > applicable to the ATM interface. However, since ATM interface > is a packet interface, they are required to be included in > the ATM MIB with null values. Using "0" for these counters > could be misleading unless the network management applications > are sophisticated enough to interpret them as not being supported. I proposed that the ATM layer should be considered as a character-oriented interface, and there was one objection. Can you refute that objection ?? > Also, the interpretations of the ifOutUcastPkts for ATM cells > and for AAL packets are not the same as defined in > the interfaces draft. Is it possible for the description clause > to include both definitions and use only the definition > which is applicable to the specific interface ? As mentioned above, a media-specific MIB is NOT allowed to redefine ifOutUcastPkts (or any other ifTable object). The current ATOM-MIB needs to be fixed in this respect. [Note that even if an implementation can only count packets transmitted, it can still respond with the correct value of ifOutUcastPkts by subtracting the values of ifOutErrors and ifOutDiscards from its count of packets transmitted.] > Also, is it possible to define > a separate compliance statement for ATM -like interfaces > for which only a subset of the packet counters is applicable ? Just for ATM interfaces, no. > Alternatively, can we use only the General Group for ATM cell and the AAL and > define the respective counters in the ATM MIB ? This would effectively define ATM and AAL as bit-oriented interfaces. I don't think so. > Traps : > > Currently, the only link up/down trap considered for the ATM MIB > is at the physical layer. This is incorrect. LinkUp/linkDown traps are defined for each sub-layer which has an ifTable entry. The if-mib says that *by default*, only the physical layer trap is enabled. > For ATM carried over STS-3c, the > SONET TC sublayer can fail independently of the physical layer. > Even at the physical layer, e.g., for SONET, the only > trap considered is for the Line/Section failure and > no trap considered for Path layer failure. What happens > when the STS-3c Path or the SONET TC sublayer fails ? > Traps are supported for fault isolation and detection. However, > by supporting traps at the lowest layer only, there is no > information available to detect and isolate faults at the higher layers. > Can we propose to define the ATM layer trap in the ATM MIB ? > How about defining the STS-3c Path layer trap in the SONET MIB ? The reason for the default behaviour of only enabling traps for the physical layer, is to avoid generating multiple traps when all layers go down (plus, it's too hard to require expect layers to communicate/corrolate failures in one layer to failures in another.) So, we don't need any more traps - they are already defined, and a particular Network Adminstration can enable them in specific devices if it so wishes. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23838; 4 Oct 93 1:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23834; 4 Oct 93 1:41 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10385; 4 Oct 93 1:41 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 01:41:36 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA04675; Sun, 3 Oct 93 22:41:23 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA16939; Sun, 3 Oct 93 22:25:52 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310040525.AA16939@nms.hls.com> Subject: Re: Consensus To: Bob Stewart Date: Sun, 3 Oct 93 22:25:51 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <9309272107.AA06270@xap.xyplex.com>; from "Bob Stewart" at Sep 27, 93 4:07 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > Regarding Steve's example with a load balancer on top, what ifType would that > have? "other" isn't very illuminating, and it seems that lots of people will > have various proprietary schemes for doing that. Can we have an ifType for > that, something like "multiplexor" or "loadBalancer" or "linkGrouper" or... It seems to me that a "propMultiplexor" would satisfy both this and the "propMultiLink" suggestion. Does anyone object to adding "propMultiplexor" ? > Also, while I'm at it, I asked a while back about some means of distinguishing > ifIndexes that correspond to physical ports from those that do not. I > suggested an object with "physical" and "virtual" enumerations, as we have in > the Character MIB. Nobody commented. Am I the only one that cares? Have I > missed something that makes that a dumb idea? Apologies. With you and the others having proposed this, we seem to have consensus on adding "virtual". Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23875; 4 Oct 93 1:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23871; 4 Oct 93 1:58 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10588; 4 Oct 93 1:58 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 01:58:32 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA04906; Sun, 3 Oct 93 22:58:20 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA17028; Sun, 3 Oct 93 22:42:49 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310040542.AA17028@nms.hls.com> Subject: Re: Call for concensus To: Jim Barnes Date: Sun, 3 Oct 93 22:42:48 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <11396.9309271412@spock.xylogics.com>; from "Jim Barnes" at Sep 27, 93 10:12 am Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > First, just a clarification to make sure I understand the issue, in section > 3.2.1, the third paragraph on page 11 of the Sept. 20 version, I find > the following: > > "... The vital constancy requirement is met by > requiring that after an interface is dynamically removed, its > ifIndex value is not re-used (by another dynamically added > interface) until after the following re-initialization of the > network management system." > > Does this mean that if I have a dynamic interface established over > a particular physical port, if the interface is removed and then > the same physical port is used to establish a new interface at some > future time, the ifIndex value for the new interface will be different > than the ifIndex value for the first interface over that physical port? If the same interface is re-established, then it can use the same ifIndex value. If a different interface is established, it uses a new ifIndex value. (where by "interface", I mean the sub-layer referred to by the ifEntry). Would changing "by another dynamically added" to "by a different dynamically added" make the wording clearer ? > Second, some of the enumerated values for ifType are "ddn-x25(4)", > "iso88026-man(10)", etc. My interpretation of RFC1452 (Coexistence > between SNMPv1 and SNMPv2) is that these names are illegal for SNMPv2 > MIBs. Thanks. I'll fix the labels. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24000; 4 Oct 93 2:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23996; 4 Oct 93 2:27 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10954; 4 Oct 93 2:27 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 02:27:08 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA05062; Sun, 3 Oct 93 23:26:56 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA17122; Sun, 3 Oct 93 23:11:25 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310040611.AA17122@nms.hls.com> Subject: Re: Attempted Final Draft To: Bob Stewart Date: Sun, 3 Oct 93 23:11:24 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <9309291654.AA16365@xap.xyplex.com>; from "Bob Stewart" at Sep 29, 93 11:54 am Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > On page 13, paragraph 3, line 4 is broken. It says "on top of In fact." Thanks. > As has been discussed to death, IANA definition of ifTypes has ASN.1 problems. > Could we resolve that by having an IANA-controlled document with textual > conventions that can be referenced and compiled normally? In the Evolution > document, ifType would be SYNTAX InterfaceType, and that textual convention > would be in the IANA-DEFINITIONS document. You could pick up new values with > a straight-forward recompilation. Textual conventions are an extremely > powerful capability. I'm loathe to have the Evolutions document dependent on something which is not yet defined or published. We could define two MIB Modules in the Evolutions document, the second being the IANA-DEFINITIONS you suggest, and then have it be able to be replaced by future revisions of that MIB Module. But, I doubt that such a future revision would be able to be used without some editing (e.g., removing page numbers), so there will be editing to be done anyway. It doesn't seem much difference to the existing scheme, which does have the advantage of being understood. > Although I've met considerable apathy, it still seems to me it would be useful > to distinguish physical and virtual interfaces. This assists generic (cough, > cough, ahem) programs that try to draw a picture and indicate physical > interfaces. It would actually be useful for any generic attempt to start from > a well-defined place. You could assume that the bottom level of ifStackTable > represents physical interfaces, but a stated requirement would be much better. > A suggestion or implication isn't good enough for dependable interoperability. > If such a requirement is not reasonable, I propose an object, ifPhysical, > added to IfXEntry, SYNTAX TruthValue, MAX-ACCESS read-only. Nudge me slightly > and I'll provide the ASN.1. A couple of people have spoken in support of this > idea. There has been no dissent. I feel ignored. I'd like a comment from > the authors, please. Apologies. Will adding virtual() as an ifType satisfy this ? Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25802; 4 Oct 93 8:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25798; 4 Oct 93 8:47 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16294; 4 Oct 93 8:47 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 08:47:31 EDT Received: by ftp.com id AA22073; Mon, 4 Oct 93 08:47:34 -0400 Date: Mon, 4 Oct 93 08:47:34 -0400 Message-Id: <9310041247.AA22073@ftp.com> To: kzm@hls.com Subject: Re: Consensus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: rlstewart@xap.xyplex.com, if-mib@thumper.bellcore.com >> Regarding Steve's example with a load balancer on top, what ifType would that >> have? "other" isn't very illuminating, and it seems that lots of people will >> have various proprietary schemes for doing that. Can we have an ifType for >> that, something like "multiplexor" or "loadBalancer" or "linkGrouper" or... > >It seems to me that a "propMultiplexor" would satisfy both this and the >"propMultiLink" suggestion. Does anyone object to adding "propMultiplexor" ? > >>Also, while I'm at it, I asked a while back about some means of distinguishing >>ifIndexes that correspond to physical ports from those that do not. I >>suggested an object with "physical" and "virtual" enumerations, as we have in >>the Character MIB. Nobody commented. Am I the only one that cares? Have I >>missed something that makes that a dumb idea? > >Apologies. With you and the others having proposed this, we seem to have >consensus on adding "virtual". This is not within our purview any more. I do believe that the assignment of ifTypes now belongs to Jon, Joyce, and their faithful minions. I would suggest that whoever wants these (or any other) objects, get in touch with IANA. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28912; 4 Oct 93 10:36 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28908; 4 Oct 93 10:36 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19163; 4 Oct 93 10:36 EDT Received: from monk.proteon.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 10:36:27 EDT Received: from hutch.proteon.com by monk.proteon.com (5.65/1.8) id AA03537; Mon, 4 Oct 93 10:36:51 -0400 Received: by hutch.proteon.com (4.1/SMI-4.1) id AA03937; Mon, 4 Oct 93 10:36:19 EDT Date: Mon, 4 Oct 93 10:36:19 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Arun V. Mahajan" Message-Id: <9310041436.AA03937@hutch.proteon.com> To: if-mib@thumper.bellcore.com Subject: ifOperStatus Cc: axm@hutch.proteon.com Hi all, I am new to this list, so apologies if this has been brought up before... Is there any provision for the case of redundant interfaces (in ifOperStatus for starters) ? For example, if there exists a redundant WAN link, acting as a backup link to another link that is configured, and this link is usually in a standby mode, then how does it look from the SNMP perspective ? or is this an implementation issue? Is it ok to set the 'ifOperStatus' to unknown(4) in this case? thanks, .arun   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29122; 4 Oct 93 10:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29118; 4 Oct 93 10:43 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19272; 4 Oct 93 10:43 EDT Received: from lobster.wellfleet.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 10:43:25 EDT Received: from sargon.wellfleet.com by lobster.wellfleet.com (4.1/SMI-4.1) id AA13995; Mon, 4 Oct 93 09:59:11 EDT Received: by sargon.wellfleet.com (4.1/SMI-4.1) id AA27038; Mon, 4 Oct 93 10:09:33 EDT Date: Mon, 4 Oct 93 10:09:33 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Onishi Message-Id: <9310041409.AA27038@sargon.wellfleet.com> To: kasten@ftp.com Subject: Re: Consensus Cc: if-mib@thumper.bellcore.com > >>> Regarding Steve's example with a load balancer on top, what ifType would that >>> have? "other" isn't very illuminating, and it seems that lots of people will >>> have various proprietary schemes for doing that. Can we have an ifType for >>> that, something like "multiplexor" or "loadBalancer" or "linkGrouper" or... >> >>It seems to me that a "propMultiplexor" would satisfy both this and the >>"propMultiLink" suggestion. Does anyone object to adding "propMultiplexor" ? > >This is not within our purview any more. I do believe that the >assignment of ifTypes now belongs to Jon, Joyce, and their faithful >minions. I would suggest that whoever wants these (or any other) >objects, get in touch with IANA. > OK, but it may be worth describing what information should be maintained by such a row...ifMtu and ifSpeed may not make sense if you are muxing over disparate stacks, etc etc....or would this be a vendor specific compliance statement? _____________________________________________________________________________ Steven P. Onishi ____ Wellfleet Communications Inc. /|\/|\ Phone: (508) 436-3816 2 Federal Street M/S 1094 Fax: (508) 670-8760 Billerica, MA 01821 E-mail: sonishi@wellfleet.com _____________________________________________________________________________   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01559; 4 Oct 93 12:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01555; 4 Oct 93 12:22 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21519; 4 Oct 93 12:22 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 12:22:28 EDT Received: by ftp.com id AA00868; Mon, 4 Oct 93 12:22:39 -0400 Date: Mon, 4 Oct 93 12:22:39 -0400 Message-Id: <9310041622.AA00868@ftp.com> To: sonishi@wellfleet.com Subject: Re: Consensus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com > >>> Regarding Steve's example with a load balancer on top, what ifType would that > >>> have? "other" isn't very illuminating, and it seems that lots of people will > >>> have various proprietary schemes for doing that. Can we have an ifType for > >>> that, something like "multiplexor" or "loadBalancer" or "linkGrouper" or... > >> > >>It seems to me that a "propMultiplexor" would satisfy both this and the > >>"propMultiLink" suggestion. Does anyone object to adding "propMultiplexor" ? > > > >This is not within our purview any more. I do believe that the > >assignment of ifTypes now belongs to Jon, Joyce, and their faithful > >minions. I would suggest that whoever wants these (or any other) > >objects, get in touch with IANA. > > > > OK, but it may be worth describing what information should be maintained by > such a row...ifMtu and ifSpeed may not make sense if you are muxing over > disparate stacks, etc etc....or would this be a vendor specific compliance > statement? Not in the ifmib. This is a matter for a hypothetical "Standard Interface Multiplexor MIB". Feel free to raise the issue of forming such a working group with the Area Director. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02282; 4 Oct 93 13:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02278; 4 Oct 93 13:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22435; 4 Oct 93 13:09 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 13:09:42 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA24668 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Mon, 4 Oct 1993 10:09:36 -0700 Message-Id: <199310041709.AA24668@hubbub.cisco.com> To: "Arun V. Mahajan" Cc: if-mib@thumper.bellcore.com, axm@hutch.proteon.com Subject: Re: ifOperStatus In-Reply-To: Your message of "Mon, 04 Oct 93 10:36:19 EDT." <9310041436.AA03937@hutch.proteon.com> Date: Mon, 04 Oct 93 10:09:35 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder It would not be a bad idea to expand on the reason for a link being down. Suggestion: down-administrative down-communcation-failed down-no-demand down-unknown It would help the management people to color their icons with a bit more data about the status of a link. Thoughts? Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02960; 4 Oct 93 13:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02956; 4 Oct 93 13:52 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23330; 4 Oct 93 13:52 EDT Received: from UTKVX3.UTK.EDU by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 13:52:03 EDT Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-13 #4157) id <01H3PT1Z22288Y53DW@utkvx.utk.edu>; Mon, 4 Oct 1993 13:39:46 EDT Date: Mon, 04 Oct 1993 13:39:46 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utk.edu Subject: Re: comments on keith's latest posting To: kzm@hls.com Cc: if-mib@thumper.bellcore.com Message-Id: <01H3PT1Z7EYQ8Y53DW@utkvx.utk.edu> X-Vms-To: IN%"kzm@hls.com" X-Vms-Cc: IN%"if-mib@thumper.bellcore.com",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >Is that better ? yes, thank you regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05309; 4 Oct 93 15:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05305; 4 Oct 93 15:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25193; 4 Oct 93 15:09 EDT Received: from monk.proteon.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 15:09:40 EDT Received: from hutch.proteon.com by monk.proteon.com (5.65/1.8) id AA06630; Mon, 4 Oct 93 15:10:00 -0400 Received: by hutch.proteon.com (4.1/SMI-4.1) id AA04034; Mon, 4 Oct 93 15:09:19 EDT Date: Mon, 4 Oct 93 15:09:19 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Arun V. Mahajan" Message-Id: <9310041909.AA04034@hutch.proteon.com> To: snyder@cisco.com Subject: ifOperStatus Cc: axm@hutch.proteon.com, if-mib@thumper.bellcore.com >It would not be a bad idea to expand on the reason for a link being >down. > >Suggestion: > > down-administrative > down-communcation-failed > down-no-demand > down-unknown > >It would help the management people to color their icons with a bit >more data about the status of a link. > >Thoughts? > >Robert Yes, this is in the lines of what some people have been saying about having more info in the MIBs themselves as to how a manager must use the mib object, but cannot clutter up the ifMib with too much info which could be potentially available in the MIBs for that media type in the transmission/experimental group.... btw, what about redundant links ? it would be good if they were monitorable atleast...(i could do it in the private extensions in the worst case) .arun   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08039; 4 Oct 93 16:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08035; 4 Oct 93 16:22 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26824; 4 Oct 93 16:22 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 16:22:26 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA02365 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Mon, 4 Oct 1993 13:22:19 -0700 Message-Id: <199310042022.AA02365@hubbub.cisco.com> To: "Arun V. Mahajan" Cc: snyder@cisco.com, if-mib@thumper.bellcore.com Subject: Re: ifOperStatus In-Reply-To: Your message of "Mon, 04 Oct 93 15:09:19 EDT." <9310041909.AA04034@hutch.proteon.com> Date: Mon, 04 Oct 93 13:22:19 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder > >Suggestion: > > > > down-administrative > > down-communcation-failed > > down-no-demand > > down-unknown > > > >It would help the management people to color their icons with a bit > >more data about the status of a link. > > > >Thoughts? > > > >Robert > > Yes, this is in the lines of what some people have been saying about having > more info in the MIBs themselves as to how a manager must use the mib object, > > but cannot clutter up the ifMib with too much info which could be potentially > available in the MIBs for that media type in the transmission/experimental > group.... I think it would be a mistake to push generic info back to the individual media MIBs. Seems like all interfaces can be administratively down vs down due to a communication failure. I would not say that only serial media can be a demand link, even though that is what the market delivers today. I think generic interface information belongs in this MIB. Oh well. Odd man out I guess. Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08816; 4 Oct 93 16:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08812; 4 Oct 93 16:59 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27580; 4 Oct 93 16:59 EDT Received: from atlas.xylogics.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 16:59:12 EDT Received: from spock.xylogics.com by atlas.xylogics.com with SMTP id AA16670 (5.65c/UK-2.1-930726); Mon, 4 Oct 1993 17:00:18 -0400 Received: by spock.xylogics.com id AA02400 (4.1/UK-2.1-921215); Mon, 4 Oct 93 16:57:41 EDT Message-Id: <2400.9310042057@spock.xylogics.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jim Barnes Date: Mon, 4 Oct 1993 16:57:40 EDT In-Reply-To: kzm@hls.com (Keith McCloghrie) "Re: Call for concensus" (Oct 3, 10:42pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Keith McCloghrie Subject: Re: Call for concensus Cc: if-mib@thumper.bellcore.com I wrote: } > First, just a clarification to make sure I understand the issue, in section } > 3.2.1, the third paragraph on page 11 of the Sept. 20 version, I find } > the following: } > } > "... The vital constancy requirement is met by } > requiring that after an interface is dynamically removed, its } > ifIndex value is not re-used (by another dynamically added } > interface) until after the following re-initialization of the } > network management system." } > } > Does this mean that if I have a dynamic interface established over } > a particular physical port, if the interface is removed and then } > the same physical port is used to establish a new interface at some } > future time, the ifIndex value for the new interface will be different } > than the ifIndex value for the first interface over that physical port? Keith McCloghrie responded: } If the same interface is re-established, then it can use the same } ifIndex value. If a different interface is established, it uses a new } ifIndex value. (where by "interface", I mean the sub-layer referred } to by the ifEntry). Would changing "by another dynamically added" to } "by a different dynamically added" make the wording clearer ? Keith, I guess that "different dynamically added" doesn't help me. Maybe I'm being dense, but I don't know how "different" is defined. And, now the agent needs to remember the info for the most recent dynamic interface defined for each physical interface in order to determine whether the new dynamic interface is "different" from the previous one. Jim Barnes (barnes@xylogics.com)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10598; 4 Oct 93 18:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10594; 4 Oct 93 18:34 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa29635; 4 Oct 93 18:34 EDT Received: from mail.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 4 Oct 93 18:02:55 EDT Received: from freeze (freeze.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA25518; Mon, 4 Oct 1993 17:58:37 -0400 Return-Path: Received: by freeze (4.1/4.7) id AA06246; Mon, 4 Oct 93 18:08:38 EDT Date: Mon, 4 Oct 93 18:08:38 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Masuma Ahmed X-Station-Sent-From: freeze.bellcore.com Message-Id: <9310042208.AA06246@freeze> To: kzm@hls.com Subject: re: AAL and other issues Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com, salil@freeze.bellcore.com, hv@freeze.bellcore.com, scf@freeze.bellcore.com Keith, > > However, having separate ifEntries still do not solve all the AAL issues that > > have been discussed in earlier emails. For example, > > the interpretation of the ifSpeed for AAL, > > The definition of ifSpeed in the if-mib wg's Internet Draft addresses > this issue. It seems that ambiguity still remains even when we use the current definition of ifSpeed for AAL. The ambiguity exists because of the way the AAL is modeled in the ATM MIB and also because of the ifSpeed definition. Based on the IETF July meeting agreement, AAL is modeled per ATM interface and not per virtual connection. Therefore, it is required to aggregate AAL information (by AAL type) for all virtual connections (that carry a specific AAL type) per ATM interface. Such aggregation makes the interpretation of ifSpeed for AAL less clear. For example, - Each AAL is carried over a virtual connection and not per interface. Accordingly, the ATM cell traffic parameters (e.g., peak cell rate, sustained cell rate) are specified per virtual connection and not per interface. One can derive the AAL traffic parameters for the virtual connection from the associated ATM cell traffic parameters. However, it is not clear how one can derive the AAL traffic parameters for each ATM interface by aggregating the virtual connections (that carry a specific AAL type) information. This is because the ATM traffic parameters such as peak cell rates are not usually additive. Recognizing the above problem and following the ifSpeed definition in the if-mib which is: "An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth. If the bandwidth of the interface is greater than the maximum value reportable by this object then this object should report its maximum value (2,147,483,647) and ifHighSpeed must be used to report the interface's speed. For a sub-layer which has no concept of bandwidth, this object should be zero." we can say that AAL ifSpeed should be the nominal bandwidth (since AAL ifSpeed cannot be estimated accurately). However, what is the nominal speed of AAL for each ATM interface? How do we estimate it (i.e., what algorithm do we use and used in a consistent manner for all interfaces and for all AAL types) ? An alternative would be to model each AAL per virtual connection and not per interface. Any insight will be helpful. > > the correlation between the > > AAL failure and the virtual connection (used for carrying the AAL) failure, > > The failure of a VC does not cause a failure of the AAL sub-layer. > I see no problem here. Thanks for pointing out the error. The correct text should read: "the correlation between the AAL traffic load counter being zero (i.e., no packets received) and the virtual connection (used for carrying the AAL) failure" There are potentially three independent reasons for AAL traffic counter to be zero (besides physical layer failure): (1) AAL failure, (2) virtual connection failure, and (3) misconfigured VPI/VCI values. However, since the model does not provide any correlation between AAL and virtual connection, the network management applications have to be sophisticated enough to use some alternative methods (not sure what are those methods could be !) to isolate AAL-related problems that are caused by problems at the virtual connection level. Note that, even though the current network management trend is to use more proactive tools than reactive ones, our AAl model supports reactive NM actions only. An alternative would be to model AAL per virtual connection and include the AAL/virtual connection correlation information in the model. > > the types of AAL performance monitoring parameters, > > Well, the ifTable counters for the AAL sub-layer count AAL frames. Admitted that the ifTable counters for the AAL sub-layer count AAL frames, my question was more towards identifying the types of AAL performance monitoring (PM) parameters that we need to monitor, i.e., do we need to support all or a subset of the PM counters that ATM Forum B-ICI specification has specified for each AAL type. Also, do we need to support simple counters or threshold-based counters or both? I guess this boils down to the question of what do we need to manage for AAL. Any insight will he helpful. > > and the > > interpretation of the ifOutUcastPkts (which has a different meaning > > from that provided in the ifMIB draft proposal), have yet to > > be resolved. > > ifOutUCastPkts is defined by the if-mib's Internet Draft. It cannot have > a different meaning. Since ifOutUCasePkts cannot have a different meaning other than the one defined in if-mib, a way to support AAL transmit counter (the definition of which is different from the ifOutUCastPkts) needs to be determined. > > Given that there are quite a few outstanding issues, can we > > propose to take out AAL from the ATM MIB at the present time and > > consider them for further study ? > > Please identify which MIB objects you would propose to remove. > [Also note that leaving AAL out would go against the spirit/letter > of this wg's charter.] If we can resolve the outstanding issues described above, I think we will be able to include AAL into the ATM MIB. However, my preference will be to study the AAL issues carefully before hastily incorporating AAL into the ATM MIB especially since services defined over AAL at an ATM UNI have yet to be worked on. > > Most of the counters specified in the interfaces > > draft proposal (9/23/93) are not > > applicable to the ATM interface. However, since ATM interface > > is a packet interface, they are required to be included in > > the ATM MIB with null values. Using "0" for these counters > > could be misleading unless the network management applications > > are sophisticated enough to interpret them as not being supported. > > I proposed that the ATM layer should be considered as a character-oriented > interface, and there was one objection. Can you refute that objection ?? I agree with Ken Rodemann's objection. However, some of his arguments can be addressed but the resolutions do not appear to be very clean. I plan to address them in a separate mail. > > Also, the interpretations of the ifOutUcastPkts for ATM cells > > and for AAL packets are not the same as defined in > > the interfaces draft. Is it possible for the description clause > > to include both definitions and use only the definition > > which is applicable to the specific interface ? > > As mentioned above, a media-specific MIB is NOT allowed to redefine > ifOutUcastPkts (or any other ifTable object). The current ATOM-MIB > needs to be fixed in this respect. [Note that even if an implementation > can only count packets transmitted, it can still respond with the correct > value of ifOutUcastPkts by subtracting the values of ifOutErrors and > ifOutDiscards from its count of packets transmitted.] Many ATM devices especially ATM switches will not be able to count ifOutErrors and ifOutDiscards per interface because of their specific implementations. Therefore, ifOutUcastPkts cannot be derived using the method you mentioned. > > Also, is it possible to define > > a separate compliance statement for ATM -like interfaces > > for which only a subset of the packet counters is applicable ? > > Just for ATM interfaces, no. > > > Alternatively, can we use only the General Group for ATM cell and the AAL and > > define the respective counters in the ATM MIB ? > > This would effectively define ATM and AAL as bit-oriented interfaces. > I don't think so. I plan address this in a separate mail. > > Traps : I agree with your comments on the trap-related issues. ifLinkUpDownTrapEnable can be specified the way the FR MIB has done to include different implementations. What do you think ? Thanks for all your valuable comments. Masuma mxa@mail.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18704; 5 Oct 93 0:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18700; 5 Oct 93 0:08 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05360; 5 Oct 93 0:08 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 00:08:15 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA14467; Mon, 4 Oct 93 21:08:02 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA05751; Mon, 4 Oct 93 20:52:25 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310050352.AA05751@nms.hls.com> Subject: Re: ifOperStatus To: Robert Snyder Date: Mon, 4 Oct 93 20:52:24 PDT Cc: axm@proteon.com, snyder@cisco.com, if-mib@thumper.bellcore.com In-Reply-To: <199310042022.AA02365@hubbub.cisco.com>; from "Robert Snyder" at Oct 04, 93 1:22 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] >>>Suggestion: >>> >>> down-administrative >>> down-communcation-failed >>> down-no-demand >>> down-unknown >>> >>>It would help the management people to color their icons with a bit >>>more data about the status of a link. >> >> Yes, this is in the lines of what some people have been saying about having >> more info in the MIBs themselves as to how a manager must use the mib object, >> >> but cannot clutter up the ifMib with too much info which could be potentially >> available in the MIBs for that media type in the transmission/experimental >> group.... > > I think it would be a mistake to push generic info back to the > individual media MIBs. > > Seems like all interfaces can be administratively down vs down due > to a communication failure. I would not say that only serial media can be > a demand link, even though that is what the market delivers today. > I think generic interface information belongs in this MIB. I agree, and it seems like a useful addition. Does anyone object ? Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18719; 5 Oct 93 0:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18715; 5 Oct 93 0:13 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05465; 5 Oct 93 0:13 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 00:13:30 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA14543; Mon, 4 Oct 93 21:13:18 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA05765; Mon, 4 Oct 93 20:57:40 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310050357.AA05765@nms.hls.com> Subject: Re: ifOperStatus To: "Arun V. Mahajan" Date: Mon, 4 Oct 93 20:57:40 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <9310041436.AA03937@hutch.proteon.com>; from "Arun V. Mahajan" at Oct 4, 93 10:36 am Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > Is there any provision for the case of redundant interfaces (in ifOperStatus > for starters) ? > For example, if there exists a redundant WAN link, acting as a backup link to > another link that is configured, and this link is usually in a standby mode, > then how does it look from the SNMP perspective ? or is this an implementation > issue? > Is it ok to set the 'ifOperStatus' to unknown(4) in this case? Using unknown(4) doesn't seem very helpful. How about the downNoDemand(x) which Robert suggested ? Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19744; 5 Oct 93 1:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19740; 5 Oct 93 1:16 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06386; 5 Oct 93 1:16 EDT Received: from UTKVX3.UTK.EDU by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 01:16:10 EDT Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-13 #4157) id <01H3QHA1GJWG8Y5DPD@utkvx.utk.edu>; Tue, 5 Oct 1993 01:14:59 EDT Date: Tue, 05 Oct 1993 01:14:58 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utk.edu Subject: Re: Call for concensus To: kzm@hls.com Cc: if-mib@thumper.bellcore.com Message-Id: <01H3QHA1K1AA8Y5DPD@utkvx.utk.edu> X-Vms-To: IN%"kzm@hls.com" X-Vms-Cc: IN%"if-mib@thumper.bellcore.com",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >> Second, some of the enumerated values for ifType are "ddn-x25(4)", >> "iso88026-man(10)", etc. My interpretation of RFC1452 (Coexistence >> between SNMPv1 and SNMPv2) is that these names are illegal for SNMPv2 >> MIBs. >Thanks. I'll fix the labels. i agree ... i was going to suggest that in my long review, but it got dropped due to one of those pesky "typos" [that is, i support this change heartily] regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03480; 5 Oct 93 10:01 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03476; 5 Oct 93 10:01 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03469; 5 Oct 93 10:01 EDT Received: from thumper.bellcore.com by IETF.CNRI.Reston.VA.US id aa00587; 5 Oct 93 5:55 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for if-mib-list@netrix.com; Tue, 5 Oct 93 02:10:16 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA20323; Mon, 4 Oct 93 23:10:02 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA06074; Mon, 4 Oct 93 22:54:24 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310050554.AA06074@nms.hls.com> Subject: re: AAL and other issues To: Masuma Ahmed Date: Mon, 4 Oct 93 22:54:23 PDT Cc: kzm@hls.com, atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9310042208.AA06246@freeze>; from "Masuma Ahmed" at Oct 4, 93 6:08 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] Masuma, > - Each AAL is carried over a virtual connection and not per interface. I think this is where the difficulties you see are coming from. An ifEntry is intended to apply to a whole sub-layer, not to individual connections. By using the phrase "each AAL", you are implicitly thinking of the virtual connections. I suggest we instead think of the AAL sub-layer (for the purposes of the ifEntry) as purely a segmentation/re-assembly engine. As such the AAL sub-layer need have no concept of bandwidth. (We don't loose anything with this, since management of bandwidth can be dealt for the whole interface at the physical layer, and for each connection at the ATM layer). Thus, I suggets ifSpeed for the AAL sub-layer is 0. > > The failure of a VC does not cause a failure of the AAL sub-layer. > > I see no problem here. > > Thanks for pointing out the error. The correct text should read: > > "the correlation between the AAL traffic load counter being zero > (i.e., no packets received) and the virtual connection > (used for carrying the AAL) failure" > AAL traffic counter to be zero (besides physical layer > failure): (1) AAL failure, (2) > virtual connection failure, and (3) misconfigured VPI/VCI values. Again if we think of the AAL sub-layer as being a segmentation/re-assembly engine, then AAL sub-layer errors are segmentation and re-assembly errors. Virtual connection failures and unknown VPI/VCIs are counted at the ATM layer. If the AAL traffic load counter is zero when there should be traffic, then: if the segmentation and re-assembly error counter(s) are non-zero, there's the problem; else, look to the ATM layer for the failure. > > > the types of AAL performance monitoring parameters, > > > > Well, the ifTable counters for the AAL sub-layer count AAL frames. > > Admitted that the ifTable counters for the AAL sub-layer count AAL > frames, my question was more towards identifying the types of AAL performance > monitoring (PM) parameters that we need to monitor, i.e., > do we need to support all or a subset of > the PM counters that ATM Forum B-ICI specification > has specified for each AAL type. Also, do we need to support > simple counters or threshold-based counters or both? I guess this > boils down to the question of what do we need to manage for AAL. Any > insight will he helpful. I haven't looked at the PM paramaters of the B-ICI, but RMON is just about the only SNMP MIB which provides thresholds, and RMON's thresholds are done in a way that can do thresholds on any MIB object in the agent's MIB. I suggest we do not need thresholds in an ATM MIB. > If we can resolve the outstanding issues described above, I think > we will be able to include AAL into the ATM MIB. However, > my preference will be to study the AAL issues carefully > before hastily incorporating AAL into the ATM MIB especially since > services defined over AAL at an ATM UNI have yet to be worked on. So, let's see if we can get the AAL layer represented as an ifEntry and be judicious about what other objects we define for it. > > As mentioned above, a media-specific MIB is NOT allowed to redefine > > ifOutUcastPkts (or any other ifTable object). The current ATOM-MIB > > needs to be fixed in this respect. [Note that even if an implementation > > can only count packets transmitted, it can still respond with the correct > > value of ifOutUcastPkts by subtracting the values of ifOutErrors and > > ifOutDiscards from its count of packets transmitted.] > > Many ATM devices especially ATM switches > will not be able to count ifOutErrors and > ifOutDiscards per interface because of their specific implementations. > Therefore, ifOutUcastPkts cannot be derived using the method you mentioned. My interpretation of what you say is that some implementations do not recognize any errors, nor discard any cells, at their output interfaces. For such implementations, ifOutErrors and ifOutDiscards are both 0, and thus, there's no problem. > I agree with your comments on the trap-related issues. > ifLinkUpDownTrapEnable can be specified the way > the FR MIB has done to include different implementations. > What do you think ? All I see in the FR MIB is "setting ifLinkUpDownTrapEnable is implementation specific". I don't understand what that means, unless it's saying that implementations may support ifLinkUpDownTrapEnable as read-only. This is probably a good suggestion, but it shouldn't be FR-specific. If it's appropriate, then the ifmib's compliance statements should say this. Comments ? Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03696; 5 Oct 93 10:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03692; 5 Oct 93 10:03 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03852; 5 Oct 93 10:03 EDT Received: from thumper.bellcore.com by IETF.CNRI.Reston.VA.US id aa01111; 5 Oct 93 7:57 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 07:56:41 EDT Received: by ftp.com id AA26701; Tue, 5 Oct 93 07:56:51 -0400 Date: Tue, 5 Oct 93 07:56:51 -0400 Message-Id: <9310051156.AA26701@ftp.com> To: kzm@hls.com Subject: Re: ifOperStatus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: snyder@cisco.com, axm@proteon.com, snyder@cisco.com, if-mib@thumper.bellcore.com I am vaguely concerned that we might be opening up a small hole through which an entire army of down-because, up-because, not-quite-up-but-nearly-there and i-am-not-quite-sure-but-i-think-i-am-up-unless-it-is-tuesday-in-which- case-i-am-testing states. Here's an alternative. Why don't we keep the broad up/down states that we have and add an OID to contain additional, media-specific diagnostic information? >>>> down-administrative >>>> down-communcation-failed >>>> down-no-demand >>>> down-unknown >>>> >>>>It would help the management people to color their icons with a bit >>>>more data about the status of a link. >>> >>>Yes, this is in the lines of what some people have been saying about having >>>more info in the MIBs themselves as to how a manager must use the mib object, >>> >>>but cannot clutter up the ifMib with too much info which could be potentially >>>available in the MIBs for that media type in the transmission/experimental >>>group.... >> >> I think it would be a mistake to push generic info back to the >> individual media MIBs. >> >> Seems like all interfaces can be administratively down vs down due >> to a communication failure. I would not say that only serial media can be >> a demand link, even though that is what the market delivers today. >> I think generic interface information belongs in this MIB. > >I agree, and it seems like a useful addition. Does anyone object ? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04700; 5 Oct 93 10:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04696; 5 Oct 93 10:48 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05256; 5 Oct 93 10:48 EDT Received: from Shiva.COM by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 10:48:46 EDT Received: by Shiva.COM (1.34b) Tue, 5 Oct 93 10:48:37 EDT Date: Tue, 5 Oct 93 10:48:37 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Phil Budne Message-Id: <9310051448.AA19079@Shiva.COM> To: if-mib@thumper.bellcore.com Subject: ifExtnsChipSet Cc: phil@shiva.com > To: if-mib@thumper.bellcore.com > Subject: amsterdam minutes > Date: Tue, 20 Jul 93 16:10:19 -0400 > From: tob@jeff.bellcore.com > > This is my draft of the minutes of the amsterdam meeting > of the WG. Let me know if I've forgotten or mis-remembered > anything. > .... > 8. Support of ifExtns (from RFC1229) > There has been some modest implementation of RFC 1229 > expressed by two members of the WG. > Ted Brunner will poll the ietf mailing list for any other > implementation experience with it. > > Agreement was reached about the objects in Sections 8.1-8.3, > but these agreements will be verified on the mailing list. > Ted Brunner will send out the appropriate messages pointing out > the level of agreement on these issues, > and poll the mailing list for any dissagreements. > > 8.1. ifExtnsTable > Resolution: ifExtnsRevWare, ifExtnsChipSet are deleted. > ifExtnsPromiscuous is kept. > Place it into the packet compliance group, > and move its oid into the ifTable, and remove Extns from its new name. .... I don't recall any announcement, poll, or discussion other than the above. Was there? from draft-ietf-ifmib-evolution-02.txt; (7) Per the working group meeting in Amsterdam, ifExtnsRevWare and ifExtnsChipSet were deleted from the MIB on the basis that their exact use is very unclear. It is quite possible in many interface architectures to "mix and match" chipsets and drivers, leading to ambiguity as to the intended contents of these objects. The use of the ifExtnsChipSets seems clear and straightforward for MIBs which define such objects. If the problem is with the interaction of the two object's values (mixing and matching) then why not delete just one (my choice would be to keep 'ChipSet). While I found the objects a pain to implement, they are just the sort of information I want to see when something sick starts happening on my net!   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06092; 5 Oct 93 11:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06088; 5 Oct 93 11:44 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06689; 5 Oct 93 11:44 EDT Received: from datanet.tele.fi by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 11:44:05 EDT Message-Id: <9310051544.AA10764@thumper.bellcore.com> Received: from datanet.tele.fi by datanet.tele.fi id <27230-0@datanet.tele.fi>; Tue, 5 Oct 1993 17:42:26 +0200 To: kzm@hls.com Cc: mxa@mail.bellcore.com, kzm@hls.com, atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9310050554.AA06074@nms.hls.com> "kzm@hls.com" Subject: re: AAL and other issues Date: Tue, 5 Oct 1993 17:42:26 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi what is the latest version of the atm mib? the latest i have seen was from august and there was a sepate mib objects for aal1 and aal345. what is the text where the inferface stuff is fixed or is there any? i would like to see how the proposed mib now looks like before being able to continue the discussion. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06400; 5 Oct 93 12:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06396; 5 Oct 93 12:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07188; 5 Oct 93 12:10 EDT Received: from flash.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 11:35:43 EDT Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA03951; Tue, 5 Oct 93 11:35:42 -0400 Received: from by eve (4.1/4.7) id AB28247; Tue, 5 Oct 93 11:37:34 EDT Date: Tue, 5 Oct 93 11:37:34 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9310051537.AB28247@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Keith McCloghrie , Masuma Ahmed Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: MIN-ACCESS ifLinkUpDownTrapEnable Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com At 10:54 PM 10/4/93 -0700, Keith McCloghrie wrote: >> I agree with your comments on the trap-related issues. >> ifLinkUpDownTrapEnable can be specified the way >> the FR MIB has done to include different implementations. >> What do you think ? > >All I see in the FR MIB is "setting ifLinkUpDownTrapEnable is >implementation specific". I don't understand what that means, unless >it's saying that implementations may support ifLinkUpDownTrapEnable as >read-only. This is probably a good suggestion, but it shouldn't be >FR-specific. If it's appropriate, then the ifmib's compliance >statements should say this. Comments ? > >Keith. very good suggestion. this also comes in handy for sonetMIB. kaj 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07609; 5 Oct 93 13:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07604; 5 Oct 93 13:05 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08314; 5 Oct 93 13:05 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 12:28:12 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA10596; Tue, 5 Oct 93 09:27:52 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA08136; Tue, 5 Oct 93 09:12:11 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310051612.AA08136@nms.hls.com> Subject: re: AAL and other issues To: Juha Heinanen Date: Tue, 5 Oct 93 9:12:10 PDT Cc: kzm@hls.com, mxa@mail.bellcore.com, atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9310051543.AA08397@lanslide.hls.com>; from "Juha Heinanen" at Oct 5, 93 5:42 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] Juha, > what is the latest version of the atm mib? the latest i have seen was > from august and there was a sepate mib objects for aal1 and aal345. I believe draft-ietf-atommib-atm-00.txt of 9 August is the latest. However, there has been consensus on a number of changes since then (e.g., to separate AAL5, and not to do AAL3/4 in this MIB.) > what is the text where the inferface stuff is fixed or is there any? draft-ietf-ifmib-evolution-03.txt of 26 September is the latest, with a few minor changes/typos since. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07946; 5 Oct 93 13:25 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07942; 5 Oct 93 13:25 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08712; 5 Oct 93 13:25 EDT Received: from datanet.tele.fi by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 13:25:45 EDT Message-Id: <9310051725.AA19088@thumper.bellcore.com> Received: from datanet.tele.fi by datanet.tele.fi id <27554-0@datanet.tele.fi>; Tue, 5 Oct 1993 19:25:42 +0200 To: mxa@mail.bellcore.com Cc: kzm@hls.com, atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com, salil@freeze.bellcore.com, hv@freeze.bellcore.com, scf@freeze.bellcore.com In-Reply-To: <9310042208.AA06246@freeze> "mxa@mail.bellcore.com" Subject: re: AAL and other issues Date: Tue, 5 Oct 1993 19:25:42 +0200 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Juha Heinanen X-Orig-Sender: Juha.Heinanen@datanet.tele.fi i agree with masuma that we should leave the aal stuff out from the current atm mib. at least i want to see, how the aal section of the mib now looks likebefore saying ok to it. i don't understand why we can't treat the aal's as application protocols over atm and then define for each aal its own mib. if we include aal1, aal34 and aal5, we also have to include fr-sscs and sscop which according to itu belong to the aal layer. -- juha   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09143; 5 Oct 93 14:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09139; 5 Oct 93 14:32 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10092; 5 Oct 93 14:32 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 14:33:01 EDT Received: from via.ccb3.merit.edu by vela.acs.oakland.edu with SMTP id AA01413 (5.65c+/IDA-1.4.4); Tue, 5 Oct 1993 14:31:59 -0400 Date: Tue, 5 Oct 93 14:01:13 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1464.bill.simpson@um.cc.umich.edu> To: if-mib@thumper.bellcore.com Reply-To: bsimpson@morningstar.com Subject: Re: ifOperStatus > I am vaguely concerned that we might be opening up a small hole through > which an entire army of down-because, up-because, not-quite-up-but-nearly-there > and i-am-not-quite-sure-but-i-think-i-am-up-unless-it-is-tuesday-in-which- > case-i-am-testing states. > > >>>> down-administrative > >>>> down-communcation-failed > >>>> down-no-demand > >>>> down-unknown > >>>> I thought that this was pretty reasonable, particularly since we are getting so many boxes with demand dialing interfaces, so I liked the downNoDemand concept. I'm not sure that downAdministrative might be superfluous with ifAdminStatus already having down. We can tell whether it is down due to Admin if Admin is also down, and failure if Admin is up. How about: up down testing unknown waitingDemand We could add waitingDemand and unknown to the ifAdminStatus, too. Would that be too far down the slippery slope Frank? Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09422; 5 Oct 93 14:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09418; 5 Oct 93 14:48 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10473; 5 Oct 93 14:48 EDT Received: from monk.proteon.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 14:48:59 EDT Received: from hutch.proteon.com by monk.proteon.com (5.65/1.8) id AA13136; Tue, 5 Oct 93 14:49:16 -0400 Received: by hutch.proteon.com (4.1/SMI-4.1) id AA05744; Tue, 5 Oct 93 14:48:41 EDT Date: Tue, 5 Oct 93 14:48:41 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Arun V. Mahajan" Message-Id: <9310051848.AA05744@hutch.proteon.com> To: kzm@hls.com Subject: Re: ifOperStatus Cc: if-mib@thumper.bellcore.com, kasten@ftp.com, snyder@cisco.com >> Is there any provision for the case of redundant interfaces (in ifOperStatus >> for starters) ? >> Is it ok to set the 'ifOperStatus' to unknown(4) in this case? >Using unknown(4) doesn't seem very helpful. How about the downNoDemand(x) >which Robert suggested ? > Keith. OK, it is a good suggestion and serves my purpose, despite being too much serial-line'ish, but since it is a serial line type of interface anyway, it's ok. On the same topic, may I raise the basic point again? which is, how does it look in the SNMP perspective?? as far as other values in the IfTable ? this is probably nit-picking, a redundant interface is like none other, that's all. >Here's an alternative. Why don't we keep the broad up/down states >that we have and add an OID to contain additional, media-specific >diagnostic information? > >Frank Kastenholz There is a danger of going too much in the realm of the media mib's again in this case, isnt it? (generic-interface-extensions ). thanks, .arun   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21750; 5 Oct 93 20:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21746; 5 Oct 93 20:27 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa17024; 5 Oct 93 20:27 EDT Received: from flash.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 5 Oct 93 19:56:53 EDT Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA12851; Tue, 5 Oct 93 19:56:52 -0400 Received: from by eve (4.1/4.7) id AB04264; Tue, 5 Oct 93 19:58:43 EDT Date: Tue, 5 Oct 93 19:58:43 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9310052358.AB04264@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: re: AAL and other issues At 7:25 PM 10/5/93 +0200, Juha Heinanen wrote: >i agree with masuma that we should leave the aal stuff out from the >current atm mib. at least i want to see, how the aal section of the mib >now looks likebefore saying ok to it. > >i don't understand why we can't treat the aal's as application protocols >over atm and then define for each aal its own mib. if we include aal1, >aal34 and aal5, we also have to include fr-sscs and sscop which >according to itu belong to the aal layer. > >-- juha i believe there are a couple issues here: 1. if-mib wg is asking for consensus. thus, one of the questions for atommib is: is the current ifTable good enough for the atmmib. keith has made arguments that it is, at least for: - the atm layer, for which he proposed a relatively elegant approach with the fixed-chunk group as replacement of the characterGroup. ken made some good additional points on that which would modify the proposal slightly. - the aal5 layer. keith has made points on how the ifTable mapping can be successfully done for this purpose, without the need for another 'application mib'. ongoing discussion on this one. - we have not addressed an ifmib mapping for other aals, nor was one proposed. in fact tracy's message of a while back suggested that it may not be needed (see attached). thus, the question on for the benefit of if-mib wg is: are the atm and aal5 mapping proposals such that we are reasonably confident that the proposed ifTable is OK from this perspective? ! [NOTE: Keith's fixed-chunk approach does require a ! change in the if-mib Conformance Statement. ! Any Comments on that change?] 2.Should the need for management of other aals be addressed. Yes. As always, proposals are invited. Tracy has already made the point on how aal3/4 is managed (attached). on other aals we may decide that they dont need to be managed or they may need to be managed but the specification will not be part of the current atm mib, or,...etc. Note that there is no law that mandates that we solve all these problems simultaneously, and in the same spec. I would appreciate comments on whether the views on (1) are such that we can recommend the if-mib wg to make the fixed-chunk change, and whether any other changes are necessary from the atommib perspective. I would also like to see proposals on how to proceed with (2). kaj --------------- Tracy Brown wrote a while back: > Having one ifEntry for AAL3/4 CPCS and AAL5 CPCS > is somewhat confusing. They have very different > characteristics (e.g., ifMTU). Modeling them as a > single ifEntry causes problems. But actually, > there may be no need to model them as a single entry. > > The only time I think it is necessary to model > AAL CPCS layer, as an ifEntry > in the Interfaces Group with a unique > ifType value, > is when it is directly under an internetwork layer, > (e.g., IP or LLC/SNAP directly on top of AAL5) > Otherwise, I think it may be redundant. > > 1 The one major application for AAL3/4 is SIP Level 3 (SMDS), > There seems no reason to monitor AAL3/4 CPCS when SMDS SIP > Level 3 is directly on top of it. We can monitor SIP Level 3 > with an ifEntry on its own (i.e., ifType = sip) and have > an ifEntry with atm > under it. > 2 For the case of Frame Relay, again there is no need to > monitor the AAL5 CPCS layer in the Interfaces group. > Again, we can monitor Frame Relay with an ifEntry of its own > (i.e., frame-relay) and have an ifEntry with atm under it. > 3 If an internet level protocol (IPX, IP, etc.) runs on top of > AAL5, > it is useful to have the ifTable kind of packet statistics. > > For the first two cases the AAL CPCS is only > an adaptation layer to put SMDS or FR into ATM. > I would imagine that you would already be monitoring > the Frame Relay level and SMDS SIP Level 3 with an ifEntry and > would not really need an ifEntry for the AAL CPCS. > > My suggestion is that we simplify the AAL/ifTable mapping > by having only AAL5 counts for the third case, and no AAL3/4 counts. 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00818; 6 Oct 93 3:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00814; 6 Oct 93 3:37 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02025; 6 Oct 93 3:37 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 03:37:14 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA18400; Wed, 6 Oct 93 00:37:00 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA10507; Wed, 6 Oct 93 00:21:16 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310060721.AA10507@nms.hls.com> Subject: Re: Call for concensus To: Jim Barnes Date: Wed, 6 Oct 93 0:21:15 PDT Cc: kzm@hls.com, if-mib@thumper.bellcore.com In-Reply-To: <2400.9310042057@spock.xylogics.com>; from "Jim Barnes" at Oct 4, 93 4:57 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > I guess that "different dynamically added" doesn't help me. Maybe I'm being > dense, but I don't know how "different" is defined. And, now the agent > needs to remember the info for the most recent dynamic interface defined > for each physical interface in order to determine whether the new dynamic > interface is "different" from the previous one. The rationale for the requirement is that a management station may not notice that one interface went away and another came into existence. Thus, the management station might difference the counter values retrieved on successive polls and get some strange values. We already have the concept that an ifIndex value can change upon a restart of the agent (i.e., when sysUpTime goes to zero). The intent is to have one ifIndex value not mean two things between restarts. You are correct in pointing out that "different" is hard to define, and there will be all kinds of gray areas. I suspect that any firm definition we come up with now would in all likelihood turn out to be inadequate. Thus, my preference is not to give a firm definition, but instead to explain the reasoning behind the definition and let implementors choose what "different" means in their particular situation. Now, in case you find that unsatisfactory, I offer the following guidelines: A previously-unused value of ifIndex should be assigned to a dynamically added interface if: 1. the assignment of a previously-used ifIndex value to the interface could result in a discontinuity in the values of ifTable counters for that value of ifIndex, or, 2. an agent has no knowledge of whether the interface is the "same" or "different" to a previously incarnated interface. Would adding these to the document help ? Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00907; 6 Oct 93 4:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00903; 6 Oct 93 4:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02412; 6 Oct 93 4:09 EDT Received: from thuer.netcs.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 04:09:38 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA12445; Wed, 6 Oct 1993 09:09:25 +0100 Received: by keks.netcs.com (5.65/25-eef) id AA00866; Wed, 6 Oct 93 09:09:21 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9310060809.AA00866@keks.netcs.com> Subject: Re: ifOperStatus To: bsimpson@morningstar.com Date: Wed, 6 Oct 93 9:09:20 MET Cc: if-mib@thumper.bellcore.com In-Reply-To: <1464.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Oct 5, 93 2:01 pm X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 > > > I am vaguely concerned that we might be opening up a small hole through > > which an entire army of down-because, up-because, not-quite-up-but-nearly-there > > and i-am-not-quite-sure-but-i-think-i-am-up-unless-it-is-tuesday-in-which- > > case-i-am-testing states. > > > > >>>> down-administrative > > >>>> down-communcation-failed > > >>>> down-no-demand > > >>>> down-unknown > > >>>> > > I thought that this was pretty reasonable, particularly since we are > getting so many boxes with demand dialing interfaces, so I liked > the downNoDemand concept. > > I'm not sure that downAdministrative might be superfluous with > ifAdminStatus already having down. We can tell whether it is down > due to Admin if Admin is also down, and failure if Admin is up. > > How about: > up > down > testing > unknown > waitingDemand > > We could add waitingDemand and unknown to the ifAdminStatus, too. > > Would that be too far down the slippery slope Frank? > > Bill.Simpson@um.cc.umich.edu > Sorry -- can somebody repeat the reasons for not having a 'calling' state? Too general? Too european? Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02674; 6 Oct 93 8:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02670; 6 Oct 93 8:58 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07245; 6 Oct 93 8:58 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 08:58:48 EDT Received: by ftp.com id AA11513; Wed, 6 Oct 93 08:59:00 -0400 Date: Wed, 6 Oct 93 08:59:00 -0400 Message-Id: <9310061259.AA11513@ftp.com> To: okorf@netcs.com, bsimpson@morningstar.com, if-mib@thumper.bellcore.com Subject: Re: ifOperStatus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com First, a bit of architectural principle: Perfection is finally obtained not when there is no longer anything to add but when there is no longer anything to take away. Now, we are discussing whether to add more states/values to ifOperStatus. We really have two choices here. We can 1) Add more values, but which values? What are their exact meanings? How do they apply to the Frotz interface? and so on. First, there is the problem of which variables (or "when do we stop") There was a list recently posted which had 3 different "down" states: Administrative, Communication-failed, and no-demand. It also had an unknown state (originally called down-unknown -- but I am presuming that if the state is unknown then it is hard to say whether it is down...). Then Bill Simpson posted a list (in response to my posting) which had up, down, testing, unknown, and waitingDemand. Then Oliver Korfmacher asked about why we do not have a calling state. I am sure that other suggestions will be made over time. Right now we have traps defined for when an interface changes state (LinkUp and LinkDown). If we go from one type of down to another, do we issue a trap or not? If we go from up to down-no-demand, is a trap necessary? or we can 2) Keep ifOperStatus as simple as possible and then add additional, "clarifying" variables. I propose that ifOperStatus be kept as it is, perhaps with the addition of Unknown (though I'll get to that in a minute) and we add a single OID object called something like ifStatusInformation which contains (or may contain) an OID that further clarifies the meaning of what is in ifOperStatus. There could be some "well-known" oids that are defined in the ifMib. By using OIDs we will allow proprietary and medium-specific MIBs to pass additional status information back to the manager in a common manner. This allows each specific MIB to tailor the state information that it reports to the manager to meet its (the specific MIB's) needs, rather than trying to map necessarily generic state values to a MIB's specific needs. It also might be a win for a manager station since this OID would, by definition, unambiguously identify the type of interface reporting the state, so the manager would keep a simple map of state OIDs to actions. If ifOperStatus had a rich set of states then the manager would have to map two values -- the value of ifOperStatus _and_ the type of interface (ifType -- or ifSpecific) to some action. Finally, I do not believe that a specific Unknown value in ifOperStatus is useful. If you can not tell (or at least have a good estimate) of an interface's state then you probably have other problems -- for example, how reliable are the counters that you are reporting? Are you saying that ifOutOctets is a true and accurate number, but you can not tell whether the interface is up or down? If you can not tell the interface's status, are you going to try to feed it packets to send? If so, then either the interface will report a result or not. If the interface reports a result then the interface's status is known. If it does not report a result, then the status is also known -- down. If you can not tell an interface's state and you stop sending packets to it then the interface is down. Remember, up means "ready to pass packets". If the driver, for any reason, stops passing packets (the hardware tells it "I'm broken", the operator has turned the interface off, or whatever) then the interface is down. Now, if you are doing proxy management, there might appear to be a need for Unknown -- for some reason the proxy manager can not get to the real managed object in order to determine the interface's status. Well, this is a problem with the proxy system and not with the interface MIB. By this logic, all variables in all MIBs should report Unknown whenever a proxy can not get to the real managed object. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02893; 6 Oct 93 9:17 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02889; 6 Oct 93 9:17 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07863; 6 Oct 93 9:17 EDT Received: from thuer.netcs.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 09:17:55 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA13748; Wed, 6 Oct 1993 14:17:49 +0100 Received: by keks.netcs.com (5.65/25-eef) id AA02537; Wed, 6 Oct 93 14:17:44 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9310061317.AA02537@keks.netcs.com> Subject: Re: ifOperStatus To: kasten@ftp.com Date: Wed, 6 Oct 93 14:17:42 MET Cc: okorf@netcs.com, bsimpson@morningstar.com, if-mib@thumper.bellcore.com In-Reply-To: <9310061259.AA11513@ftp.com>; from "Frank Kastenholz" at Oct 6, 93 8:59 am X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 I like the ifStatusInformation OID idea. In my feeling, it allows enough flexibility without creating a chaos of ifStatus values. Nice improvement. > .. > Right now we have traps defined for when an interface changes state > (LinkUp and LinkDown). If we go from one type of down to another, do > we issue a trap or not? If we go from up to down-no-demand, is > a trap necessary? > .. > Frank Kastenholz But, what about traps? This may be beyond the scope of this discussion, but there are applications which display interface stati due to received traps. One solution would be to have the ifStatusInformation in the binding of a trap. But which one one sends if an interfaces starts the calling process on a dial-on-demand network? LinkUp is wrong, since no data flow is currently possible. LinkDown is also wrong. What about a LinkStatusChangingTrap which can be used to propagate (in ifStatusInformation and others) the progress or failure of an connect or disconnect procedure? For very fine-granular purposes, it can for example carry additional information about layer 2 or whatever establishment processes (what about ppp LCP up, IPCP up, and so on). Oliver   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05315; 6 Oct 93 11:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05311; 6 Oct 93 11:08 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11027; 6 Oct 93 11:08 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 11:08:18 EDT Received: by xap.xyplex.com id ; Wed, 6 Oct 93 13:10:04 -0500 Date: Wed, 6 Oct 93 13:10:04 -0500 Message-Id: <9310061810.AA13371@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com In-Reply-To: Oliver Korfmacher's message of Wed, 6 Oct 93 14:17:42 MET <9310061317.AA02537@keks.netcs.com> Subject: Re: ifOperStatus Frank's arguments on ifOperStatus are persuasive, I was leaning toward adding values, but he's pretty well talked me out of it. An ifStatusInformation value, with some decent standard OIDs seems like a good compromise. Without the standards, you have no interoperable meanings, and we should be able to define at least a few of those. Oliver said: >But, what about traps? I suggest that we relegate trap issues to the fine control of a manager using the SNMPv2 Manager-to-Manager MIB. That way we don't have to make any decisions about what is interesting enough to justify a trap. We only have to make sure the necessary status information is available. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05673; 6 Oct 93 11:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05666; 6 Oct 93 11:23 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11401; 6 Oct 93 11:23 EDT Received: from relay1.UU.NET by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 11:23:06 EDT Received: from tinton.ccur.com (via tinton.tinton.ccur.com) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14684; Wed, 6 Oct 93 11:22:53 -0400 Received: from bach by tinton.tinton.ccur.com SMTP/TCP Channel id aa14776; 6 Oct 93 11:21 EDT Subject: Re: ifOperStatus To: if-mib@thumper.bellcore.com Date: Wed, 6 Oct 93 15:21:46 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Greg Fisher In-Reply-To: <9310060809.AA00866@keks.netcs.com> from "Oliver Korfmacher" at Oct 6, 93 09:09:20 am X-Mailer: ELM [version 2.4dev PL52] Message-Id: <9310061121.aa14776@tinton.tinton.ccur.com> Frank and Bill say : > > > > > I am vaguely concerned that we might be opening up a small hole through > > > which an entire army of down-because, up-because, not-quite-up-but-nearly-there > > > and i-am-not-quite-sure-but-i-think-i-am-up-unless-it-is-tuesday-in-which- > > > case-i-am-testing states. .... > > > > I thought that this was pretty reasonable, particularly since we are > > getting so many boxes with demand dialing interfaces, so I liked > > the downNoDemand concept. > > > > I'm not sure that downAdministrative might be superfluous with > > ifAdminStatus already having down. We can tell whether it is down > > due to Admin if Admin is also down, and failure if Admin is up. > > > > How about: > > up > > down > > testing > > unknown > > waitingDemand I share the view that "downAdministrative" is superfluous. But, if we add to ifOperStatus: idle - up, no circuits, connections, listeners in-use - up, not idle Something like this might accommodate our serial interfaces without seeming to be too interface-specific. The discussion proves that there is some demand for more "interesting" status data, but it will probably stall if we start to include terms which cannot be applied with reasonable generality. > > We could add waitingDemand and unknown to the ifAdminStatus, too. > > > > Would that be too far down the slippery slope Frank? Whoops! Greg Fisher - Concurrent Computer fisher@tinton.ccur.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07411; 6 Oct 93 12:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07406; 6 Oct 93 12:50 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13981; 6 Oct 93 12:50 EDT Received: from dustbin.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 12:50:26 EDT Received: from glare.cisco.com by dustbin.cisco.com with SMTP id AA20150 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Wed, 6 Oct 1993 09:50:20 -0700 Message-Id: <199310061650.AA20150@dustbin.cisco.com> To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Subject: Re: ifOperStatus In-Reply-To: Your message of "Wed, 06 Oct 93 08:59:00 EDT." <9310061259.AA11513@ftp.com> Date: Wed, 06 Oct 93 09:49:04 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder Maybe it would help if I describe the problem I am trying to solve. Customers see a red ICON on their management station and would like to understand a little bit about the why if is down. Note: red seems to be the universal down status color. In cisco's private MIB we have a variable: locIfReason OBJECT-TYPE SYNTAX DisplayString ACCESS read-only STATUS mandatory DESCRIPTION "Reason for interface last status change." ::= { lifEntry 20 } That does this job, but it may be a challenge for network management stations to make use of in the general case. Demand links confuse the issue because management stations typically paint the icon red, so if you have a site with a bunch of dial-back up or demand links, the useful, "I should react if I see red" quality of these icons is lost. If I could click on the red icon and get this DisplayString, maybe that would do the job. I believe the solution belongs in this MIB. It does not have to exist specifically in ifOperStatus. Robert cisco eng   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07598; 6 Oct 93 13:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07594; 6 Oct 93 13:15 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14625; 6 Oct 93 13:15 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 13:15:51 EDT Received: by ftp.com id AA21116; Wed, 6 Oct 93 13:16:00 -0400 Date: Wed, 6 Oct 93 13:16:00 -0400 Message-Id: <9310061716.AA21116@ftp.com> To: snyder@cisco.com Subject: Re: ifOperStatus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Well, if you change the SYNTAX to be OBJECT-IDENTIFIER (EnumeratedType or whatever the TC is for enumerations) then it is pretty much the same as what I am proposing. I prefer OIDs beacause they are easily parsable by the manager and their assignment authority can be distrubuted; the if-mib group can define common values, the x25 mib group can define specific values for x.25 and so on. If we use text strings, as you do and as someone else suggested to me in a private message, we get into language and character set issues and we have the problem of ensuring that two groups do not use the same string for situations that are not identical (in other words, we'd end up inventing some kind of assignment authority distribution scheme -- which ASN.1 OIDs already have....) > locIfReason OBJECT-TYPE > SYNTAX DisplayString > ACCESS read-only > STATUS mandatory > DESCRIPTION > "Reason for interface last status change." > ::= { lifEntry 20 } > > That does this job, but it may be a challenge for network management > stations to make use of in the general case. > > Demand links confuse the issue because management stations typically > paint the icon red, so if you have a site with a bunch of dial-back up > or demand links, the useful, "I should react if I see red" quality of > these icons is lost. If I could click on the red icon and get this > DisplayString, maybe that would do the job. I would imagine that a manager would have a table that maps OIDs to things like severity levels, icon actions (unless derived from a severity level), actions (ring a bell, email the operator, self destruct), and so on. This table would allow a manager to say "Well, the interface is `down' but the `reason' OID says that the interface is waiting for an incoming call so i'll paint the icon blue and put a reason string into the icon that says `waiting for incoming call'" -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07787; 6 Oct 93 13:26 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07783; 6 Oct 93 13:26 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14907; 6 Oct 93 13:26 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 13:26:25 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA27828 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Wed, 6 Oct 1993 10:26:12 -0700 Message-Id: <199310061726.AA27828@hubbub.cisco.com> To: kasten@ftp.com Cc: snyder@cisco.com, if-mib@thumper.bellcore.com Subject: Re: ifOperStatus In-Reply-To: Your message of "Wed, 06 Oct 93 13:16:00 EDT." <9310061716.AA21116@ftp.com> Date: Wed, 06 Oct 93 10:26:11 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder Ok I agree. Your proposal solves the problem and deals nicely with what I did not like about the DisplayString solution. One last thought. Should this OID be added to the link-up/link-down varbind list. Assuming that these traps are within the scope of the new document. Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11468; 6 Oct 93 15:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11464; 6 Oct 93 15:57 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19104; 6 Oct 93 15:57 EDT Received: from UTKVX3.UTK.EDU by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 15:57:09 EDT Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-13 #4157) id <01H3SOP77GKK8Y5UVX@utkvx.utk.edu>; Wed, 6 Oct 1993 15:10:41 EDT Date: Wed, 06 Oct 1993 15:10:41 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utk.edu Subject: Re: ifOperStatus To: okorf@netcs.com Cc: if-mib@thumper.bellcore.com Message-Id: <01H3SOP77GKM8Y5UVX@utkvx.utk.edu> X-Vms-To: IN%"okorf@netcs.com" X-Vms-Cc: IN%"if-mib@thumper.bellcore.com",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >I like the ifStatusInformation OID idea. In my feeling, it allows >enough flexibility without creating a chaos of ifStatus values. >Nice improvement. i'm sorry, but i have to disagree because i don't think it is an improvement here is my thinking: there are many management stations that are able to associate a value of an enumerated integer with a "happy state" i.e., green and/or able to do a "switch" based on multiple cases, comparisons of counters or gauges with thresholds, etc all of these a based on INTEGER or INTEGER-like thingos i don't know of a single management station that can do this with OIDs, and, if it could, its performance would be much poorer this is nuts please, can't we do this in a way parallel to ifType? could you support that Oliver? regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12579; 6 Oct 93 17:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12575; 6 Oct 93 17:02 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20832; 6 Oct 93 17:02 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 17:02:55 EDT Received: by xap.xyplex.com id ; Wed, 6 Oct 93 19:04:40 -0500 Date: Wed, 6 Oct 93 19:04:40 -0500 Message-Id: <9310070004.AA22265@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com In-Reply-To: CASE@UTKVX.UTCC.UTK.EDU's message of Wed, 06 Oct 1993 15:10:41 -0400 (EDT) <01H3SOP77GKM8Y5UVX@utkvx.utk.edu> Subject: Re: ifOperStatus >i don't know of a single management station that can do this with OIDs, and, >if it could, its performance would be much poorer Does this imply that in general OIDs are not the right sort of data values to give to NMSs? Given the growing use of OIDs to define hierarchically extensible enumerations, that's a bit distressing. I can't help feeling like sometimes we over constrain some of SNMP's flexibility and power in the name of NMSs that only implement the simplest possible algorithms for comparison, interpretation, and error handling, expecting that to somehow work out into powerful, interoperable network management. Will there be a point when we can expect NMSs to get more of a clue? Directly on the issue, the ifType approach has it's problems, too. As IANA adds types, how do NMSs learn about them? I suggested using a textual convention and having IANA make that available for direct compilation, but got no responses. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14588; 6 Oct 93 18:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14584; 6 Oct 93 18:16 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23124; 6 Oct 93 18:16 EDT Received: from UTKVX3.UTK.EDU by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 18:16:22 EDT Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-13 #4157) id <01H3SU1URRSW8Y5UVX@utkvx.utk.edu>; Wed, 6 Oct 1993 17:57:26 EDT Date: Wed, 06 Oct 1993 17:57:26 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utk.edu Subject: Re: ifOperStatus To: rlstewart@xap.xyplex.com Cc: if-mib@thumper.bellcore.com Message-Id: <01H3SU1UWBRM8Y5UVX@utkvx.utk.edu> X-Vms-To: IN%"rlstewart@xap.xyplex.com" X-Vms-Cc: IN%"if-mib@thumper.bellcore.com",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT >>i don't know of a single management station that can do this with OIDs, and, >>if it could, its performance would be much poorer since i wrote this, i've been told that the snmp research nms can, in fact do this with OIDs, but that i was correct in that it is a fairly expensive operation, one that is typically done several times a second >Does this imply that in general OIDs are not the right sort of data values to >give to NMSs? Given the growing use of OIDs to define hierarchically >extensible enumerations, that's a bit distressing. >I can't help feeling like sometimes we over constrain some of SNMP's >flexibility and power in the name of NMSs that only implement the simplest >possible algorithms for comparison, interpretation, and error handling, >expecting that to somehow work out into powerful, interoperable network >management. i had the same thought when i wrote my original note, but chose to write the note anyway >Will there be a point when we can expect NMSs to get more of a clue? some have a pretty good clue on comparison, interpretation, and error handling of INTEGER values, it's just that they don't typically [yet] have these for OIDs >Directly on the issue, the ifType approach has it's problems, too. As IANA >adds types, how do NMSs learn about them? I suggested using a textual >convention and having IANA make that available for direct compilation, but got >no responses. i have no problem with the IANA publishing them as textual conventions in parseable ASN.1, however, i can understand why they'd resist such a thing i figure we'd get them the same way we get the enterprise numbers ... we fetch them periodically, and hand edit to reformat them into something a mib compiler can read ... not optimum, but workable regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15079; 6 Oct 93 18:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15075; 6 Oct 93 18:58 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24038; 6 Oct 93 18:58 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 18:58:28 EDT Received: from via.dsf2.merit.edu by vela.acs.oakland.edu with SMTP id AA21322 (5.65c+/IDA-1.4.4); Wed, 6 Oct 1993 18:58:19 -0400 Date: Wed, 6 Oct 93 16:28:56 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1476.bill.simpson@um.cc.umich.edu> To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Reply-To: bsimpson@morningstar.com Subject: Re: ifOperStatus Based on Frank's excellent analysis, I'm wondering if it wouldn't be better to deprecate the ifOperStatus entirely! After all, with the new ifStack, the top level interface could be "up" (ready to accept packets), while the bottom is "down" (waiting for dial-in, or an out-going packet to force a dial-out). This whole thing could get more complicated with VCs, and so maybe the OID is the best solution to allow future evolution. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15338; 6 Oct 93 19:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15334; 6 Oct 93 19:21 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24596; 6 Oct 93 19:21 EDT Received: from synoptics.com (pobox.synoptics.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 19:21:14 EDT Received: from immer (immer.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA09775; Wed, 6 Oct 93 16:19:35 PDT Received: by immer (4.1/2.0N) id AA06099; Wed, 6 Oct 93 16:19:01 PDT Message-Id: <9310062319.AA06099@immer> Date: Wed, 6 Oct 93 16:19:01 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Perkins To: if-mib@thumper.bellcore.com Subject: Re: ifOperStatus This thread is going over old and controversal ground on the issue of registration as exampled by ifType. This is really an SNMPv1/2 global issue. The problem is how to define an object that returns identifications when the identifications are growing over time. The two approaches that have been taken are 1) use an enumerated integer, or 2) use an OID. Both of these approaches have benefits and costs. Also, there is an underlying theme of making everything ASN.1 parsable MIB modules. With approach #1 (a global registration authority of identification), + Integers are "easier" to implement than OIDs + There is one place that keeps a complete list + High quality of assignments - privacy - turn around time on assignments - if in MIBs, version tracking, & delayed publishing updates - currently, no parsable individual descriptions of values in MIBs With approach #2 (distributed registration authorities) + Privacy + Speed of publishing determined by creator + In SNMPv2, the OBJECT-IDENTITY macro allows descriptions to be associated with each value - No one place to go to get all possible values - Currently few, if any, NMSs actually have an OID database that associates attributes such as description, etc with each OID value - OIDs are "harder" to implement than integers - Possibly low quality assignments (its distributed, quality determined locally) - The value { 0 0 } may be allowed which requires special handling - Duplication of similar values by different registration authorities In both cases, for a management application to use the object's value to make some programatic decision, it MUST have access to an associated "knowledge base". This knowledge base MUST be field extensible. It should have for each value a classification of the value. The application uses the classification of the value to determine what to do. Without a field extensible knowledge base, an application MUST be MODIFIED each time a new value is published. That's the situation as I see it. Hope this helps with the discussion. /dave perkins, synoptics, 408-764-1516   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16096; 6 Oct 93 20:27 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16092; 6 Oct 93 20:27 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26100; 6 Oct 93 20:27 EDT Received: from inet-gw-2.pa.dec.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 20:27:26 EDT Received: by inet-gw-2.pa.dec.com; id AA15904; Wed, 6 Oct 93 17:27:24 -0700 Received: by us1rmc.bb.dec.com; id AA11271; Wed, 6 Oct 93 20:26:04 -0400 Message-Id: <9310070026.AA11271@us1rmc.bb.dec.com> Received: from levers.enet; by us1rmc.enet; Wed, 6 Oct 93 20:26:23 EDT Date: Wed, 6 Oct 93 20:26:23 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anil Rijsinghani To: if-mib@thumper.bellcore.com Apparently-To: if-mib@thumper.bellcore.com Subject: Re: ifOperStatus Glad to see Jeff's and Dave Perkins' notes on some of the ramifications of using OID's rather than enumerations. Until there is a well defined method of getting OID's to work for the user, I personally believe enumerations are the correct way to go. In addition to making life more difficult for the nms as well as the end-user, there's the issue of how standard OID's are asssigned and maintained. The mechanism certainly should *not* be to "go to Jon/Joyce if you need a new OID" -- it needs to go through the MIB WG that defined it, to make sure that it makes sense at all. Mechanisms to distribute private OID's and automate their use by browsers/applications need to be documented. If the procedure isn't well thought-out, it will make the problem worse rather than the other way around. Anil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16764; 6 Oct 93 22:16 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16760; 6 Oct 93 22:16 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa28469; 6 Oct 93 22:16 EDT Received: from synoptics.com (pobox.synoptics.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 6 Oct 93 22:16:37 EDT Received: from donatello (donatello.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA10328; Wed, 6 Oct 93 19:13:46 PDT Received: by donatello (4.1/2.0N) id AA23231; Wed, 6 Oct 93 19:13:46 PDT Message-Id: <9310070213.AA23231@donatello> Date: Wed, 6 Oct 93 19:13:46 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Bierman To: if-mib@thumper.bellcore.com, anil@levers.enet.dec.com Subject: Re: ifOperStatus [...] > Until there is a well defined method of getting OID's to work for the user, > I personally believe enumerations are the correct way to go. In addition to > making life more difficult for the nms as well as the end-user, > there's the issue of how standard OID's are asssigned and maintained. > The mechanism certainly should *not* be to "go to Jon/Joyce if you need > a new OID" -- it needs to go through the MIB WG that defined it, to > make sure that it makes sense at all. Mechanisms to distribute > private OID's and automate their use by browsers/applications need > to be documented. [...] > Anil > At the Cambridge IETF meeting, the issue of OIDs vs. enumerations was discussed at length. I seem to remember the following points: 1) OIDs were preferred over enums because they could be assigned locally (i.e. privately without going through IANA) 2) OIDs would also prevent constant updating of standard MIBs in order to add new enums 3) It is allowable in SNMPv2 (but not v1) to add enums to the end of the list without deprecating and redefining an object 4) There was some concern about the semantics of the enum "other" given point (3) (the semantics of "other" change over time as enums are added to the end of the list) I think the administrative arguments are more compelling than the implementation issues...a list of enums is contained, but a hassle to maintain. A "standard" list of OIDs would still have to be globally administered and private OIDs are not likely to be supported in any generic apps. This also opens the door for vendors to impart all kinds of private semantics to standard MIB objects. If we want to promote standard, generic, inter-operable agents and applications, then I think enums are the way to go. --andy;   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05087; 7 Oct 93 10:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05083; 7 Oct 93 10:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11132; 7 Oct 93 10:10 EDT Received: from thuer.netcs.com ([192.76.152.15]) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 10:10:29 EDT Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA03008; Thu, 7 Oct 1993 15:10:23 +0100 Received: by keks.netcs.com (5.65/25-eef) id AA05712; Thu, 7 Oct 93 15:10:15 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Oliver Korfmacher Message-Id: <9310071410.AA05712@keks.netcs.com> Subject: Re: ifOperStatus To: CASE@utkvx.utk.edu Date: Thu, 7 Oct 93 15:10:15 MET Cc: okorf@netcs.com, if-mib@thumper.bellcore.com In-Reply-To: <01H3SOP77GKM8Y5UVX@utkvx.utk.edu>; from "CASE@utkvx.utk.edu" at Oct 06, 93 3:10 pm X-Mailer: ELM [version 2.2 PL0] X-Charset: ASCII X-Char-Esc: 29 > > >I like the ifStatusInformation OID idea. In my feeling, it allows > >enough flexibility without creating a chaos of ifStatus values. > >Nice improvement. > > i'm sorry, but i have to disagree because i don't think it is an improvement > here is my thinking: > there are many management stations that are able to associate a value of an > enumerated integer with a "happy state" i.e., green and/or able to do a > "switch" based on multiple cases, comparisons of counters or gauges with > thresholds, etc > > all of these a based on INTEGER or INTEGER-like thingos > > i don't know of a single management station that can do this with OIDs, and, > if it could, its performance would be much poorer > > this is nuts > > please, can't we do this in a way parallel to ifType? > > could you support that Oliver? Sorry, but: What about a compromise? The argument from Snyder@cisco that having the different (may be even vendor-specific) states of their interfaces defined in their MIBs or OID-trees sounds correct to me as well. > > > regards, > jdc > Oliver no bad comments to my LinkChangeTrap? I expected loud opposition? Or not worth to even comment? :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05415; 7 Oct 93 10:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05411; 7 Oct 93 10:18 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11324; 7 Oct 93 10:18 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 10:18:32 EDT Received: by ftp.com id AA18790; Thu, 7 Oct 93 10:18:42 -0400 Date: Thu, 7 Oct 93 10:18:42 -0400 Message-Id: <9310071418.AA18790@ftp.com> To: dperkins@synoptics.com Subject: Re: ifOperStatus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Dave, Thanks for your +/- summary. I think it concisely states some of the key issues here. However, I do have some comments: > With approach #1 (a global registration authority > of identification), > + High quality of assignments > - privacy I am not sure what you mean by the above two points. > - turn around time on assignments > - if in MIBs, version tracking, & delayed publishing updates This is a problem for either approach. The enumerations are listed in either an Internet Standard MIB -- in which case the manager/agent have the responsibility to get the "latest" version of this MIB, which can be delayed by the IETF Process..... Or the values are defined in a proprietary MIB, in which case the manager has to make sure that it has the latest version of said MIB as provided by the vendor.... > With approach #2 (distributed registration authorities) > + Privacy > + Speed of publishing determined by creator Again, this is the same as for integer enumerations... > + In SNMPv2, the OBJECT-IDENTITY macro allows descriptions > to be associated with each value > - No one place to go to get all possible values True. But, in theory* a box would either return a standardized OID (which can be obtained from a standard MIB -- either the ifMib or a medium-specific MIB) or it can return a proprietary OID, which would be defined in my proprietry MIB and which a vendor should provide with their box. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05425; 7 Oct 93 10:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05421; 7 Oct 93 10:18 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11329; 7 Oct 93 10:18 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 10:18:33 EDT Received: by ftp.com id AA18786; Thu, 7 Oct 93 10:18:39 -0400 Date: Thu, 7 Oct 93 10:18:39 -0400 Message-Id: <9310071418.AA18786@ftp.com> To: bsimpson@morningstar.com Subject: Re: ifOperStatus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com > Based on Frank's excellent analysis, I'm wondering if it wouldn't be > better to deprecate the ifOperStatus entirely! No. You want something that you can look at to rather efficiently get a general sense of the health of the interface -- ifOperStatus. Only if ifOperStatus indicates a problem should you go look for more detailed information. The PPP MIB has a similar mechanism. In PPP there is a link quality determination protocol. It has a bunch of internal counts and state variables that it exchanges with its peer, munges together, and then makes some declaration on the link's quality. In the MIB, we could have just mibified all of the internal variables and data used, requiring that a manager station go out and extract the data and then perform the same algorithm as the PPP node to determine a link's quality. However, we also have a variable that simply shows the link's quality (good or bad). A manager can monitor that variable and if there is a problem it can then go look at the other variables. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05437; 7 Oct 93 10:19 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05433; 7 Oct 93 10:19 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11334; 7 Oct 93 10:18 EDT Received: from ftp.com (babyoil.ftp.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 10:19:05 EDT Received: by ftp.com id AA18795; Thu, 7 Oct 93 10:18:44 -0400 Date: Thu, 7 Oct 93 10:18:44 -0400 Message-Id: <9310071418.AA18795@ftp.com> To: CASE@utkvx.utk.edu Subject: Re: ifOperStatus Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: okorf@netcs.com, if-mib@thumper.bellcore.com > i'm sorry, but i have to disagree because i don't think it is an improvement > here is my thinking: > there are many management stations that are able to associate a value of an > enumerated integer with a "happy state" i.e., green and/or able to do a > "switch" based on multiple cases, comparisons of counters or gauges with > thresholds, etc > > all of these a based on INTEGER or INTEGER-like thingos Jeff, My proposal keeps ifOperStatus, with its current values. This is the variable that is simple and easy to check -- that you go and look at relatively frequently. If and only if ifOperStatus indicates a problem would you go look at the OID to get more information. > i don't know of a single management station that can do this with OIDs, and, > if it could, its performance would be much poorer I do not think that we should limit what we do in agents on the basis of what manager stations currently do. It is very easy to get into a circular, chicken and egg argument by this sort of precedent. If the technology that I proposed is useful and we standardize it then it is up to agent developers and manager station developers to do it. Finally, if you wish to argue performance, then I would claim that there are several MIBs, and perhaps bits and pieces of the SNMP and SNMPv2 protocols, that might be able to use a bit of rework, if we wish to make performance such an overriding factor. Again, it is our job (to a degree) to set technology based on usefulness and utility. Then, if you wish to implement that technology you will have to have a hardware/ software base that supports it. That's the cost of playing in this game. We might end up raising the entry cost here and there, but presumably we do it because of the perceived utility of the technology -- i.e. there is a good thrust to weight ratio. Now, I have also argued as you do -- that something is to complex, that its performance is not good and so on. But my base has always been (at least I think it has always been...) that the proposal's technology was not useful enough to warrant the extra cost. So, in summation, let's keep the argument focused on the usefulness of the technology, shall we? > please, can't we do this in a way parallel to ifType? What do you mean by this? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 > > please, can't we do this in a way parallel to ifType? > > could you support that Oliver? > > > regards, > jdc > -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06005; 7 Oct 93 10:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06001; 7 Oct 93 10:54 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12328; 7 Oct 93 10:54 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 10:54:36 EDT Received: by xap.xyplex.com id ; Thu, 7 Oct 93 12:56:21 -0500 Date: Thu, 7 Oct 93 12:56:21 -0500 Message-Id: <9310071756.AA17786@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com In-Reply-To: CASE@UTKVX.UTCC.UTK.EDU's message of Wed, 06 Oct 1993 17:57:26 -0400 (EDT) <01H3SU1UWBRM8Y5UVX@utkvx.utk.edu> Subject: Re: ifOperStatus >i have no problem with the IANA publishing them as textual conventions in >parseable ASN.1, however, i can understand why they'd resist such a thing It seems to me that we could define a single document for SNMP assigned numbers, carefully laid out to make editing the enumerations very easy, then twist the arm of the IANA to use that format. I can't believe it would be all that much additional work for them. >i figure we'd get them the same way we get the enterprise numbers ... we >fetch them periodically, and hand edit to reformat them into something >a mib compiler can read ... not optimum, but workable Having lots of people repeat that sort of additional work is pretty wasteful, when it seems it would be so easy to remove the necessity to edit ANY files. You'd simply recompile the IANA MIB module, with the textual conventions, and, if you're textual convention handling system is really dumb, all the MIBs that depend on them. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07038; 7 Oct 93 11:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07032; 7 Oct 93 11:49 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13982; 7 Oct 93 11:49 EDT Received: from UTKVX3.UTK.EDU by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 11:49:50 EDT Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-13 #4157) id <01H3TURIOZS08Y62NB@utkvx.utk.edu>; Thu, 7 Oct 1993 11:42:06 EDT Date: Thu, 07 Oct 1993 11:42:06 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: CASE@utkvx.utk.edu Subject: Re: ifOperStatus To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Message-Id: <01H3TURIRO828Y62NB@utkvx.utk.edu> X-Vms-To: IN%"kasten@ftp.com" X-Vms-Cc: IN%"if-mib@thumper.bellcore.com",CASE Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Frank writes: >My proposal keeps ifOperStatus, with its current values. This is the perhaps it does ... however, i can't keep track, yours is not the only proposal on the table that's part of the problem with this thread ... we can't effectively debate the merits of the proposal, because there are so many proposals that are muddled together, at least in my mind, if not in everybody's mind regards, jdc   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07301; 7 Oct 93 12:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07297; 7 Oct 93 12:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14619; 7 Oct 93 12:10 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 12:10:59 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA24563 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Thu, 7 Oct 1993 09:10:21 -0700 Message-Id: <199310071610.AA24563@hubbub.cisco.com> To: CASE@utkvx.utk.edu Cc: kasten@ftp.com, if-mib@thumper.bellcore.com Subject: Re: ifOperStatus In-Reply-To: Your message of "Thu, 07 Oct 93 11:42:06 EDT." <01H3TURIRO828Y62NB@utkvx.utk.edu> Date: Thu, 07 Oct 93 09:10:21 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder > that's part of the problem with this thread ... we can't effectively debate > the merits of the proposal, because there are so many proposals that are > muddled together, at least in my mind, if not in everybody's mind Good point. I feel I created this mess, so I will take a shot at cleaning it up. Back in a bit. Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08639; 7 Oct 93 13:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08635; 7 Oct 93 13:29 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16600; 7 Oct 93 13:29 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 13:29:22 EDT Received: from via.ccb3.merit.edu by vela.acs.oakland.edu with SMTP id AA07602 (5.65c+/IDA-1.4.4); Thu, 7 Oct 1993 13:29:15 -0400 Date: Thu, 7 Oct 93 12:05:24 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1482.bill.simpson@um.cc.umich.edu> To: if-mib@thumper.bellcore.com Reply-To: bsimpson@morningstar.com Subject: Re: ifOperStatus > From: kasten@ftp.com (Frank Kastenholz) > we also have a variable that simply shows the link's quality (good or > bad). A manager can monitor that variable and if there is a problem > it can then go look at the other variables. > Well, that seems a good split to me, too. So, no matter which way you argue, I seem to agree with you. That means I just don't know enough to make a decision, or you are a very good arguer! So, for OperStatus, I guess that my preference would be back to: up down testing waiting With an OID for specific kinds of down, testing and waiting. But by this logic, wouldn't it be best for ifType to be deprecated, and be replaced with ifClass of character, packet, etc for the conformance statements, with ifSpecific used to determine the actual type? Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10030; 7 Oct 93 14:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10025; 7 Oct 93 14:21 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18426; 7 Oct 93 14:21 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 14:21:30 EDT Received: by xap.xyplex.com id ; Thu, 7 Oct 93 16:23:13 -0500 Date: Thu, 7 Oct 93 16:23:13 -0500 Message-Id: <9310072123.AA20727@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com Subject: IANA Textual Conventions Lest we argue about fact... I decided to find out for sure what IANA would be willing to do, so I asked Jon Postel. I told him what I was proposing: either a separate document or a piece of the existing assigned numbers document, formatted as an ASN.1 MIB containing textual conventions arranged for easy addition of new lines for new values. Here's his response, which showed up very shortly after I asked. >Bob: > >Yes. I am sure we can do what you suggest. > >--jon. So, now, why can't we change ifType to be a textual convention, InterfaceType, and define that textual convention in a MIB-style document that is maintained by IANA, thus allowing people to simply compile that standard document along with their standard MIB, with NO editing unless they want to (easily) pick up new values before a new version is released? (I'm going to keep pounding this sucker until it goes in or blows up. This might be the once and for all answer to extending standard enumerations.) Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10918; 7 Oct 93 14:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10914; 7 Oct 93 14:39 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19088; 7 Oct 93 14:39 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 7 Oct 93 14:39:57 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA29968 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Thu, 7 Oct 1993 11:39:56 -0700 Message-Id: <199310071839.AA29968@hubbub.cisco.com> To: if-mib@thumper.bellcore.com Subject: ifOperStatusDetail Date: Thu, 07 Oct 93 11:39:55 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder Ok here is my first attempt to bring this home... 1. ifOperStatus Remains unchanged. 2. ifOperStatusDetail is added to the ifTable ifOperStatusDetail OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "Provides more detail on the current operational state of the interface. For example: a dial on demand circuit that had the ifOperStatus of down might be set to the appropriate OID to indicate a current lack of demand for the circuit. If no appropriate OID exists to detail the current state the value should be set to the OBJECT IDENTIFIER { 0 0 }." ::= { ifEntry 23 } Depending on the reaction to the above I would propose some OIDs to seed this proposal, but I will wait for the reaction to the above first. Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10026; 8 Oct 93 14:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10020; 8 Oct 93 14:49 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19466; 8 Oct 93 14:49 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 8 Oct 93 14:49:30 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA27600 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Fri, 8 Oct 1993 11:49:26 -0700 Message-Id: <199310081849.AA27600@hubbub.cisco.com> To: Robert Snyder Cc: if-mib@thumper.bellcore.com Subject: Re: ifOperStatusDetail In-Reply-To: Your message of "Thu, 07 Oct 93 11:39:55 PDT." <199310071839.AA29968@hubbub.cisco.com> Date: Fri, 08 Oct 93 11:49:26 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder Hmmm. No response. Was I on the money, or so bogus that I frustrated you all? Robert > -- using template mhl.format -- > Date: Thu, 07 Oct 93 11:39:55 PDT > To: if-mib@thumper.bellcore.com > > From: Robert Snyder > Subject: ifOperStatusDetail > > Return-Path: snyder > > > Ok here is my first attempt to bring this home... > > 1. ifOperStatus > > Remains unchanged. > > 2. ifOperStatusDetail is added to the ifTable > > ifOperStatusDetail OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Provides more detail on the current operational > state of the interface. For example: a dial on demand > circuit that had the ifOperStatus of down might be > set to the appropriate OID to indicate a current lack > of demand for the circuit. > If no appropriate OID exists to detail the current state > the value should be set to the OBJECT IDENTIFIER { 0 0 }." > ::= { ifEntry 23 } > > Depending on the reaction to the above I would propose some OIDs to > seed this proposal, but I will wait for the reaction to the above > first. > > Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13391; 8 Oct 93 17:21 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13387; 8 Oct 93 17:21 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24189; 8 Oct 93 17:21 EDT Received: from flash.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 8 Oct 93 16:48:54 EDT Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA10163; Fri, 8 Oct 93 16:48:53 -0400 Received: from by eve (4.1/4.7) id AB14591; Fri, 8 Oct 93 16:50:45 EDT Date: Fri, 8 Oct 93 16:50:45 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9310082050.AB14591@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: use of ifTable for the atm layer in order to prepare a new version of the atm mib we need resolution on this issue. are there any objections against keith's fixed-chunk proposal? if-mibbers? [silence means no objection to make this modification in if-mib....] kaj At 7:58 PM 10/5/93 -0400, Kaj Tesink wrote: >to get everybody on the same track, i worked out what the >fixedChunkProposal and the keepIfTableAsIsApproach mean for the >atm layer. > >comments please. > >kaj >--------------------------------------------------------- > >Here is what the fixed-chunk proposal means (i.e., the fixedChunkGroup >contains the objects ifInOctets, ifOutOctets, IfInErrors, ifInUnknownProtos; >the ifPacketGroup does not apply - we may have to change the >names of those groups) > > 7.2.1. Support of the ATM Cell Layer by ifTable > > Some specific interpretations of ifTable for the ATM cell > layer follow. > > Object Use for the generic ATM layer. > > ifIndex Each ATM port is represented by an ifEntry. > ifDescr Description of the ATM interface. > ifType The value that is allocated for ATM is 37. > ifSpeed Peak bandwidth in bits per second available for >use. > ifPhysAddress The primary address for this interface > assigned by the ATM interface provider. > An octet string of zero length if no address is > used for this interface. > ifAdminStatus Supports read-only access (initially). > The administrative status of the interface. > ifOperStatus Assumes the value down(2) if the ATM cell layer or > any layer below that layer is down. > ifLastChange The elapsed time since the last re-initializtion. > ifInOctets The number of received octets over the >interface, i.e., > the number of received cells multiplied by 53. > ifOutOctets The number of transmitted octets over the >interface, i.e., > the number of transmitted cells multiplied by 53. > ifInErrors The number of received cells that are > dropped due to uncorrectable header bit errors. > ifInUnknownProtos The number of received cells discarded > due to header content errors which include > unrecognized VPI or VPI/VCI values, incorrect > PTI values or incorrect cell header patterns. > ifSpecific Set to the OBJECT IDENTIFIER { experimental 41 }. > [Ed.note to be changed to { transmission 37 } if > this specification is put on the IETF standards > track] > ifName Textual name of the interface or an octet string > of zero length. > ifLinkUpDownTrapEnable Default is disabled (2). > Just read-only access may be supported. > ifHighSpeed Peak bandwidth in megabits per second available >for use. > > >And here is what it means when we use ifTable as it is. >Changes to the above marked with bar (|) > > > 7.2.1. Support of the ATM Cell Layer by ifTable > > Some specific interpretations of ifTable for the ATM cell > layer follow. > > Object Use for the generic ATM layer. > > ifIndex Each ATM port is represented by an ifEntry. > ifDescr Description of the ATM interface. > ifType The value to be allocated for ATM is 37. >| ifMtu Set to 53. > ifSpeed Peak bandwidth in bits per second available for >use. > ifPhysAddress The primary address for this interface > assigned by the ATM interface provider. > An octet string of zero length if no address is > used for this interface. > ifAdminStatus Supports read-only access (initially). > Set to the same value as ifOperStatus. > ifOperStatus Assumes the value down(2) if the ATM cell layer or > any layer below that layer is down. > ifLastChange The elapsed time since the last re-initializtion. > ifSpecific Set to the OBJECT IDENTIFIER { experimental 41 }. > [Ed.note to be changed to { transmission 37 } if > this specification is put on the IETF standards > track] > ifName Textual name of the interface or an octet string > of zero length. > ifLinkUpDownTrapEnable Default is disabled (2). > Just read-only access may be supported. > ifHighSpeed Peak bandwidth in megabits per second available >for use. > ifPromiscuousMode Set to false(2) > >| Given the fixed cells size of 53 octets, the following arithmetic >| relationship applies: > >| ifInOctets * 53 = The number of received cells on the interface = >| (ifInUcastPkts + ifInMulticastPkts + >| ifInBroadcastPkts + ifInErrors + >| ifInUnknownProtos + ifInDiscards) >| with: > >| ifInOctets The number of received cells multiplied by 53. >| ifInUcastPkts The number of received unerrored assigned cells. >| ifInMulticastPkts Set to 0 since the generic ATM level is >| point-to-point. >| ifInBroadcastPkts Set to 0 since the generic ATM level is >| point-to-point. > ifInErrors The number of received cells that are > dropped due to uncorrectable header bit errors. > ifInUnknownProtos The number of received cells discarded > due to header content errors which include > unrecognized VPI or VPI/VCI values, incorrect > PTI values or incorrect cell header patterns. >| ifInDiscards Set to 0. > > >| ifOutOctets * 53 = The number of transmitted cells on the interface >= >| (ifOutUcastPkts + ifOutMulticastPkts + >| ifOutBroadcastPkts + ifOutErrors + >| ifOutDiscards) >| with: > > ifOutOctets The number of transmitted cells multiplied by 53. >| ifOutUcastPkts The number of assigned cells received for >transmission. >| ifOutMulticastPkts Set to 0 since the generic ATM level is >| point-to-point. >| ifOutBroadcastPkts Set to 0 since the generic ATM level is >| point-to-point. >| ifOutErrors Set to 0. >| ifOutDiscards Set to 0. > > > Thus, implementations that count received and transmitted cells > on the interface can take advantage of this arithmetic relationship > to derive ifInUcastPkts and ifOutUcastPkts. > > > > >0------------0--------------0-------------0-------------0-----------0 >Kaj Tesink >pmail Bellcore vmail (908) 758-5254 > 331 Newman Springs Rd. faxmail (908) 758-4196 > Red Bank, NJ 07701 email kaj@cc.bellcore.com 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20372; 11 Oct 93 3:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20368; 11 Oct 93 3:09 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01987; 11 Oct 93 3:09 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 02:39:27 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA24904; Sun, 10 Oct 93 23:39:05 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA01248; Sun, 10 Oct 93 23:22:48 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310110622.AA01248@nms.hls.com> Subject: Re: use of ifTable for the atm layer To: Kaj Tesink Date: Sun, 10 Oct 93 23:22:47 PDT Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9310082050.AB14591@eve>; from "Kaj Tesink" at Oct 8, 93 4:50 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] I support this change to the ifmib. I also have some comments. >Here is what the fixed-chunk proposal means (i.e., the fixedChunkGroup >contains the objects ifInOctets, ifOutOctets, IfInErrors, ifInUnknownProtos; >the ifPacketGroup does not apply - we may have to change the >names of those groups) 1. How about fixedLengthGroup (rather than fixedChunkGroup) ? 2. For consistency, ifOutErrors should also be in the fixedLengthGroup. > 7.2.1. Support of the ATM Cell Layer by ifTable > > Some specific interpretations of ifTable for the ATM cell > layer follow. > > Object Use for the generic ATM layer. > > ifIndex Each ATM port is represented by an ifEntry. > ifDescr Description of the ATM interface. > ifType The value that is allocated for ATM is 37. > ifSpeed Peak bandwidth in bits per second available for > use. The words "peak" and "available" suggest that this is the bandwidth currently unused by existing connections, which I assume was not your intention ?? > ifPhysAddress The primary address for this interface > assigned by the ATM interface provider. > An octet string of zero length if no address is > used for this interface. 1. Delete "assigned by the ATM interface provider", since a) it's not clear what it means, and b) assuming the address is in one of the formats specified by the ATM Forum, then it can be a combination of a network prefix and a MAC address, and thus is not provided by any one entity. 2. For a host, this is the (primary) local address for signaling requests for connections to terminate at this host. For switches/networks, I suggest it is the (primary) local address for signaling requests for connections to terminate at the endpoint/host (if any) connected to this interface. > ifAdminStatus Supports read-only access (initially). > The administrative status of the interface. Omit the comment about read-only access. Implementations are allowed to support read-only and read-write, according to the compliance statements in the ifmib. This interpretation does not change that. > ifOperStatus Assumes the value down(2) if the ATM cell layer or > any layer below that layer is down. > ifLastChange The elapsed time since the last re-initializtion. This differs from the MIB-II definition which should be instead. > ifInOctets The number of received octets over the > interface, i.e., > the number of received cells multiplied by 53. > ifOutOctets The number of transmitted octets over the > interface, i.e., > the number of transmitted cells multiplied by 53. > ifInErrors The number of received cells that are > dropped due to uncorrectable header bit errors. Change "uncorrectable header bit errors" to "HEC errors", since a) it is more specific, and b) I believe there is at least one physical layer for which one-bit errors are correctable, but the specification says to drop them anyway. > ifInUnknownProtos The number of received cells discarded > due to header content errors which include > unrecognized VPI or VPI/VCI values, incorrect > PTI values or incorrect cell header patterns. Why put incorrect PTI values and incorrect cell header patterns here rather than in ifInErrors ? > ifSpecific Set to the OBJECT IDENTIFIER { experimental 41 }. > [Ed.note to be changed to { transmission 37 } if > this specification is put on the IETF standards > track] > ifName Textual name of the interface or an octet string > of zero length. > ifLinkUpDownTrapEnable Default is disabled (2). > Just read-only access may be supported. See above comment on read-only. > ifHighSpeed Peak bandwidth in megabits per second available > for use. See above comment for ifSpeed. Either list ifHighSpeed, ifHCInOctets and ifHCOutOctets, or list none of them. If listed, then I suggest prepending each such interpretation with: "if required by the compliance statements in [x], ..." where [x] is a reference to the ifmib. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22304; 11 Oct 93 10:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22300; 11 Oct 93 10:18 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23875; 11 Oct 93 10:18 EDT Received: from cd1.lrz-muenchen.de by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 10:18:46 EDT Received: from lrz1.lrz-muenchen.de by cd1.lrz-muenchen.de id SMTP-0012cb96b3e001797; Mon, 11 Oct 93 15:18:38 +0100 Received: from LRZ1/MAILQUEUE by lrz1.lrz-muenchen.de (Mercury 1.1); Mon, 11 Oct 93 15:18:38 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anja Schuhknecht Organization: Leibniz-Rechenzentrum To: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com Date: Mon, 11 Oct 1993 15:18:20 +0100 Subject: Re: use of ifTable for the atm layer X-Pmrqc: 1 Priority: normal X-Mailer: PMail v3.0 (R1a) Message-Id: Dear Mibber's, I am listening your discussion about ATM and it's 'management equivalence in MIBII' for about one month now and have one question. I got the impression that you took the MIBII and tried to find an interpretation for the various MIBII-objects in ATM. Wouldn't it be better to proceed the other way round, i.e. taking ATM, trying to find out what kind of parameters you will need to really MANAGE ATM-staff and afterwards (if it is absolutely unevidable) try to put this in the MIBII? Anja -------------------------------------------------------------------------- Anja Schuhknecht Tel: +49 89 2105-8765 Leibniz-Rechenzentrum Muenchen Fax: +49 89 2809460 Abteilung Kommunikationsnetze Email (RFC-822): schuhknecht@lrz-muenchen.de Email (X.400): g=anja; s=schuhknecht; ou=lrz; p=lrz-muenchen; a=d400; c=de --------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23617; 11 Oct 93 12:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23613; 11 Oct 93 12:44 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa29203; 11 Oct 93 12:44 EDT Received: from att.att.com (gw1.att.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 12:44:53 EDT Message-Id: <9310111644.AA13665@thumper.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: krr@qsun.att.com Date: Mon, 11 Oct 93 12:07 EDT Original-From: qsun!krr (Kenneth R Rodemann +1 908 949 6229) To: if-mib@thumper.bellcore.com Subject: Re: use of ifTable for the atm layer Recipients: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com Kaj, I have one correction, one request for added objects, and two concerns. The correction: > | ifInOctets * 53 = The number of received cells on the interface... > | ifOutOctets * 53 = The number of transmitted cells on the ... These lines should be division (/) rather than multiplication. Request for added objects: As per the Service Management Architecture, add back-references in both atmV?ConnectionTable's to the (officially-proposed-by-the-end-of-this-week) generic connection table. Concern I: I am still uneasy about the name Fixed-Chunk-Group (or some such variant). This name is fairly general and other (future?) protocols may be able to be classified as such. The arithmetic works nicely for ATM because the current ATM MIB is based on a non-multicast/non-broadcast service. If we continue to call this group by such a generic name, I think we must add comments as follows: -- This Group only counts received/transmitted octets, not packets. -- Note that octet counters in the Interfaces Table aggregate -- the octet counts for unicast and non-unicast packets into -- a single octet counter per direction (received/transmitted). -- Thus, separating unicast from multicast or broadcast counts -- for interfaces or protocols that permit non-unicast packets -- must be maintained in a media-specific MIB module. Concern II: Because of using only a subset of ifTable counters, a couple of counter-type inconsistencies exist: (a) within ifTable, only octet counts are kept for good cells, while only cell counts are kept for bad (invalid) cells. (b) between ifTable and the ATM connection tables: ports (interfaces) use only octet counters connections use only cell counters Let's attempt to remove these inconsistencies (or at least remove inconsistency (b)). Cheers, Ken Rodemann AT&T Bell Laboratories krr@qsun.att.com 908-949-6229   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23875; 11 Oct 93 13:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23871; 11 Oct 93 13:14 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa29985; 11 Oct 93 13:14 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 13:14:24 EDT Received: by xap.xyplex.com id ; Mon, 11 Oct 93 15:15:58 -0500 Date: Mon, 11 Oct 93 15:15:58 -0500 Message-Id: <9310112015.AA28847@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com Subject: IANA Textual Conventions I received an off-line suggestion that I see if IANA would keep a live document on-line, so we wouldn't have to wait for RFC releases. They are willing to consider that, althoug it is more trouble for them. I'd predict that an SNMP-only, MIB-formatted document would have a decent chance of getting that sort of treatment, since it's activity level should be less than all the assigned numbers put together. I still haven't heard much comment on whether this is a good idea... Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29078; 11 Oct 93 18:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29074; 11 Oct 93 18:23 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08390; 11 Oct 93 18:22 EDT Received: from flash.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 17:49:43 EDT Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA13484; Mon, 11 Oct 93 17:49:42 -0400 Received: from [128.96.69.98] (nvc-1h409-1) by eve (4.1/4.7) id AA18636; Mon, 11 Oct 93 17:51:35 EDT Date: Mon, 11 Oct 93 17:51:33 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9310112151.AA18636@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Keith McCloghrie Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: use of ifTable for the atm layer Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com At 11:22 PM 10/10/93 -0700, Keith McCloghrie wrote: >I support this change to the ifmib. I also have some comments. > >>Here is what the fixed-chunk proposal means (i.e., the fixedChunkGroup >>contains the objects ifInOctets, ifOutOctets, IfInErrors, ifInUnknownProtos; >>the ifPacketGroup does not apply - we may have to change the >>names of those groups) > >1. How about fixedLengthGroup (rather than fixedChunkGroup) ? less soup-like ^). i like it. > >2. For consistency, ifOutErrors should also be in the fixedLengthGroup. right. sorry for that oversight. the mapping for ATM: ifOutErrors Set to 0. (this is what we had before; if some folks want to measure this it should be: ifOutErrors See [5]. which would introducs some arithmetics again. anybody likes this? > >> 7.2.1. Support of the ATM Cell Layer by ifTable >> >> Some specific interpretations of ifTable for the ATM cell >> layer follow. >> >> Object Use for the generic ATM layer. >> >> ifIndex Each ATM port is represented by an ifEntry. >> ifDescr Description of the ATM interface. >> ifType The value that is allocated for ATM is 37. >> ifSpeed Peak bandwidth in bits per second available for >> use. > >The words "peak" and "available" suggest that this is the bandwidth currently >unused by existing connections, which I assume was not your intention ?? you're right. this should equal the level 1 payload that can be used by ATM. what about: ifSpeed The total bandwidth in bits per second available for ATM use. > >> ifPhysAddress The primary address for this interface >> assigned by the ATM interface provider. >> An octet string of zero length if no address is >> used for this interface. > >1. Delete "assigned by the ATM interface provider", since a) it's not >clear what it means, and b) assuming the address is in one of the formats >specified by the ATM Forum, then it can be a combination of a network >prefix and a MAC address, and thus is not provided by any one entity. > >2. For a host, this is the (primary) local address for signaling requests >for connections to terminate at this host. For switches/networks, I >suggest it is the (primary) local address for signaling requests >for connections to terminate at the endpoint/host (if any) connected >to this interface. addresses may be used administratively only (pvcs). what about: ifPhysAddress The (primary) local address for this interface. An octet string of zero length if no address is used for this interface. > >> ifAdminStatus Supports read-only access (initially). >> The administrative status of the interface. > >Omit the comment about read-only access. Implementations are allowed >to support read-only and read-write, according to the compliance >statements in the ifmib. This interpretation does not change that. ok, so: ifAdminStatus See [5]. > >> ifOperStatus Assumes the value down(2) if the ATM cell layer or >> any layer below that layer is down. >> ifLastChange The elapsed time since the last re-initializtion. > >This differs from the MIB-II definition which should be instead. what about: ifLastChange See [5]. > >> ifInOctets The number of received octets over the >> interface, i.e., >> the number of received cells multiplied by 53. >> ifOutOctets The number of transmitted octets over the >> interface, i.e., >> the number of transmitted cells multiplied by 53. >> ifInErrors The number of received cells that are >> dropped due to uncorrectable header bit errors. > >Change "uncorrectable header bit errors" to "HEC errors", since a) it is >more specific, and b) I believe there is at least one physical layer >for which one-bit errors are correctable, but the specification says to >drop them anyway. ifInErrors The number of received cells that are dropped due to HEC errors. > >> ifInUnknownProtos The number of received cells discarded >> due to header content errors which include >> unrecognized VPI or VPI/VCI values, incorrect >> PTI values or incorrect cell header patterns. > >Why put incorrect PTI values and incorrect cell header patterns here >rather than in ifInErrors ? previously, some folks liked to separate these errors from the HEC errors. > >> ifSpecific Set to the OBJECT IDENTIFIER { experimental 41 }. >> [Ed.note to be changed to { transmission 37 } if >> this specification is put on the IETF standards >> track] >> ifName Textual name of the interface or an octet string >> of zero length. >> ifLinkUpDownTrapEnable Default is disabled (2). >> Just read-only access may be supported. > >See above comment on read-only. ifLinkUpDownTrapEnable Default is disabled (2). > >> ifHighSpeed Peak bandwidth in megabits per second available >> for use. > >See above comment for ifSpeed. > >Either list ifHighSpeed, ifHCInOctets and ifHCOutOctets, or list none >of them. If listed, then I suggest prepending each such interpretation >with: "if required by the compliance statements in [x], ..." >where [x] is a reference to the ifmib. i personally dont feel a strong urge to list them. anybody insisting? > >Keith. thanx for debugging, kaj -------------------------------------------------- any comments? summary: 7.2.1. Support of the ATM Cell Layer by ifTable Some specific interpretations of ifTable for the ATM cell layer follow. Object Use for the generic ATM layer. ifIndex Each ATM port is represented by an ifEntry. ifDescr Description of the ATM interface. ifType The value that is allocated for ATM is 37. ifSpeed The total bandwidth in bits per second available for ATM use. ifPhysAddress The (primary) local address for this interface. An octet string of zero length if no address is used for this interface. ifAdminStatus See [5]. ifOperStatus Assumes the value down(2) if the ATM cell layer or any layer below that layer is down. ifLastChange See [5]. ifInOctets The number of received octets over the interface, i.e., the number of received cells multiplied by 53. ifOutOctets The number of transmitted octets over the interface, i.e., the number of transmitted cells multiplied by 53. ifInErrors The number of received cells that are dropped due to HEC errors. ifInUnknownProtos The number of received cells discarded due to header content errors which include unrecognized VPI or VPI/VCI values, incorrect PTI values or incorrect cell header patterns. ifOutErrors Set to 0. ifSpecific Set to the OBJECT IDENTIFIER { experimental 41 }. [Ed.note to be changed to { transmission 37 } when this specification is put on the IETF standards track] ifName Textual name of the interface or an octet string of zero length. ifLinkUpDownTrapEnable Default is disabled (2). 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29114; 11 Oct 93 18:30 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29110; 11 Oct 93 18:30 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08597; 11 Oct 93 18:30 EDT Received: from flash.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 18:06:09 EDT Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA13718; Mon, 11 Oct 93 18:06:09 -0400 Received: from [128.96.69.98] (nvc-1h409-1) by eve (4.1/4.7) id AA18882; Mon, 11 Oct 93 18:08:02 EDT Date: Mon, 11 Oct 93 18:08:01 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9310112208.AA18882@eve> X-Sender: kaj@eve.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Anja Schuhknecht , atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kaj Tesink Subject: Re: use of ifTable for the atm layer At 3:18 PM 10/11/93 +0100, Anja Schuhknecht wrote: >Dear Mibber's, > >I am listening your discussion about ATM and it's 'management equivalence >in MIBII' for about one month now and have one question. I got the impression >that you took the MIBII and tried to find an interpretation for the various >MIBII-objects in ATM. Wouldn't it be better to proceed the other way >round, i.e. taking ATM, trying to find out what kind of parameters you will >need to really MANAGE ATM-staff and afterwards (if it is absolutely >unevidable) try to put this in the MIBII? > hi anja, a fair question! i think what has been done is a little bit of both: how can atm be managed, and how can it be managed such that it fits into MIB II. note that atm is not just managed by MIB II; that is why we have the ATM MIB. the relevance of the MIB II mapping is that that way we can fold atm management into the overall management of internets, of which MIB II has been well established as the core. perhaps no interface type has an ideal mapping to MIB II although some map better than others. each i/f type has its own peculiarities. but by having MIB II as a common denominator we enable more common NMS applications that can provide a common picture of key i/f properties in internets. a lofty goal indeed. kaj 0------------0--------------0-------------0-------------0-----------0 Kaj Tesink pmail Bellcore vmail (908) 758-5254 331 Newman Springs Rd. faxmail (908) 758-4196 Red Bank, NJ 07701 email kaj@cc.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29219; 11 Oct 93 19:00 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29215; 11 Oct 93 19:00 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09294; 11 Oct 93 19:00 EDT Received: from synoptics.com (pobox.synoptics.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 11 Oct 93 18:33:02 EDT Received: from milliways (milliways.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA24707; Mon, 11 Oct 93 15:31:20 PDT Received: by milliways (4.1/2.0N) id AA15709; Mon, 11 Oct 93 15:31:19 PDT Message-Id: <9310112231.AA15709@milliways> Date: Mon, 11 Oct 93 15:31:19 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Andrew Smith To: kzm@hls.com Subject: Re: use of ifTable for the atm layer Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com > From kzm@hls.com Sun Oct 10 23:47:10 1993 > From: kzm@hls.com (Keith McCloghrie) > Subject: Re: use of ifTable for the atm layer > To: kaj@cc.bellcore.com (Kaj Tesink) > Date: Sun, 10 Oct 93 23:22:47 PDT > Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com > In-Reply-To: <9310082050.AB14591@eve>; from "Kaj Tesink" at Oct 8, 93 4:50 pm > Organization: Hughes LAN Systems > Content-Length: 4738 Keith, > > ifPhysAddress The primary address for this interface > > assigned by the ATM interface provider. > > An octet string of zero length if no address is > > used for this interface. > > 1. Delete "assigned by the ATM interface provider", since a) it's not > clear what it means, and b) assuming the address is in one of the formats > specified by the ATM Forum, then it can be a combination of a network > prefix and a MAC address, and thus is not provided by any one entity. ... not to mention a selector field. > 2. For a host, this is the (primary) local address for signaling requests > for connections to terminate at this host. For switches/networks, I > suggest it is the (primary) local address for signaling requests > for connections to terminate at the endpoint/host (if any) connected > to this interface. Some questions: (1) Should ifPhysAddress have 19 or 20 octets in it? If 20, what should the selector contain? (2) Should a multi-homed device (e.g. a router with 'n' IP "interfaces" on one ATM cable) have 'n' seperate instances of the ATM Cell-layer group installed in ifTable just in order to be able to report each of its complete ATM addresses? I am assuming here that the selector field might be used to distinguish the different signalling endpoints, rather than giving the box 'n' 48-bit MAC addresses for the single interface. Any comments? Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Distributed Network Systems Group FAX: +1 408 988 5525 SynOptics Communications Inc. E-m: asmith@synoptics.com ********************************************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00683; 12 Oct 93 6:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab00675; 12 Oct 93 6:58 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01805; 12 Oct 93 5:28 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for if-mib-list@netrix.com; Tue, 12 Oct 93 03:46:47 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA21039; Tue, 12 Oct 93 00:46:32 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA00413; Tue, 12 Oct 93 00:30:07 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310120730.AA00413@nms.hls.com> Subject: Re: use of ifTable for the atm layer To: Kaj Tesink Date: Tue, 12 Oct 93 0:30:07 PDT Cc: kzm@hls.com, atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9310112151.AA18636@eve>; from "Kaj Tesink" at Oct 11, 93 5:51 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > >2. For consistency, ifOutErrors should also be in the fixedLengthGroup. > > right. sorry for that oversight. the mapping for ATM: > > ifOutErrors Set to 0. > > (this is what we had before; if some folks want to measure this it should be: > > ifOutErrors See [5]. How about: "See [5]. For implementation strategies in which no output errors can occur at the ATM layer, this will always be 0." > >> ifSpeed Peak bandwidth in bits per second available for > >> use. > > > >The words "peak" and "available" suggest that this is the bandwidth currently > >unused by existing connections, which I assume was not your intention ?? > > you're right. this should equal the level 1 payload that can be used by ATM. > what about: > > ifSpeed The total bandwidth in bits per second > available for ATM use. "available for ... use" may still be ambiguous. How about: "The total bandwidth in bits per second available for existing and future ATM connections." > >Why put incorrect PTI values and incorrect cell header patterns here > >rather than in ifInErrors ? > > previously, some folks liked to separate these errors from the HEC errors. Having ATM-specific MIB objects for each type of error is fine, but I think the semantics of ifInUnknownProtos applies only to unknown VPI/VCIs. Also, unknown VPI/VCIs are likely to be a configuration error and it's better to separate out these from the other types of errors. > >Either list ifHighSpeed, ifHCInOctets and ifHCOutOctets, or list none > >of them. If listed, then I suggest prepending each such interpretation > >with: "if required by the compliance statements in [x], ..." > >where [x] is a reference to the ifmib. > > i personally dont feel a strong urge to list them. anybody insisting? Nuke 'em. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10953; 12 Oct 93 13:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10947; 12 Oct 93 13:54 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14736; 12 Oct 93 13:54 EDT Received: from mail.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 12 Oct 93 13:17:50 EDT Received: from freeze (freeze.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA12082; Tue, 12 Oct 1993 13:13:01 -0400 Return-Path: Received: by freeze (4.1/4.7) id AA06982; Tue, 12 Oct 93 13:23:05 EDT Date: Tue, 12 Oct 93 13:23:05 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Masuma Ahmed X-Station-Sent-From: freeze.bellcore.com Message-Id: <9310121723.AA06982@freeze> To: kzm@hls.com Subject: Re: use of ifTable for the atm layer Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com, salil@freeze.bellcore.com, hjf@freeze.bellcore.com, scf@freeze.bellcore.com, hv@freeze.bellcore.com Keith, > > >2. For consistency, ifOutErrors should also be in the fixedLengthGroup. > > > > right. sorry for that oversight. the mapping for ATM: > > > > ifOutErrors Set to 0. > > > > (this is what we had before; if some folks want to measure this it should be: > > > > ifOutErrors See [5]. > > How about: "See [5]. For implementation strategies in which no output > errors can occur at the ATM layer, this will always be 0." The statement seems to indicate that output errors do not occur for some implementations which may be not be a correct statement. Note that, some implementations may not be able to measure the error separately for each ATM interface in the outgoing direction but that does not mean that cells are not discarded or corrected before transmitting across the output port. Therefore, the value "0" could be misleading from NM perspectives. Therefore, for NM reason, I would propose not to add the ifOutErrors even though for symmetry reason, one may want to do so. > > >> ifSpeed Peak bandwidth in bits per second available for > > >> use. > > > > > >The words "peak" and "available" suggest that this is the bandwidth currently > > >unused by existing connections, which I assume was not your intention ?? > > > > you're right. this should equal the level 1 payload that can be used by ATM. > > what about: > > > > ifSpeed The total bandwidth in bits per second > > available for ATM use. > > "available for ... use" may still be ambiguous. How about: "The total > bandwidth in bits per second available for existing and future ATM > connections." How about "The total bandwidth in bits per second available to ATM layer." (For example, for DS3 interface, the bandwidth available to ATM is 34 Mbps and not 45 Mbps. Don't you think we need to convey this in the ifSpeed description ?) > > >Why put incorrect PTI values and incorrect cell header patterns here > > >rather than in ifInErrors ? > > > > previously, some folks liked to separate these errors from the HEC errors. > > Having ATM-specific MIB objects for each type of error is fine, but I think > the semantics of ifInUnknownProtos applies only to unknown VPI/VCIs. > Also, unknown VPI/VCIs are likely to be a configuration error and it's > better to separate out these from the other types of errors. The HEC errors occur due to transmission errors. On the other hand, incorrect PTI or incorrect cell header patterns occur due to protocol errors. The VPI/VCI error can occur due to protocol error and can also occur due to misconfiguration. In the T1S1.5 committee, it was decided to fold in all these three errors into one counter. The reason for doing that is the probability of occurrence of the incorrect PTI and cell header patterns is very small and the counter will basically provide information on incorrrect VPI/VCI values that are being used. Note that, it is impossible to separate out the VPI/VCI errors caused due to the protocol error from the configuration error. Also, since the ifInUnknownProtos stands for "The number of packets received via the interface which were discarded because of an unknown or unsupported protocol", we can use the ifInUnknownProtos for the above errors. > > >Either list ifHighSpeed, ifHCInOctets and ifHCOutOctets, or list none > > >of them. If listed, then I suggest prepending each such interpretation > > >with: "if required by the compliance statements in [x], ..." > > >where [x] is a reference to the ifmib. > > > > i personally dont feel a strong urge to list them. anybody insisting? > > Nuke 'em. > No problem to nuke'em. However, representing ATM layer by the fixedlengthgroup means that for most of the ATM interface rates such as DS3 and STS3c rates, we have to use the high capacity counters and not the 32 bit counters for the octet counts. Do you have any insight ? Masuma   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11082; 12 Oct 93 13:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11076; 12 Oct 93 13:55 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14808; 12 Oct 93 13:55 EDT Received: from mail.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 12 Oct 93 13:55:59 EDT Received: from ginsu4 (ginsu4.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA12266; Tue, 12 Oct 1993 13:51:43 -0400 Return-Path: Received: from localhost by ginsu4 (4.1/4.7) id AA07092; Tue, 12 Oct 93 13:46:58 EDT X-Station-Sent-From: ginsu4.bellcore.com Message-Id: <9310121746.AA07092@ginsu4> To: if-mib@thumper.bellcore.com Subject: Re: Connection Table ID Date: Tue, 12 Oct 93 13:46:56 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Tracy A. Brown" Gang, >From Ken Rodemann and Russ McGuire: >> cnEgressIfIndex Integer32, >> cnEgressCnId Integer32, >> cnIngressName DisplayString, >> cnEgressName DisplayString, >> cnAdminStatus INTEGER, >> cnOperStatus INTEGER, >> cnLastChange TimeTicks, >> cnSpecific OBJECT IDENTIFIER > > For frame relay would this point to the appropriately indexed > frPVCConnectIngressIfIndex? Or frPVCConnectIngressAdminStatus? Good question. I would say either, but frPVCConnectIngressAdminStatus may be better, since the INDEX variables will (probably) be not-accessible in SNMPv2. Then again, maybe this should point to the beginning of the row (column 1). Tracy, what do you think? Is there concensus on how ifSpecific will be used with the new instance-level redefinition? >From me: >From the ifMIB: ifSpecific: "A reference to MIB definitions specific to the particular media being used to realize the interface. It is recommended that this value point to an instance of a MIB object in the media-specific MIB, i.e., that this object have the semantics associated with the InstancePointer textual convention defined in RFC 1443. In fact, it is recommended that the media- specific MIB specify what value ifSpecific should/can take for values of ifType. If no MIB definitions specific to the particular media are available, the value should be set to the OBJECT IDENTIFIER { 0 0 }." ifSpecific The media-specific MIB must specify, for each of the ifType values to which it applies, the instance of a MIB object to which ifSpecific should point. So I guess we need to decide what objects ifSpecific should point to in the FRS MIB and the Connection MIB. We say in the FRS MIB: ifSpecific Set to the OBJECT IDENTIFIER for frLportIfIndex.frLportIfIndex for this ifEntry. Which is a non-accessible object. Talking with Kaj Tesink, he thinks the only use of ifSpecific would be to GET the object specified, therefore, ifSpecific should point to an accessible object. So the FRS MIB needs to be fixed and the Connection MIB should specify frPVCConnectIngressAdminStatus.(4 index values) for ifSpecific. IfMIBbers is this right? Tracy - -- Tracy A. Brown Bellcore NVC 1C-354 331 Newman Springs Rd. Red Bank, NJ 07701 tacox@mail.bellcore.com email (908) 758-2107 vmail (908) 758-4177 fax ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15236; 12 Oct 93 14:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15229; 12 Oct 93 14:40 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16066; 12 Oct 93 14:40 EDT Received: from mail.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 12 Oct 93 14:10:08 EDT Received: from freeze (freeze.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA12383; Tue, 12 Oct 1993 14:05:51 -0400 Return-Path: Received: by freeze (4.1/4.7) id AA07004; Tue, 12 Oct 93 14:16:00 EDT Date: Tue, 12 Oct 93 14:16:00 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Masuma Ahmed X-Station-Sent-From: freeze.bellcore.com Message-Id: <9310121816.AA07004@freeze> To: kzm@hls.com Subject: Re: use of ifTable for the atm layer Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com, salil@freeze.bellcore.com, hjf@freeze.bellcore.com, scf@freeze.bellcore.com, hv@freeze.bellcore.com Keith, > > > ifPhysAddress The primary address for this interface > > assigned by the ATM interface provider. > > An octet string of zero length if no address is > > used for this interface. > > 1. Delete "assigned by the ATM interface provider", since a) it's not > clear what it means, and b) assuming the address is in one of the formats > specified by the ATM Forum, then it can be a combination of a network > prefix and a MAC address, and thus is not provided by any one entity. > > 2. For a host, this is the (primary) local address for signaling requests > for connections to terminate at this host. For switches/networks, I > suggest it is the (primary) local address for signaling requests > for connections to terminate at the endpoint/host (if any) connected > to this interface. It is not clear for the public ATM UNI what is the meaning of (primary) local address either for provisioned or signaling connections. Note that for a public UNI supporting provisioned connections, the ATM UNI address will be assigned by the carrier which may not follow the ATM Forum address scheme. However, the address assigned will be unique within a carrier's network. On the other hand, for a public UNI supporting signaling connections, the ATM addreses in most cases (at least initially) will be native E.164 addresses which are globally unique and will not follow private ATM address structure. Therefore, stating it as a local address could be misleading. Also, what is a primary address. Are we assuming that an ATM UNI will have primary and secondary addresses (assuming that we understand primary and secondary addresses !) ? How about using: "See [5]". > > > ifInOctets The number of received octets over the > > interface, i.e., > > the number of received cells multiplied by 53. > > ifOutOctets The number of transmitted octets over the > > interface, i.e., > > the number of transmitted cells multiplied by 53. > > ifInErrors The number of received cells that are > > dropped due to uncorrectable header bit errors. > > Change "uncorrectable header bit errors" to "HEC errors", since a) it is > more specific, and b) I believe there is at least one physical layer > for which one-bit errors are correctable, but the specification says to > drop them anyway. I am not sure of any standards specification which specifies to drop cells for correctable HEC errors. How about: "The number of cells dropped due to uncorrectable HEC errors." > > ifInUnknownProtos The number of received cells discarded > > due to header content errors which include > > unrecognized VPI or VPI/VCI values, incorrect > > PTI values or incorrect cell header patterns. > > Why put incorrect PTI values and incorrect cell header patterns here > rather than in ifInErrors ? > The PTI and cell header patterns are caused due to protocol errors whereas header bit errors are caused due to transmission errors. Therefore, these errors are included in the ifInUnknownProtos since this counter counts packets discarded due to protocol error. Masuma   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02701; 13 Oct 93 1:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02696; 13 Oct 93 1:08 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01319; 13 Oct 93 1:08 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 13 Oct 93 00:39:52 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA09370; Tue, 12 Oct 93 21:39:36 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA10956; Tue, 12 Oct 93 21:23:05 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310130423.AA10956@nms.hls.com> Subject: Re: use of ifTable for the atm layer To: Andrew Smith Date: Tue, 12 Oct 93 21:23:04 PDT Cc: kzm@hls.com, atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com In-Reply-To: <9310112231.AA15709@milliways>; from "Andrew Smith" at Oct 11, 93 3:31 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > > > ifPhysAddress The primary address for this interface > > > assigned by the ATM interface provider. > > > An octet string of zero length if no address is > > > used for this interface. > > > > 1. Delete "assigned by the ATM interface provider", since a) it's not > > clear what it means, and b) assuming the address is in one of the formats > > specified by the ATM Forum, then it can be a combination of a network > > prefix and a MAC address, and thus is not provided by any one entity. > > ... not to mention a selector field. Right. > > 2. For a host, this is the (primary) local address for signaling requests > > for connections to terminate at this host. For switches/networks, I > > suggest it is the (primary) local address for signaling requests > > for connections to terminate at the endpoint/host (if any) connected > > to this interface. > > Some questions: > > (1) Should ifPhysAddress have 19 or 20 octets in it? I think 20 octets. > If 20, what should the selector contain? > (2) Should a multi-homed device (e.g. a router with 'n' IP "interfaces" on > one ATM cable) have 'n' seperate instances of the ATM Cell-layer group > installed in ifTable just in order to be able to report each of its > complete ATM addresses? I am assuming here that the selector field might > be used to distinguish the different signalling endpoints, rather than > giving the box 'n' 48-bit MAC addresses for the single interface. Good questions. I recall some discussion in the ATM Forum suggesting that Signaling/Address-Registration would treat any value of the Selector field as equivalent. I was going to check if the Forum spec actually says this, but haven't done so (yet). Also, many of the ifTable objects (ifSpeed, if InErrors, ifUnknownProtos, etc.) can only be attributed to the ATM interface as a whole, not to an individual ATM address. Thus, as far as the ATM layer is concerned, I think there should be one ifEntry with the selector in ifPhysAddress as, say, zero. However, MIB-II's ipAddrEntIfIndex points to a single ifEntry. In the case you cite, distinguishing which IP address uses which selector requires each selector to have its own ifEntry. One way to do this would be to have insert an extra ifEntry sub-layer (perhaps with an ifType of 'virtual' ?) between the IP layer and the ATM-layer. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04897; 13 Oct 93 9:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04892; 13 Oct 93 9:57 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14244; 13 Oct 93 9:57 EDT Received: from relay.fore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 13 Oct 93 09:57:53 EDT Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA23426; Wed, 13 Oct 93 09:58:13 EDT Received: from beluga.fore.com by dolphin.fore.com (4.1/SMI-4.1) id AA25362; Wed, 13 Oct 93 09:57:32 EDT Received: by beluga.fore.com (4.1/SMI-4.1) id AA08376; Wed, 13 Oct 93 09:57:30 EDT Date: Wed, 13 Oct 93 09:57:30 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Drew Daniel Perkins Message-Id: <9310131357.AA08376@beluga.fore.com> To: asmith@synoptics.com, kzm@hls.com Subject: Re: use of ifTable for the atm layer Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com > > (1) Should ifPhysAddress have 19 or 20 octets in it? > > I think 20 octets. > > > If 20, what should the selector contain? > > (2) Should a multi-homed device (e.g. a router with 'n' IP "interfaces" on > > one ATM cable) have 'n' seperate instances of the ATM Cell-layer group > > installed in ifTable just in order to be able to report each of its > > complete ATM addresses? I am assuming here that the selector field might > > be used to distinguish the different signalling endpoints, rather than > > giving the box 'n' 48-bit MAC addresses for the single interface. > > Good questions. I recall some discussion in the ATM Forum suggesting > that Signaling/Address-Registration would treat any value of the > Selector field as equivalent. I was going to check if the Forum spec > actually says this, but haven't done so (yet). Also, many of the > ifTable objects (ifSpeed, if InErrors, ifUnknownProtos, etc.) can only > be attributed to the ATM interface as a whole, not to an individual ATM > address. Thus, as far as the ATM layer is concerned, I think there > should be one ifEntry with the selector in ifPhysAddress as, say, zero. > However, MIB-II's ipAddrEntIfIndex points to a single ifEntry. In the > case you cite, distinguishing which IP address uses which selector > requires each selector to have its own ifEntry. One way to do this > would be to have insert an extra ifEntry sub-layer (perhaps with an > ifType of 'virtual' ?) between the IP layer and the ATM-layer. I have never noticed anything in the ATM Forum spec which said to ignore the selector. Section "5.1.3.1.11 Selector" says: "The selector is not used for ATM routing, but may be used by endsystems." We just used this fact in the Classical IP spec, so if this is not the complete story on selectors, then we'll have to change it. Drew Perkins ----------------------------------------------------------------- Fore Systems, Inc. Tel: (412) 967-4040 1000 Gamma Drive Fax: (412) 967-4044 Pittsburgh, PA 15238 Email: ddp@fore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12849; 13 Oct 93 14:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12845; 13 Oct 93 14:43 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25538; 13 Oct 93 14:43 EDT Received: from att.att.com (gw1.att.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 13 Oct 93 14:42:33 EDT Message-Id: <9310131842.AA16566@thumper.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: krr@qsun.att.com Date: Wed, 13 Oct 93 14:36 EDT Original-From: qsun!krr (Kenneth R Rodemann +1 908 949 6229) To: if-mib@thumper.bellcore.com Subject: Generic Connection Table Proposal Recipients: frftc@nsco.network.com atommib@thumper.bellcore.com if-mib@thumper.bellcore.com I have just submitted the following proposal for a generic connection table to the internet drafts coordinators. I would appreciate people's comments about the document and its relevance to the Frame Relay, ATM, and Interfaces MIBs. Thank you. Cheers, Ken Rodemann AT&T Bell Laboratories krr@qsun.att.com 908-949-6229 ----------------------------- Draft Connection Table October 1993 Management Information Base for Management of Network Connections October 8, 1993 Frame Relay Service MIB (frnetmib) Working Group Kenneth R. Rodemann AT&T Bell Laboratories krr@qsun.att.com 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 2. Abstract This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines managed objects used for managing Network Connections. Rodemann Expires April 8, 1994 [Page 1] Draft Connection Table October 1993 3. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework consists of four major components. They are: o RFC 1442 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. o RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols. o RFC 1445 which defines the administrative and other architectural aspects of the framework. o RFC 1448 which defines the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 3.1 Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Rodemann Expires April 8, 1994 [Page 2] Draft Connection Table October 1993 4. Overview This MIB consists of a single table, cnTable, that contains configuration and status information for network connections. This table is generic and may include entries for connections of differing datalink protocols as well as for interworked connections. The cnTable does not track connection performance information, such as packet or octet counts. Each entry in cnTable represents a single uni-directional flow of a connection, from the flow's ingress endpoint to its egress endpoint: +------------------------------------+ | ingress egress | | endpt endpt | ingress | +-------+ +-------+ | egress -> - - - - - - - | |----------| | - - - - - - -> | +-------+ +-------+ | | | +------------------------------------+ With this model, a bidirectional point-to-point connection is represented by two entries in cnTable, one entry per flow, with the corresponding ingress and egress ends flipped. The model also extends naturally to handle point-to-multipoint and multipoint-to-multipoint connections. For example, a full-duplex point-to-multipoint connection from point A to points B, C, and D consists of 6 uni-directional flows, so cnTable will have 6 entries for this connection. To accomodate multipoint connections, cnTable is indexed by both ingress and egress endpoints. A connection endpoint is identified by a 2-tuple, (ifIndex, cnId), where ifIndex specifies the endpoint's interface and cnId specifies the connection's unique identification on the interface. The cnTable, therefore, is indexed by four fields: cnIngressIfIndex, cnIngressCnId, cnEgressIfIndex, cnEgressCnId. To aide the NMS operator, cnTable includes cnIngressName and cnEgressName, which contain textual names of the entry's connection flow endpoints. It is suggested that these objects identify the datalink protocol and the protocol-specific address of the associated connection endpoint. Examples include 'Frame Relay DLCI 120' and 'ATM VPI/VCI 100/110'. Rodemann Expires April 8, 1994 [Page 3] Draft Connection Table October 1993 The objects cnAdminStatus, cnOperStatus, and cnLastChange provide connection status information for each uni-directional flow of a connection. Finally, cnSpecific contains an OID that references an instance object in a protocol-specific MIB corresponding to the entry's uni-directional connection flow. This OID references an actual instance, rather than a MIB group, because the protocol-specific connection table may be indexed differently than cnTable. Rodemann Expires April 8, 1994 [Page 4] Draft Connection Table October 1993 5. Object Definitions CONNECTION-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, TimeTicks, experimental FROM SNMPv2-SMI DisplayString, PhysAddress, RowStatus FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; cnMIB MODULE-IDENTITY LAST-UPDATED "9310082355Z" ORGANIZATION "IETF Frame Relay Network MIB WG" CONTACT-INFO "Kenneth R. Rodemann AT&T Bell Laboratories Room 1F-435A 101 Crawfords Corner Road PO Box 3030 Holmdel, NJ 07733-3030 Tel: 1-908-949-6229 Fax: 1-908-949-1726 E-mail: krr@qsun.att.com" DESCRIPTION "The MIB module to describe generic objects for network connections." ::= { experimental xx } -- The Connection Table -- The Connection Table contains information on -- an entity's connections. Each entry represents -- a uni-directional flow of a connection, from the -- ingress to the egress of the flow. cnTable OBJECT-TYPE SYNTAX SEQUENCE OF CnEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of uni-directional connection flows". ::= { cnMIB 1 } cnEntry OBJECT-TYPE SYNTAX CnEntry MAX-ACCESS not-accessible STATUS current Rodemann Expires April 8, 1994 [Page 5] Draft Connection Table October 1993 DESCRIPTION "An entry containing management information applicable to a particular connection flow." INDEX { cnIngressIfIndex, cnIngressCnId, cnEgressIfIndex, cnEgressCnId } ::= { cnTable 1 } CnEntry ::= SEQUENCE { cnIngressIfIndex Integer32, cnIngressCnId Integer32, cnEgressIfIndex Integer32, cnEgressCnId Integer32, cnIngressName DisplayString, cnEgressName DisplayString, cnAdminStatus INTEGER, cnOperStatus INTEGER, cnLastChange TimeTicks, cnSpecific OBJECT IDENTIFIER } cnIngressIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex corresponding to the ingress interface of this uni-directional connection flow." ::= { cnEntry 1 } cnIngressCnId OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION The identification of the ingress connection endpoint for this uni-directional connection flow. The endpoint's identification value must be unique per interface." ::= { cnEntry 2 } cnEgressIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of ifIndex corresponding to the egress interface of this uni-directional connection flow." Rodemann Expires April 8, 1994 [Page 6] Draft Connection Table October 1993 ::= { cnEntry 3 } cnEgressCnId OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION The identification of the egress connection endpoint for this uni-directional connection flow. The endpoint's identification value must be unique per interface." ::= { cnEntry 4 } cnIngressName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual name of the ingress connection endpoint for this uni-directional connection flow. The value of this object should identify the datalink protocol and the protocol-specific address of this connection endpoint. Examples include 'Frame Relay DLCI 120' and 'ATM VPI/VCI 100/110'." ::= { cnEntry 5 } cnEgressName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The textual name of the egress connection endpoint for this uni-directional connection flow. The value of this object should identify the datalink protocol and the protocol-specific address of this connection endpoint. Examples include 'Frame Relay DLCI 120' and 'ATM VPI/VCI 100/110'." ::= { cnEntry 6 } cnAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } MAX-ACCESS read-create STATUS current DESCRIPTION "The desired state of the uni-directional Rodemann Expires April 8, 1994 [Page 7] Draft Connection Table October 1993 connection flow. The testing(3) state indicates that no operational packets can be passed." ::= { cnEntry 7 } cnOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3), -- in some test mode unknown(4) -- status can not be determined -- for some reason. } MAX-ACCESS read-only STATUS current DESCRIPTION "The current operational state of the uni-directional connection flow. The testing(3) state indicates that no operational packets can be passed." ::= { cnEntry 8 } cnLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the uni-directional connection flow entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { cnEntry 9 } cnSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "A reference to a MIB object in the protocol-specific MIB (i.e., an object having the semantics associated with the InstancePointer textual convention defined in RFC 1443), corresponding to this uni-directional connection flow. If no connection-associated MIB definition specific to the particular media is available, the value should be set to the OBJECT IDENTIFIER { 0 0 }." ::= { cnEntry 10 } Rodemann Expires April 8, 1994 [Page 8] Draft Connection Table October 1993 -- Conformance Information cnTableConformance OBJECT IDENTIFIER ::= { cnMIB 2 } cnTableGroups OBJECT IDENTIFIER ::= { cnTableConformance 1 } cnTableCompliances OBJECT IDENTIFIER ::= { cnTableConformance 2 } -- Units of Conformance cnTableGroup OBJECT-GROUP OBJECTS { cnIngressIfIndex, cnIngressCnId, cnEgressIfIndex, cnEgressCnId, cnIngressName, cnEgressName, cnAdminStatus, cnOperStatus, cnLastChange, cnSpecific } STATUS current DESCRIPTION "A collection of objects providing information applicable to Network Connections." ::= { cnTableGroups 1 } Rodemann Expires April 8, 1994 [Page 9] Draft Connection Table October 1993 -- Compliance Statements cnTableCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which implement the Connection Table." MODULE -- this module MANDATORY-GROUPS { cnTableGroup } OBJECT cnIngressName SYNTAX DisplayString MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT cnEgressName SYNTAX DisplayString MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT cnAdminStatus SYNTAX Integer MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT cnSpecific SYNTAX OBJECT IDENTIFIER MIN-ACCESS read-only DESCRIPTION "Write access is not required." END Rodemann Expires April 8, 1994 [Page 10] Draft Connection Table October 1993 6. References [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [2] Galvin, J., and K. McCloghrie, "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes LAN Systems, April 1993. [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Inc., Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [6] K. McCloghrie and F. Kastenholz, "Evolution of Interfaces Group of MIB-II", Internet Draft, Interfaces MIB Working Group, September 20, 1993. [7] K. Rodemann, "Service Management Architecture for Virtual Connection Services", Internet Draft, Frame Relay Service MIB Working Group, July 1, 1993. [8] T. Brown, "Definitions of Managed Objects for Frame Relay Service", Internet Draft, Frame Relay Service MIB Working Group, October 1, 1993. [9] M. Ahmed and K. Tesink, "Definitions of Managed Objects for ATM Management Version 1.0", Internet Draft, ATM MIB Working Group, August 9, 1993. Rodemann Expires April 8, 1994 [Page 11] Draft Connection Table October 1993 7. Security Considerations Security issues are not discussed in this memo. 8. Author's Address Kenneth R. Rodemann AT&T Bell Laboratories Room 1F-435A 101 Crawfords Corner Road PO Box 3030 Holmdel, NJ 07733-3030 908-949-6229 krr@qsun.att.com Rodemann Expires April 8, 1994 [Page 12] Table of Contents 1. Status of this Memo................................. 1 2. Abstract............................................ 1 3. The SNMPv2 Network Management Framework............. 2 3.1 Object Definitions............................. 2 4. Overview............................................ 3 5. Object Definitions.................................. 5 6. References.......................................... 11 7. Security Considerations............................. 12 8. Author's Address.................................... 12 - i -   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21855; 13 Oct 93 20:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21851; 13 Oct 93 20:37 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05051; 13 Oct 93 20:37 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 13 Oct 93 20:37:54 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA19706; Wed, 13 Oct 93 17:37:28 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA13760; Wed, 13 Oct 93 17:20:52 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310140020.AA13760@nms.hls.com> Subject: Re: ifExtnsChipSet To: Phil Budne Date: Wed, 13 Oct 93 17:20:51 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <9310051448.AA19079@Shiva.COM>; from "Phil Budne" at Oct 5, 93 10:48 am Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] Phil, > > 8.1. ifExtnsTable > > Resolution: ifExtnsRevWare, ifExtnsChipSet are deleted. > > I don't recall any announcement, poll, or discussion other than the > above. Was there? Only at the wg meeting in Amsterdam. > from draft-ietf-ifmib-evolution-02.txt; > > (7) Per the working group meeting in Amsterdam, > ifExtnsRevWare and ifExtnsChipSet were deleted from the > MIB on the basis that their exact use is very unclear. > It is quite possible in many interface architectures to > "mix and match" chipsets and drivers, leading to > ambiguity as to the intended contents of these objects. > > The use of the ifExtnsChipSets seems clear and straightforward for > MIBs which define such objects. If the problem is with the > interaction of the two object's values (mixing and matching) then why > not delete just one (my choice would be to keep 'ChipSet). > > While I found the objects a pain to implement, they are just the sort > of information I want to see when something sick starts happening on > my net! As I recall, there were two main comments on ifExtnsChipSets: - some technologies (e.g., FDDI) require multiple ICs, which cannot be represented by a single object (except by having OIDs for every possible combination: yuck). - the need for ifExtnsChipSets seemed important at the time it was defined because of a particular problem with one (or two?) chip-sets which had certain idiosyncrasies. Today, when those particular chip-sets are either fixed or no longer in use, the usefullness seems less important. As for ifExtnsRevWare, I believe the original need for it was because one ifIndex value represented all software/hardware/firmware between IP and the physical wire, and thus one ifDescr object was insufficient to describe them all. Now that multiple ifIndex values represent the stack, there are multiple ifDescr objects, and thus less the need for ifExtnsRevWare goes away. I have not seen anyone else comment in response to your suggestion, and I would propose that more than one person's opinion is needed to overturn the wg meeting decision. Perhaps, this message will encourage anyone who supports your suggestion to speak up. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00816; 14 Oct 93 4:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00812; 14 Oct 93 4:34 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa00601; 14 Oct 93 2:26 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 02:26:30 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA03853; Wed, 13 Oct 93 23:26:16 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA00814; Wed, 13 Oct 93 23:09:39 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310140609.AA00814@nms.hls.com> Subject: Re: IANA Textual Conventions To: Bob Stewart Date: Wed, 13 Oct 93 23:09:38 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <9310072123.AA20727@xap.xyplex.com>; from "Bob Stewart" at Oct 7, 93 4:23 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > I decided to find out for sure what IANA would be willing to do, so I asked > Jon Postel. I told him what I was proposing: either a separate document or a > piece of the existing assigned numbers document, formatted as an ASN.1 MIB > containing textual conventions arranged for easy addition of new lines for > new values. > > Here's his response, which showed up very shortly after I asked. > > >Bob: > > > >Yes. I am sure we can do what you suggest. > > > >--jon. > > So, now, why can't we change ifType to be a textual convention, InterfaceType, > and define that textual convention in a MIB-style document that is maintained > by IANA, thus allowing people to simply compile that standard document along > with their standard MIB, with NO editing unless they want to (easily) pick up > new values before a new version is released? > > (I'm going to keep pounding this sucker until it goes in or blows up. This > might be the once and for all answer to extending standard enumerations.) Well, since no one has objected, I guess it goes in !! I propose that we change the existing MIB Module in the Evolutions document as you suggest, with its IMPORTS of IANAInterfaceType from another MIB Module, and also include the first version of that second MIB Module in the Evolutions document (with a comment to say it will be re-issued by the IANA). Thus, the Evolutions document will be able to be used even before the IANA publish a new version, and if the IANA publish updated versions on-line, the folks who don't have Internet access will at least have an out-of-date version (rather than no version). Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07009; 14 Oct 93 12:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07005; 14 Oct 93 12:34 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14753; 14 Oct 93 12:34 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 12:34:09 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA13141; Thu, 14 Oct 93 09:33:54 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA01682; Thu, 14 Oct 93 09:17:14 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310141617.AA01682@nms.hls.com> Subject: Re: ifOperStatusDetail To: if-mib@thumper.bellcore.com Date: Thu, 14 Oct 93 9:17:13 PDT Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] Here's another outstanding proposal. It seemed to me that Robert's proposal captured the consensus of the preceeding mailing-list discussion, and since no one has spoken up since, everyone must be in agreement, right ? Keith. ----------- Forwarded message: > From snyder@cisco.com Fri Oct 8 11:45:39 1993 > Message-Id: <199310081849.AA27600@hubbub.cisco.com> > To: Robert Snyder > Cc: if-mib@thumper.bellcore.com > Subject: Re: ifOperStatusDetail > > > Hmmm. No response. Was I on the money, or so bogus that I frustrated > you all? > > Robert > > > -- using template mhl.format -- > > Date: Thu, 07 Oct 93 11:39:55 PDT > > To: if-mib@thumper.bellcore.com > > > > From: Robert Snyder > > Subject: ifOperStatusDetail > > > > Return-Path: snyder > > > > > > Ok here is my first attempt to bring this home... > > > > 1. ifOperStatus > > > > Remains unchanged. > > > > 2. ifOperStatusDetail is added to the ifTable > > > > ifOperStatusDetail OBJECT-TYPE > > SYNTAX OBJECT IDENTIFIER > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Provides more detail on the current operational > > state of the interface. For example: a dial on demand > > circuit that had the ifOperStatus of down might be > > set to the appropriate OID to indicate a current lack > > of demand for the circuit. > > If no appropriate OID exists to detail the current state > > the value should be set to the OBJECT IDENTIFIER { 0 0 }." > > ::= { ifEntry 23 } > > > > Depending on the reaction to the above I would propose some OIDs to > > seed this proposal, but I will wait for the reaction to the above > > first. > > > > Robert >   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07394; 14 Oct 93 12:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07390; 14 Oct 93 12:58 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15516; 14 Oct 93 12:58 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 12:58:21 EDT Received: by ftp.com id AA27420; Thu, 14 Oct 93 12:58:32 -0400 Date: Thu, 14 Oct 93 12:58:32 -0400 Message-Id: <9310141658.AA27420@ftp.com> To: kzm@hls.com, if-mib@thumper.bellcore.com Subject: Re: ifOperStatusDetail Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com > Here's another outstanding proposal. It seemed to me that Robert's > proposal captured the consensus of the preceeding mailing-list discussion, > and since no one has spoken up since, everyone must be in agreement, right ? Obviously someone is keeping better records as to what is left on the table than I am :-) Thanks Keith. > > > 1. ifOperStatus > > > > > > Remains unchanged. Actually, should have some additional DESCRIPTION text referring the manager off to ifOperStatusDetail for possible additional information. > > > I would propose some OIDs to > > > seed this proposal, but I will wait for the reaction to the above > > > first. I am not sure if there are any additional OIDs needed in the interface MIB. However, as other, medium-specific, MIBs are reviewed as they advance through the system, THEY most likely would get some OIDs that define extended status information. In other words, as this body now examines and considers OIDs to define here we must ask whether the OID belongs in the standard, generic, interface mib or in a medium specific MIB. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07792; 14 Oct 93 13:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07788; 14 Oct 93 13:20 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16095; 14 Oct 93 13:20 EDT Received: from hubbub.cisco.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 13:20:26 EDT Received: from glare.cisco.com by hubbub.cisco.com with SMTP id AA27754 (5.67a/IDA-1.5 for if-mib@thumper.bellcore.com); Thu, 14 Oct 1993 10:20:12 -0700 Message-Id: <199310141720.AA27754@hubbub.cisco.com> To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Subject: Re: ifOperStatusDetail In-Reply-To: Your message of "Thu, 14 Oct 93 12:58:32 EDT." <9310141658.AA27420@ftp.com> Date: Thu, 14 Oct 93 10:20:12 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Robert Snyder > I am not sure if there are any additional OIDs needed in the interface > MIB. However, as other, medium-specific, MIBs are reviewed as they > advance through the system, THEY most likely would get some OIDs that > define extended status information. In other words, as this body > now examines and considers OIDs to define here we must ask whether > the OID belongs in the standard, generic, interface mib or in a medium > specific MIB. I is my belief that if I can identify any generic ones, they belong in this mib. I may not be able to do so. Ones specific to a medium type, should be in the medium specific MIBs Robert   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07925; 14 Oct 93 13:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07920; 14 Oct 93 13:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa16183; 14 Oct 93 13:24 EDT Received: from monk.proteon.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 13:24:11 EDT Received: from hutch.proteon.com by monk.proteon.com (5.65/1.8) id AA10783; Thu, 14 Oct 93 13:25:10 -0400 Received: by hutch.proteon.com (4.1/SMI-4.1) id AA06695; Thu, 14 Oct 93 13:23:59 EDT Date: Thu, 14 Oct 93 13:23:59 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Arun V. Mahajan" Message-Id: <9310141723.AA06695@hutch.proteon.com> To: kzm@hls.com Subject: Re: ifOperStatusDetail Cc: if-mib@thumper.bellcore.com >Here's another outstanding proposal. It seemed to me that Robert's >proposal captured the consensus of the preceeding mailing-list discussion, >and since no one has spoken up since, everyone must be in agreement, right ? > >Keith. > >>Hmmm. No response. Was I on the money, or so bogus that I frustrated >> you all? >> >> Robert I agree. I had brought up an issue with the 'ifOperatorStatus' not being sufficient to handle the case of redundant interfaces (hot-standby types, or restoral types) at an early stage of this thread. BTW, one reason that this thread might have started is the inability of the current 'ifOperstatus' to handle newer and newer interface types, which could have more than the more common 3 states (up, down, testing) and adding 'unknown' is just not sufficient. I wish there was a way to link 'iftype' to 'ifOperatorStatus', but I have nothing concrete to say on that, so wont hold up the progress on Robert's proposal. thanks, .arun   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09365; 14 Oct 93 14:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09356; 14 Oct 93 14:23 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19341; 14 Oct 93 14:23 EDT Received: from inet-gw-2.pa.dec.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 14:23:07 EDT Received: by inet-gw-2.pa.dec.com; id AA07359; Thu, 14 Oct 93 11:23:04 -0700 Received: by us1rmc.bb.dec.com; id AA24733; Thu, 14 Oct 93 14:21:57 -0400 Message-Id: <9310141821.AA24733@us1rmc.bb.dec.com> Received: from levers.enet; by us1rmc.enet; Thu, 14 Oct 93 14:22:07 EDT Date: Thu, 14 Oct 93 14:22:07 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anil Rijsinghani To: kzm@hls.com Cc: if-mib@thumper.bellcore.com Apparently-To: if-mib@thumper.bellcore.com, kzm@hls.com Subject: Re: ifOperStatusDetail Some comments on the proposals. Experience has shown that there has been a need to add to the list of ifTypes -- probably because over the last couple of years, new interfaces have cropped up, and in addition SNMP has been implemented in an increasing number of different systems and environments. As it turns out, the only other object that I have felt a need to add enumerations to has also been related to interface (media type). In general however, the above does not hold true for all objects that can have different values. The practice of using enumerated types should not be migrated to OID's in every case. Of 100's of enumerated types I have seen in MIBs, there have only been 2 that I've wanted to extend. Not only is it inconvenient based on the way that SNMP has been used so far, but the limiting of values is actually a feature -- if one could choose from a rich and expanding set of values, then in all probability different vendors will not come up with the same choice for the same thing, thus confusing the user. (example: should I use 'ethernet' or 'iso88023'? note that this was from an enumeration, but it illustrates the point -- it would be a lot easier to do this with OID's.) Also, let's look at operational experience. ifSpecific, an OID, has been around for a while. How many nms's print out instead of the OID, "Ethernet MIB", or "abc MIB of corporation xyz"? If not too many, why not? I don't believe that ifOperStatus needs to be made an OID. Firstly, if a value doesn't apply on a generic basis then it shouldn't be here.. there seems to be agreement on this (else there could be a near infinite number of possible values that could be assigned to it). Second, once the WG agrees upon a set of status values that apply generically today then we couldn't come up with more later (since if they don't apply to all now, they couldn't possibly apply to all later). Let's just add enumerations. Anil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09959; 14 Oct 93 14:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09955; 14 Oct 93 14:38 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22001; 14 Oct 93 14:38 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 14:39:01 EDT Received: by ftp.com id AA02268; Thu, 14 Oct 93 14:38:52 -0400 Date: Thu, 14 Oct 93 14:38:52 -0400 Message-Id: <9310141838.AA02268@ftp.com> To: anil@levers.enet.dec.com Subject: Re: ifOperStatusDetail Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Cc: kzm@hls.com, if-mib@thumper.bellcore.com The proposal on the table is to keep ifOperStatus as an enumerated integer with the same values as today. A new object will be added, ifOperMoreStatus (or something like that) that is an OID. This object will allow for a rich set of detailed statuses to be made available. The object will not replace, supplant, supersede, do away with, or in any way lessen the utility of, ifOperStatus. BOTH will be exported by an agent, and a manager can choose which one to look at. I believe that this mechanism gives us A) The advantages of a relative few number of "generic statuses" (which you enumerate) via ifOperStatus, and B) the advantages of detailed, highly specific statuses (via ifOperMoreStatus). I think that we get the best of both worlds, and do not give anything up. > I don't believe that ifOperStatus needs to be made an OID. Firstly, if > a value doesn't apply on a generic basis then it shouldn't be here.. there > seems to be agreement on this (else there could be a near infinite number > of possible values that could be assigned to it). Second, once the WG > agrees upon a set of status values that apply generically today then we > couldn't come up with more later (since if they don't apply to all now, > they couldn't possibly apply to all later). Let's just add enumerations. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12563; 14 Oct 93 15:59 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12558; 14 Oct 93 15:59 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa29540; 14 Oct 93 15:59 EDT Received: from inet-gw-2.pa.dec.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 14 Oct 93 15:59:38 EDT Received: by inet-gw-2.pa.dec.com; id AA13373; Thu, 14 Oct 93 12:59:07 -0700 Received: by us1rmc.bb.dec.com; id AA00326; Thu, 14 Oct 93 15:57:56 -0400 Message-Id: <9310141957.AA00326@us1rmc.bb.dec.com> Received: from levers.enet; by us1rmc.enet; Thu, 14 Oct 93 15:58:10 EDT Date: Thu, 14 Oct 93 15:58:10 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anil Rijsinghani To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Apparently-To: if-mib@thumper.bellcore.com, kasten@ftp.com Subject: Re: ifOperStatusDetail > I believe that this mechanism gives us A) The advantages of a relative > few number of "generic statuses" (which you enumerate) via ifOperStatus, > and B) the advantages of detailed, highly specific statuses (via > ifOperMoreStatus). I think that we get the best of both worlds, and > do not give anything up. Could you, or Robert, give some examples please? Also, if there was a list of proposed values then that would help determine how useful this would be, and whether it really needs to be separate from OperStatus. thanks, Anil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07125; 15 Oct 93 11:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07121; 15 Oct 93 11:14 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21566; 15 Oct 93 11:14 EDT Received: from mail.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 15 Oct 93 10:41:09 EDT Received: from freeze (freeze.bellcore.com) by mail.bellcore.com (5.65c/2.1) id AA24942; Fri, 15 Oct 1993 10:36:50 -0400 Return-Path: Received: by freeze (4.1/4.7) id AA07524; Fri, 15 Oct 93 10:47:03 EDT Date: Fri, 15 Oct 93 10:47:03 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Masuma Ahmed X-Station-Sent-From: freeze.bellcore.com Message-Id: <9310151447.AA07524@freeze> To: asmith@synoptics.com, kzm@hls.com, ddp@fore.com Subject: Re: use of ifTable for the atm layer Cc: atommib@thumper.bellcore.com, if-mib@thumper.bellcore.com, salil@freeze.bellcore.com > > > (1) Should ifPhysAddress have 19 or 20 octets in it? > > > > I think 20 octets. > > > > > If 20, what should the selector contain? The ATM Forum requires ATM address to be always 20 octets ( please see version 2.4). > I have never noticed anything in the ATM Forum spec which said to ignore > the selector. For the purpose of Address Registration, the value of the SEL field is ignored ( please see version 2.4). Masuma mxa@mail.bellcore.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09192; 15 Oct 93 13:02 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09188; 15 Oct 93 13:02 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa24680; 15 Oct 93 13:02 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 15 Oct 93 13:02:29 EDT Received: by xap.xyplex.com id ; Fri, 15 Oct 93 15:03:24 -0500 Date: Fri, 15 Oct 93 15:03:24 -0500 Message-Id: <9310152003.AA21546@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: if-mib@thumper.bellcore.com In-Reply-To: Keith McCloghrie's message of Wed, 13 Oct 93 23:09:38 PDT <9310140609.AA00814@nms.hls.com> Subject: Re: IANA Textual Conventions >I propose that we change the existing MIB Module in the Evolutions >document as you suggest, with its IMPORTS of IANAInterfaceType from >another MIB Module, and also include the first version of that second >MIB Module in the Evolutions document (with a comment to say it will >be re-issued by the IANA). I like it. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19543; 17 Oct 93 17:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19539; 17 Oct 93 17:03 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12230; 17 Oct 93 17:03 EDT Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Sun, 17 Oct 93 17:03:29 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA17259; Sun, 17 Oct 93 14:02:13 -0700 To: if-mib@thumper.bellcore.com Subject: ifSpecific Reply-To: if-mib@thumper.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <17254.750891731.1@dbc.mtview.ca.us> Date: Sun, 17 Oct 1993 14:02:12 -0700 Message-Id: <17256.750891732@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Each time I review review the latest version of the If-Evolution MIB, I keep asking myself why ifSpecific is there. At this late date, I wonder if I could not prevail upon the other members of the WG to remove this object? Here's my rationale: ifSpecific is supposed to tell the management station what MIB module to look in for further information. For example, if ifType=dot3, then ifSpecific likely points to the dot3 MIB module. But, because there may be multiple MIB modules (the standard dot3, and one or more enterprise-specific dot3 MIB modules), there is no way of indicating all of them with just ifSpecific. But, the management station can not make use of this information anyway, unless it already has knowledge of the semantics of that MIB. So, ifSpecific doesn't help: if the management station sees that ifType=dot3, then it can have its own internal list of the MIB modules it knows about that relate to dot3 interfaces! This leads to: 1. Make ifSpecific a table, so for each interface, there may be zero or more MIB modules identified. 2. Get rid of ifSpecific. I suggest that the best fix is #2. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28517; 18 Oct 93 1:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28513; 18 Oct 93 1:42 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa21888; 18 Oct 93 1:42 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 18 Oct 93 01:42:40 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA01429; Sun, 17 Oct 93 22:42:26 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA16548; Sun, 17 Oct 93 22:25:23 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310180525.AA16548@nms.hls.com> Subject: Re: ifSpecific To: if-mib@thumper.bellcore.com Date: Sun, 17 Oct 93 22:25:22 PDT In-Reply-To: <17256.750891732@dbc.mtview.ca.us>; from "Marshall Rose" at Oct 17, 93 2:02 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > Each time I review review the latest version of the If-Evolution MIB, I > keep asking myself why ifSpecific is there. At this late date, I wonder > if I could not prevail upon the other members of the WG to remove this object? > > Here's my rationale: > ... > This leads to: > > 1. Make ifSpecific a table, so for each interface, there may be zero or > more MIB modules identified. > > 2. Get rid of ifSpecific. > > I suggest that the best fix is #2. OK, I concede. I have argued to keep ifSpecific, knowing that it is not perfect, but thinking that it is of some value. Of the two alternatives you list, I certainly agree that getting rid of it is better than a table. Does anyone else want to argue in favour of keeping ifSpecific ? Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02321; 18 Oct 93 9:41 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02313; 18 Oct 93 9:41 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02228; 18 Oct 93 9:41 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 18 Oct 93 09:41:37 EDT Received: by ftp.com id AA17643; Mon, 18 Oct 93 09:41:46 -0400 Date: Mon, 18 Oct 93 09:41:46 -0400 Message-Id: <9310181341.AA17643@ftp.com> To: if-mib@thumper.bellcore.com Subject: This and That Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Well, it is now about two weeks until we all see each other in Houston. So, in preparation for that meeting your humble editors wish to clear up some loose ends in the draft. We believe that there are two, ifOperStatusDetail and ifSpecific. ifSpecific. A suggestion was made that ifSpecific is redundant with respect to ifType and that it should be removed. Please think about this and make any comments over the next day or two. ifOperStatusDetail. This object will be added to the MIB. It will be an OID since OIDs (as opposed to DisplayStrings) are unambiguous, have no problems with character sets or languages, and can be administered in a distributed manner and are globally unique. As a part of this effort, the suggestion was made that there be some common, standardized, generic, values for this object. So, please think of any such values and suggest them on the list. When thinking about this please bear in mind that this object refines or extends the information provided in ifOperStatus (so a value like "down" is not necessary) and the values should be pretty generic -- they ought to be applicable to several different interface types (a value such as `802.3-10baseT-link-test-failure' is probably not generic enough to be included in this document). I plan to do the final edit on the document Wednesday afternoon and submit it for internet-draft publication then so please have any comments to the list by then. Naturally, any other comments on the interface extensions mib are always welcome, but, since time is now of the essence in order to get a draft published well in advance of the IETF meeting, such comments may not make it into the draft, or may be tabled for discussion at the IETF or after. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05094; 18 Oct 93 11:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05090; 18 Oct 93 11:46 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06614; 18 Oct 93 11:46 EDT Received: from inet-gw-2.pa.dec.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 18 Oct 93 11:47:01 EDT Received: by inet-gw-2.pa.dec.com; id AA01783; Mon, 18 Oct 93 08:46:56 -0700 Received: by us1rmc.bb.dec.com; id AA28597; Mon, 18 Oct 93 11:45:40 -0400 Message-Id: <9310181545.AA28597@us1rmc.bb.dec.com> Received: from levers.enet; by us1rmc.enet; Mon, 18 Oct 93 11:45:59 EDT Date: Mon, 18 Oct 93 11:45:59 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Anil Rijsinghani To: kasten@ftp.com Cc: if-mib@thumper.bellcore.com Apparently-To: if-mib@thumper.bellcore.com, kasten@ftp.com Subject: RE: This and That >ifSpecific. A suggestion was made that ifSpecific is redundant with > respect to ifType and that it should be removed. Please think > about this and make any comments over the next day or two. I agree.. please remove it. >ifOperStatusDetail. This object will be added to the MIB. It will be > an OID since OIDs (as opposed to DisplayStrings) are unambiguous, have > no problems with character sets or languages, and can be administered > in a distributed manner and are globally unique. Note that there are other objects in the MIB that are DisplayString, so "problems with character sets or languages" haven't really been dealt with. (nor should it be addressed in individual MIBs, but rather at the SNMP level.. perhaps when the SNMPv2 group reactivates.) > As a part of this > effort, the suggestion was made that there be some common, > standardized, generic, values for this object. So, please think of > any such values and suggest them on the list. When thinking about > this please bear in mind that this object refines or extends the > information provided in ifOperStatus (so a value like "down" > is not necessary) and the values should be pretty generic -- they > ought to be applicable to several different interface types (a > value such as `802.3-10baseT-link-test-failure' is probably > not generic enough to be included in this document). If you were referring to my suggestion to Keith, I wasn't arguing for generic values, of which I don't think there will be any; I was saying that lists of values for *specific* interfaces should be standardized, so that everybody doesn't end up using vendor-specific values. If the latter happened, you may as well use DisplayString. Anil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06971; 18 Oct 93 13:03 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06967; 18 Oct 93 13:03 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09053; 18 Oct 93 13:03 EDT Received: from merlin.cs.purdue.edu by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Mon, 18 Oct 93 12:21:47 EDT Received: from localhost by merlin.cs.purdue.edu (5.65c/PURDUE_CS-1.2) id ; Mon, 18 Oct 1993 11:21:44 -0500 Message-Id: <199310181621.AA27072@merlin.cs.purdue.edu> To: if-mib@thumper.bellcore.com Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com, mrose@dbc.mtview.ca.us Subject: Redefinition of if*UcastPkts Date: Mon, 18 Oct 1993 11:21:43 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Kenneth R Rodemann With the effort of redefining the Interfaces Group, we have considered the usefulness of the current set of variables and have deprecated some variables while introducing others. In one such example, the new definition now distinguishes between multicast and broadcast packets by deprecating ifInNUcastPkts and adding ifInMulticastPkts and ifInBroadcastPkts (similarly for the Out direction). In this light, I would like the following proposal seriously considered, dismissing this proposal only with compelling enough arguments against it. When all the arguments for and against have been raised, then let's take it to a vote. WLOG, consider the In variables: ifInOctets Counter32, ifInUcastPkts Counter32, ifInMulticastPkts Counter32, ifInBroadcastPkts Counter32, ifInDiscards Counter32, ifInErrors Counter32, ifInUnknownProtos Counter32, The Case diagram for the current redefinition work for these variables looks like this: layer above - - - - - - - - - - - - - - - ^ ^ ifInUcastPkts+ | | ifInMulticastPkts+ ----- | ifInBroadcastPkts | | | | ifInDiscards <--| | | | ifInUnknownProtos <--| | | | ifInErrors <--| | | | | ----- ifInOctets | | - - - - - - - - - - - - - - - layer below Note that if*Pkts are counted at a different place than ifInOctets. Also note that this current definition has lead to difficulty in both the Frame Relay Service MIB and AToMMIB efforts. The difficulty comes from some switch implementations that cannot count certain variables (one reason being the use of shared buffer fabrics). To remedy this deficiency, I propose that ifInU[ni]castPkts, ifInMulticastPkts, and ifInBroadcastPkts be counted consistently (at the same place) as ifInOctet, as diagramed: layer above - - - - - - - - - - - - - - - ^ ^ | | ifInDiscards <--| | | | ifInUnknownProtos <--| | | | ifInErrors <--| | | | ifInUnicastPkts+ | | ifInMulticastPkts+ ----- ----- ifInOctets ifInBroadcastPkts | | | | - - - - - - - - - - - - - - - layer below The changes to effect this are: (1) introduce a new variable, ifInUnicastPkts, with the following DESCRIPTION: "The number of packets, delivered to this sub-layer from a lower (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer." (2) deprecate ifInUcastPkts (3) modify the DESCRIPTION clauses for ifInMulticastPkts and ifInBroadcastPkts similar to the DESCRIPTION for ifInUnicastPkts. The same will be done for variables in the Out direction. Let's lay all the arguments for and against this proposal on the table, then vote. To start things off, here are my arguments for this proposal: (1) Will provide consistent counting between octet and packet counters. (2) Will allow FR Service MIB and AToMMIB (and future such efforts) to use ifTable (regarding if*U[ni]castPkts) without difficulty. (3) This is more intuitive. For example, out of a small survey of 3 agent implementors, 2 out of the 3 said that their implementation already counted ifInU[ni]castPkts this way. The reason: they didn't read the DESCRIPTION clause closely enough, but implemented the counters intuitively. How many others already implement if*U[ni]castPkts this way!! Cheers, Ken Rodemann AT&T Bell Laboratories krr@qsun.att.com 908-949-6229   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08896; 19 Oct 93 11:34 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08892; 19 Oct 93 11:34 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09445; 19 Oct 93 11:34 EDT Received: from att.att.com (gw1.att.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 19 Oct 93 11:34:51 EDT Message-Id: <9310191534.AA14893@thumper.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmurali@qsun.att.com Date: Tue, 19 Oct 93 11:26 EDT To: if-mib@thumper.bellcore.com Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com Subject: RE: Redefinition of if*UcastPkts > >From: krr@cs.purdue.edu (Kenneth R Rodemann) >Subject: Redefinition of if*UcastPkts >Date: Mon, 18 Oct 1993 11:21:43 -0500 > > >With the effort of redefining the Interfaces Group, we have considered the >usefulness of the current set of variables and have deprecated some variables >while introducing others. In one such example, the new definition now > > ... > >Cheers, >Ken Rodemann I concur. This is cleaner and allows the ifMIB to be more generic (read: implementable by more protocols), as it should be. /Baktha Muralidharan Consultant AT&T Bell Laboratories (908) 949 1272.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09921; 19 Oct 93 12:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09917; 19 Oct 93 12:07 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10654; 19 Oct 93 12:07 EDT Received: from att.att.com (gw1.att.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 19 Oct 93 11:34:56 EDT Message-Id: <9310191534.AA14901@thumper.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmurali@qsun.att.com Date: Tue, 19 Oct 93 11:26 EDT To: if-mib@thumper.bellcore.com Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com Subject: RE: Redefinition of if*UcastPkts > >From: krr@cs.purdue.edu (Kenneth R Rodemann) >Subject: Redefinition of if*UcastPkts >Date: Mon, 18 Oct 1993 11:21:43 -0500 > > >With the effort of redefining the Interfaces Group, we have considered the >usefulness of the current set of variables and have deprecated some variables >while introducing others. In one such example, the new definition now > > ... > >Cheers, >Ken Rodemann I concur. This is cleaner and allows the ifMIB to be more generic (read: implementable by more protocols), as it should be. /Baktha Muralidharan Consultant AT&T Bell Laboratories (908) 949 1272.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10068; 19 Oct 93 12:14 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10064; 19 Oct 93 12:14 EDT Received: from nsco.network.com by CNRI.Reston.VA.US id aa10803; 19 Oct 93 12:14 EDT Received: from gw1.att.com by nsco.network.com (5.61/1.34) id AA22448; Tue, 19 Oct 93 10:38:03 -0500 Message-Id: <9310191538.AA22448@nsco.network.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: bmurali@qsun.att.com Date: Tue, 19 Oct 93 11:26 EDT To: if-mib@thumper.bellcore.com Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com Subject: RE: Redefinition of if*UcastPkts > >From: krr@cs.purdue.edu (Kenneth R Rodemann) >Subject: Redefinition of if*UcastPkts >Date: Mon, 18 Oct 1993 11:21:43 -0500 > > >With the effort of redefining the Interfaces Group, we have considered the >usefulness of the current set of variables and have deprecated some variables >while introducing others. In one such example, the new definition now > > ... > >Cheers, >Ken Rodemann I concur. This is cleaner and allows the ifMIB to be more generic (read: implementable by more protocols), as it should be. /Baktha Muralidharan Consultant AT&T Bell Laboratories (908) 949 1272.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10575; 19 Oct 93 12:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10571; 19 Oct 93 12:47 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa11698; 19 Oct 93 12:47 EDT Received: from ormail.intel.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Tue, 19 Oct 93 12:19:00 EDT Received: from intelhf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #2) id m0opJi8-000MPjC; Tue, 19 Oct 93 09:15 PDT Received: from ccm by intelhf.intel.com with uucp (Smail3.1.28.1 #1) id m0opJn1-00016iC; Tue, 19 Oct 93 09:20 PDT Received: by ccm.hf.intel.com (ccmgate) Tue, 19 Oct 93 09:20:03 PST Date: Tue, 19 Oct 93 09:20:03 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Shawn Lindow Message-Id: <931019092003_1@ccm.hf.intel.com> To: bmurali@qsun.att.com, if-mib@thumper.bellcore.com Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com Subject: UNSUBSCRIBE - Please. Sorry to do this via a reply but I receive these messages via ccMail and it strips out the address I need. Please UNSUBSCRIBE me. Thanks. > >From: krr@cs.purdue.edu (Kenneth R Rodemann) >Subject: Redefinition of if*UcastPkts >Date: Mon, 18 Oct 1993 11:21:43 -0500 > > >With the effort of redefining the Interfaces Group, we have considered the >usefulness of the current set of variables and have deprecated some variables - >while introducing others. In one such example, the new definition now > > ... > >Cheers, >Ken Rodemann I concur. This is cleaner and allows the ifMIB to be more generic (read: implementable by more protocols), as it should be. /Baktha Muralidharan Consultant AT&T Bell Laboratories (908) 949 1272.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18059; 20 Oct 93 17:50 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18055; 20 Oct 93 17:50 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27343; 20 Oct 93 17:50 EDT Received: from lobster.wellfleet.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 20 Oct 93 17:50:14 EDT Received: from sargon.wellfleet.com by lobster.wellfleet.com (4.1/SMI-4.1) id AA16195; Wed, 20 Oct 93 17:40:19 EDT Received: by sargon.wellfleet.com (4.1/SMI-4.1) id AA02695; Wed, 20 Oct 93 17:51:37 EDT Date: Wed, 20 Oct 93 17:51:37 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Onishi Message-Id: <9310202151.AA02695@sargon.wellfleet.com> To: if-mib@thumper.bellcore.com Subject: Vital constancy Page 10 of the recent draft states: The vital constancy requirement is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used (by another dynamically added interface) until after the following re-initialization of the network management system. This avoids the need for a priori assignment of ifIndex values for all possible interfaces which might be added dynamically. What exactly does it mean by re-initialization of the network management system? Is there more than one interpretation of this? - SteveO   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18362; 20 Oct 93 18:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18358; 20 Oct 93 18:07 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27765; 20 Oct 93 18:07 EDT Received: from lanslide.hls.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 20 Oct 93 18:07:54 EDT Received: from nms.hls.com by lanslide.hls.com (4.1/SMI-4.0) id AA19897; Wed, 20 Oct 93 15:07:41 PDT Received: by nms.hls.com (4.1/SMI-4.1) id AA27712; Wed, 20 Oct 93 14:50:20 PDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Keith McCloghrie Message-Id: <9310202150.AA27712@nms.hls.com> Subject: Re: Vital constancy To: Steve Onishi Date: Wed, 20 Oct 93 14:50:19 PDT Cc: if-mib@thumper.bellcore.com In-Reply-To: <9310202151.AA02695@sargon.wellfleet.com>; from "Steve Onishi" at Oct 20, 93 5:51 pm Organization: Hughes LAN Systems X-Mailer: ELM [version 2.2 PL0] > Page 10 of the recent draft states: > > The vital constancy requirement is met by > requiring that after an interface is dynamically removed, its > ifIndex value is not re-used (by another dynamically added > interface) until after the following re-initialization of the > network management system. This avoids the need for a priori > assignment of ifIndex values for all possible interfaces which > might be added dynamically. > > What exactly does it mean by re-initialization of the network management > system? Is there more than one interpretation of this? It was intended to relate directly to the value of sysUpTime. Now, RFC 1213 actually says: sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." ::= { system 3 } i.e., it uses the word "portion". Perhaps, "portion" should be added to the paragraph you quote from page 10, and a parenthetical reference added to sysUpTime. Keith.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18562; 20 Oct 93 18:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18558; 20 Oct 93 18:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa28132; 20 Oct 93 18:24 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 20 Oct 93 18:24:20 EDT Received: by ftp.com id AA15177; Wed, 20 Oct 93 18:24:32 -0400 Date: Wed, 20 Oct 93 18:24:32 -0400 Message-Id: <9310202224.AA15177@ftp.com> To: if-mib@thumper.bellcore.com Subject: New MIB Version Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com A new draft of the MIB is on its way to the internet draft repositories. This version of the draft will be the subject for the discussions in Houston. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15091; 21 Oct 93 13:20 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15087; 21 Oct 93 13:20 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18490; 21 Oct 93 13:20 EDT Received: from emory.mathcs.emory.edu by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 21 Oct 93 13:21:03 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: cheryl@empiretech.com Received: from indigo.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.12) via UUCP id AA09128 ; Thu, 21 Oct 93 13:21:00 -0400 Return-Path: cheryl@empiretech.com Received: by indigo.mese.com (DECUS UUCP /2.0/2.0/2.0/); Thu, 21 Oct 93 13:07:56 EDT Received: from emptech by INDIGO.MESE.COM (MX V3.1) with UUCP; Thu, 21 Oct 1993 10:10:09 EDT Received: by emptech.empiretech.com (4.1/SMI-4.1) id AA03621; Thu, 21 Oct 93 09:14:33 EDT Message-Id: <9310211314.AA03621@emptech.empiretech.com> Subject: Re: Vital constancy To: kzm@hls.com Date: Thu, 21 Oct 1993 09:14:32 -0400 (EDT) Cc: sonishi@wellfleet.com, if-mib@thumper.bellcore.com In-Reply-To: <9310202150.AA27712@nms.hls.com> from "kzm@hls.com" at Oct 20, 93 02:50:19 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2606 > >> Page 10 of the recent draft states: >> >> The vital constancy requirement is met by >> requiring that after an interface is dynamically removed, its >> ifIndex value is not re-used (by another dynamically added >> interface) until after the following re-initialization of the >> network management system. This avoids the need for a priori >> assignment of ifIndex values for all possible interfaces which >> might be added dynamically. >> >> What exactly does it mean by re-initialization of the network management >> system? Is there more than one interpretation of this? > >It was intended to relate directly to the value of sysUpTime. >Now, RFC 1213 actually says: > > sysUpTime OBJECT-TYPE > SYNTAX TimeTicks > ACCESS read-only > STATUS mandatory > DESCRIPTION > "The time (in hundredths of a second) since the > network management portion of the system was last > re-initialized." > ::= { system 3 } > >i.e., it uses the word "portion". Perhaps, "portion" should be added >to the paragraph you quote from page 10, and a parenthetical reference >added to sysUpTime. > >Keith. > Hmmm. The current Page 10 text made me think that the network mangement _station_ had to be re-initialized (which didn't make sense) instead of the agent. I suggest the following wording: The vital constancy requirement is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used (by another dynamically added * interface) until after the network management portion of the * system is re-initialized (sysUpTime reflects the time since the * last re-initialization). This avoids the need for a priori assignment of ifIndex values for all possible interfaces which might be added dynamically. The reference to sysUpTime helps explain what is meant by the re-initialization. It also makes more sense to add the parenthetical reference to ifIndex instead of adding it to sysUpTime; sysUpTime is used in conjunction with lots of other MIB objects (not just the ifTable). ( my .02 worth ) - Cheryl +--------------------------------------------------------------------+ + Cheryl Krupczak Empire Technologies, Inc. + + cheryl@empiretech.com 500-D7 Northside Circle NW+ + (404)350-0107 Atlanta, GA 30309 + +--------------------------------------------------------------------+   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21789; 21 Oct 93 16:58 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24291; 21 Oct 93 16:58 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21742; 21 Oct 93 16:58 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21348; 21 Oct 93 16:54 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: if-mib@thumper.bellcore.com Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ifmib-conntable-00.txt Date: Thu, 21 Oct 93 16:54:01 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9310211654.aa21348@IETF.CNRI.Reston.VA.US> --NextPart Note: This is a re-send announcement with a filename change. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interfaces MIB Working Group of the IETF. Title : Management Information Base for Management of Network Connections Author(s) : K. Rodemann Filename : draft-ietf-ifmib-conntable-00.txt Pages : 12 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines managed objects used for managing Network Connections. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-ifmib-conntable-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE draft-ietf-ifmib-conntable-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931021095536.I-D@CNRI.Reston.VA.US> FILE draft-ietf-ifmib-conntable-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ifmib-conntable-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931021095536.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21818; 21 Oct 93 16:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21792; 21 Oct 93 16:58 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24293; 21 Oct 93 16:58 EDT Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21743; 21 Oct 93 16:58 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21388; 21 Oct 93 16:54 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: if-mib@thumper.bellcore.com X-Orig-Sender:ietf-announce-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-ifmib-evolution-04.txt Date: Thu, 21 Oct 93 16:54:20 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Message-ID: <9310211654.aa21388@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interfaces MIB Working Group of the IETF. Title : Evolution of the Interfaces Group of MIB-II Author(s) : K. McCloghrie, F. Kastenholz Filename : draft-ietf-ifmib-evolution-04.txt Pages : 66 Abstract not provided. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-ifmib-evolution-04.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE draft-ietf-ifmib-evolution-04.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931021101936.I-D@CNRI.Reston.VA.US> FILE draft-ietf-ifmib-evolution-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ifmib-evolution-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931021101936.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23101; 21 Oct 93 17:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23097; 21 Oct 93 17:39 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25814; 21 Oct 93 17:39 EDT Received: from vela.acs.oakland.edu by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 21 Oct 93 17:39:09 EDT Received: from via.ccb3.merit.edu by vela.acs.oakland.edu with SMTP id AA20528 (5.65c+/IDA-1.4.4); Thu, 21 Oct 1993 17:27:47 -0400 Date: Thu, 21 Oct 93 15:06:19 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Message-Id: <1570.bill.simpson@um.cc.umich.edu> To: if-mib@thumper.bellcore.com Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com Reply-To: bsimpson@morningstar.com Subject: Re: Redefinition of if*UcastPkts > To remedy this deficiency, I propose that ifInU[ni]castPkts, ifInMulticastPkts, > and ifInBroadcastPkts be counted consistently (at the same place) as > ifInOctet, as diagramed: > I like the idea of counting them in the same place. This was hard to get right in my code. However, I don't think that you have it at the right place. For PPP Link Quality Monitoring, we had to make a special variable called "InGoodOctets" to count the octets that were actually delivered. It is pretty hard to really count InUnicast before Errors, Discards, or Unknown, because they might be done on another board. Can't tell whether it was Unicast or Multicast when it was thrown away due to bad checksum. Also, when HDLC flags are munged, two packets turn into one. Therefore, I suggest the following: > layer above > - - - - - - - - - - - - - - - > ^ ifInUnicastPkts+ | ifInMulticastPkts+ ----- ifInOctets ifInBroadcastPkts | > | > ifInDiscards <--| > | > ifInUnknownProtos <--| > | > ifInErrors <--| > | > | > - - - - - - - - - - - - - - - > layer below > This means changing Octets, rather than Unicast. Bill.Simpson@um.cc.umich.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23500; 21 Oct 93 18:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23496; 21 Oct 93 18:06 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26574; 21 Oct 93 18:06 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 21 Oct 93 18:06:44 EDT Received: by ftp.com id AA18995; Thu, 21 Oct 93 18:02:26 -0400 Date: Thu, 21 Oct 93 18:02:26 -0400 Message-Id: <9310212202.AA18995@ftp.com> To: if-mib@thumper.bellcore.com, atommib@thumper.bellcore.com, frftc@nsco.network.com Subject: Re: Redefinition of if*UcastPkts Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Changing these counters in the manner suggested means that the current MIB objects would have to be deprecated and new ones added. It has been a goal of your humble editors to keep changes to existing objects as few as possible, thereby allowing manager stations that do not understand the new and improved ifMIB to be able to get some useful information out of agents that support said new and improved if MIB. Also, be reducing the number of things that need to be changed, it is just that much easier to upgrade current agents to the new MIB. However, it is always useful to reexamine one's goals and objectives periodically. This goal of ours was formulated way back in the early days of this effort. It might be worth re-examining this goal in light of the changes that _have_ been made vis-a-vis MIB-II. Since a fair number of people who might have an interest in this discussion are, no doubt, on their way to Paris (or are already there) I would suggest that any decisions vis-a-vis this change be held until we can discuss it in Houston. Naturally, discussion can continue here and now, but I would expect that the interested parties be prepared to rediscuss everything at the IETF meeting. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24223; 21 Oct 93 19:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24219; 21 Oct 93 19:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa28008; 21 Oct 93 19:10 EDT Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com) by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 21 Oct 93 19:07:52 EDT Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4R2.01/dg-rtp-v02) id AA26668; Thu, 21 Oct 1993 19:07:49 -0400 Received: by walrus (5.4R3.00/140.2) id AA09203; Thu, 21 Oct 1993 19:07:47 -0400 Date: Thu, 21 Oct 1993 19:07:47 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Dean D. Throop" Message-Id: <9310212307.AA09203@walrus> To: if-mib@thumper.bellcore.com Subject: Re: Redefinition of if*UcastPkts > From bill.simpson@um.cc.umich.edu Thu Oct 21 17:55:04 1993 > Date: Thu, 21 Oct 93 15:06:19 EDT > From: "William Allen Simpson" > Message-Id: <1570.bill.simpson@um.cc.umich.edu> > To: if-mib@thumper.bellcore.com > Cc: atommib@thumper.bellcore.com, frftc@nsco.network.com > > > To remedy this deficiency, I propose that ifInU[ni]castPkts, ifInMulticastPkts, > > and ifInBroadcastPkts be counted consistently (at the same place) as > > ifInOctet, as diagramed: > > > I like the idea of counting them in the same place. This was hard to > get right in my code. However, I don't think that you have it at the > right place. For interfaces such as LAPB, it really makes no sense to count them at different places. LAPB has a number of packets that the peers exchange in addition to the number of packets the interface sends up the stack. Thus the peers may exchange a large number of octets while the upper levels may only see a few packets. The diagram also needs to reflect that peer2peerTraffic can be extracted. > > layer above > > - - - - - - - - - - - - - - - > > ^ > ifInUnicastPkts+ | > ifInMulticastPkts+ ----- ifInOctets > ifInBroadcastPkts | |-> peer2peerTraffic > > | > > ifInDiscards <--| > > | > > ifInUnknownProtos <--| > > | > > ifInErrors <--| > > | > > | > > - - - - - - - - - - - - - - - > > layer below > > Right now the LAPB and X.25 MIBs explicitly clarify that ifInOctets counts octets exchanged between the peers and ifInUnicastPkts counts packets sent up the stack. Dean Throop throop@dg-rtp.dg.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02682; 22 Oct 93 8:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02678; 22 Oct 93 8:12 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07316; 22 Oct 93 8:12 EDT Received: from ftp.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Fri, 22 Oct 93 08:12:32 EDT Received: by ftp.com id AA29169; Fri, 22 Oct 93 08:12:45 -0400 Date: Fri, 22 Oct 93 08:12:45 -0400 Message-Id: <9310221212.AA29169@ftp.com> To: if-mib@thumper.bellcore.com Subject: [Forwarded: Current IETF Documents Archive] Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Frank Kastenholz Reply-To: kasten@ftp.com Just to pass the word along -- the people who maintain the document archives are creating a "Current IETF Documents" archive that should have documents in it specifically for the upcomming IETF meeting. I have asked that they put the ifmib evolution document in this archive. The announcement of this from the internic follows. Frank Kastenholz ------------------------------------------------------------------------ Date: Thu, 21 Oct 93 19:19:02 EDT From: DDBS Admin To: ietf@IETF.CNRI.Reston.VA.US Subject: Current IETF Documents Archive Cc: admin@ds.internic.net, sri@ds.internic.net ANNOUNCING AVAILABILITY OF A "CURRENT IETF DOCUMENTS" ARCHIVE: In preparing for an IETF meeting we noticed that people would like to have ready access to all documents that are being reviewed. At present, documents are placed in the internet-drafts archive or in the respective working group archive or just published in some mail-lists. There are just too many things to browse or read through. We feel that a special archive of "documents to be reviewed" will be very useful. It will especially help new participants come on board quickly. The InterNIC Directory and Database Services will continue to support a "current-ietf-docs" archive to enable people to get all documents - that are relevant for the current IETF meeting - from one place. This document database will be removed one month before the next IETF meeting to make room for new material. The completeness of this archive depends on the authors and working-group chair submitting the documents. We request each working-group chair to PLEASE submit the AGENDA to this archive. STRUCTURE OF THE ARCHIVE: On "ds.internic.net" documents will be stored under the appropriate working-group name under the appropriate area name in the directory "/pub/current-ietf-docs". Each area will also have a directory called "bof" where a document to be discussed in a BOF meeting will be placed. At the area level a directory called "plenary" will be created to put documents or VGs related to a plenary session. Any filename conflicts will be resolved by our administrator and the submitter will be informed via electronic mail. example: /pub/current-ietf-docs/app/osids /pub/current-ietf-docs/int/sip ACCESS VIA ANONYMOUS FTP: Anonymous FTP to ds.internic.net and change directory to /pub/current-ietf-docs/ and browse and get the document of interest. ACCESS VIA GOPHER: Connect to "gopher.internic.net" and select the menu item 4. InterNIC Directory and Database Services (AT&T)/ and then the menu item: 6. Internet Documentation (RFC's, FYI's, etc.)/ and then the menu item: 1. Current IETF Conference Documents (Houston - November 1993)/ One may use our public-access gopher client by telnet gopher.internic.net and logging in as gopher SUBMISSION OF DOCUMENTS Via Anonymous FTP: FTP to ds.internic.net and login as anonymous. Change directory to "/incoming/current-ietf-docs Put the document using the following filename convention, .. e.g.: plenary.mondayVGs.ps app.osids.agenda app.osids.schemawg-talk-VGs.ps SUBMISSION OF DOCUMENTS Via Electronic Mail: Send mail to "admin@ds.internic.net" with the following subject line: IETF - .. e.g.: IETF - app.osids.agenda Instead of sending a fresh copy of an already available document, you may ask our administrators to create a link to an existing internet-draft/RFC/ID NOTE: If you do not remember your area or working-group acronym get the file "/ietf/1wg-summary.txt" from "ds.internic.net" via anonymous FTP. COMMENTS: If you would like to see other goodies in this space please drop a note to admin@ds.internic.net. We will try to put the respective working group charters. ------------------------------------------------------------------------ InterNIC Directory and Database Services Administrator email: admin@ds.internic.net phone: 1-800-862-0677 1-908-668-6587 ------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15823; 27 Oct 93 15:55 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15819; 27 Oct 93 15:55 EDT Received: from [128.96.41.1] by CNRI.Reston.VA.US id aa21516; 27 Oct 93 15:55 EDT Received: from jeff.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Wed, 27 Oct 93 15:55:42 EDT Received: from localhost.bellcore.com by jeff.bellcore.com (4.1/4.7) id for if-mib@thumper.bellcore.com; Wed, 27 Oct 93 15:55:39 EDT Message-Id: <9310271955.AA04137@jeff.bellcore.com> To: if-mib@thumper.bellcore.com Cc: tob@thumper.bellcore.com Subject: Agenda of the Interface Mib working Group - Houston Date: Wed, 27 Oct 93 15:55:38 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: tob@jeff.bellcore.com There are two meetings (tuesday and wednesday) of the interfaces working group in Houston. Ted Brunner Bellcore tob@thumper.bellcore.com MRE 2P-252 201/829-4678 445 South St. Morristown NJ 07960-1910 Agenda of the Interface Mib working Group - Houston Tuesday 1330 meeting 1) Discussion of the IF Evolution Draft draft-ietf-ifmib-evolution-04.txt dated October 20 1993. We will have had a copy of this draft in the Drafts repositories for two weeks by the time we get to Houston. All of the changes agreed to on the mailing list (at this time) have been incorporated in this draft. If there are any issues left outstanding by this draft they will be discussed there. If any party wants to pursue them, this will be the occasion. It is my hope that we will be able to conclude discussion before the end of this meeting. Procedurally the next step is to recommend this MIB to the Area Director for promotion to Proposed Standard. Next stop IESG. If we conclude before our alloted time, the next days agenda items can slide forward. Wednesday 1330 meeting 1) Discussion of the Generic Connection Table Draft draft-ietf-ifmib-conntable-00.txt dated October 8 1993 This is a topic left on the table from Amsterdam, where it received consideration in the ATM and FR, but not the interfaces working groups. Since it is meant to be a generic table, it falls into our laps. By this time the ATM and FR WGs will have indicated support or not for a generic connection table. By this time, the ATM and FR WGs will have decided on a structure for their media-specific connection tables. A short presentation will be made, and the working group can consider supporting and consider the structure of such a table. 2) Discussion of the progression of RFCs 1231, 1304, 1398. Preliminary discussions to outline the issues involved in moving these MIBs forward with the new interfaces paradigm. As for timing/scheduling with other related working groups, Schedule of selected wg meetings: Mon 1330 ATM Tues 1330 ifmib Tues 1600 FR Weds 1330 ifmib Weds 1600 FR Thurs 1330 ATM - ------- End of Forwarded Message ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02790; 28 Oct 93 8:12 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02786; 28 Oct 93 8:12 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa07226; 28 Oct 93 8:12 EDT Received: from relay2.pipex.net by thumper.bellcore.com (4.1/4.7) id for ietf-archive@cnri.reston.va.us; Thu, 28 Oct 93 08:12:22 EDT Received: from pipex.net by relay2.pipex.net with SMTP (PP) id <01813-0@relay2.pipex.net>; Thu, 28 Oct 1993 12:12:15 +0000 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <13470-0@relay1.pipex.net>; Thu, 28 Oct 1993 12:12:07 +0000 Received: by widow.spider.co.uk; Thu, 28 Oct 93 13:18:53 +0100 Received: by lynx.spider.co.uk.spider.co.uk (4.1/SMI-4.1) id AA27084; Thu, 28 Oct 93 12:11:59 GMT Date: Thu, 28 Oct 93 12:11:59 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Richard Bradley Message-Id: <9310281211.AA27084@lynx.spider.co.uk.spider.co.uk> X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: if-mib@thumper.bellcore.com Subject: Unsubscribe please Requesting unsubscribe from if-mib-request doesn't seem to work. Please will someone remove me from this list? Thanks, Richard. -- Richard M. Bradley Network Manager Spider Systems Limited (Tel: +44 31-554 9424)