From owner-frnetmib@sunroof.eng.sun.com Mon May 1 05:23:56 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22730; Mon, 1 May 2000 05:23:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08225; Mon, 1 May 2000 03:23:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA09265; Mon, 1 May 2000 02:22:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e419MYq15023 for frnetmib-dist; Mon, 1 May 2000 02:22:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e419MS715016 for ; Mon, 1 May 2000 02:22:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA10199 for ; Mon, 1 May 2000 02:22:26 -0700 (PDT) Received: from radmail.rad.co.il (radmail.rad.co.il [207.232.32.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21797 for ; Mon, 1 May 2000 02:22:25 -0700 (PDT) Received: from leonid ([192.114.29.98]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-54115U1200L1200S0V35) with SMTP id il for ; Mon, 1 May 2000 11:24:41 +0200 Reply-To: From: "Leonid Mashinsky" To: Subject: (FRNETMIB) IP over Frame Relay Date: Mon, 1 May 2000 12:24:04 +0200 Message-ID: <000001bfb357$60ea07a0$621d72c0@rad.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ Content-Transfer-Encoding: 7bit Hello, I've some question about IP over Frame Relay Virtual Circuit. RFC doesn't recommend to assign an entry in the ifTable to each VC. On the other hand, ipMIB (ipAddrTable) relates an IP address to ifIndex. I use the Frame Relay DTE MIB (RFC2115) for FR VC. How can I create an IP interface that associated with VC and use ipAddrTable and ipNetToMediaTable for it? Thanks, Leonid Mashinsky, IPrad, leonid@iprad.co.il X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Mon May 1 08:53:58 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25656; Mon, 1 May 2000 08:53:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25651; Mon, 1 May 2000 06:53:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA20947; Mon, 1 May 2000 05:52:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e41CqgD15069 for frnetmib-dist; Mon, 1 May 2000 05:52:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e41Cqb715062 for ; Mon, 1 May 2000 05:52:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA29843 for ; Mon, 1 May 2000 05:52:37 -0700 (PDT) Received: from satori.is.paradyne.com (services.paradyne.com [135.90.253.90]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02655 for ; Mon, 1 May 2000 05:52:36 -0700 (PDT) Received: from hermes.eng.paradyne.com ([135.26.1.14]) by satori.is.paradyne.com (Netscape Messaging Server 3.6) with ESMTP id AAAB45; Mon, 1 May 2000 08:54:30 -0400 Received: from eng.paradyne.com (graysnapper.eng.paradyne.com [135.26.4.16]) by hermes.eng.paradyne.com (8.7.5/8.7.3) with ESMTP id IAA10932; Mon, 1 May 2000 08:52:12 -0400 (EDT) Message-ID: <390D7E52.108DF206@eng.paradyne.com> Date: Mon, 01 May 2000 08:53:38 -0400 From: Rob Steinberger Organization: Paradyne Corporation X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: leonid@iprad.co.il CC: frnetmib@sunroof.eng.sun.com Subject: Re: (FRNETMIB) IP over Frame Relay References: <000001bfb357$60ea07a0$621d72c0@rad.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ Content-Transfer-Encoding: 7bit Leonid, The ifTable VC problem is going to be addressed in the context of RMON monitoring in a draft that is to be published shortly. Rob. Leonid Mashinsky wrote: > Hello, > > I've some question about IP over Frame Relay Virtual Circuit. > > RFC doesn't recommend to assign an entry in the ifTable to each VC. > On the other hand, ipMIB (ipAddrTable) relates an IP address to ifIndex. > > I use the Frame Relay DTE MIB (RFC2115) for FR VC. > How can I create an IP interface that associated with VC and use ipAddrTable > and ipNetToMediaTable for it? > > Thanks, > Leonid Mashinsky, IPrad, > leonid@iprad.co.il > > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe frnetmib' in the body of the message. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:13 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08317; Tue, 2 May 2000 16:29:12 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05507; Tue, 2 May 2000 14:28:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01662; Tue, 2 May 2000 13:27:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KRaK16847 for frnetmib-dist; Tue, 2 May 2000 13:27:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRO716826 for ; Tue, 2 May 2000 13:27:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12731 for ; Tue, 2 May 2000 13:27:23 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA11808 for ; Tue, 2 May 2000 13:27:21 -0700 (PDT) Received: from shemp by mail.visualnetworks.com via smtpd (for venus.Sun.COM [192.9.25.5]) with SMTP; 2 May 2000 20:32:49 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:21 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB1@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 3 - Table Fragmentation Date: Tue, 2 May 2000 16:27:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 3) Having separate data and availability history tables does not > > make sense. > > A single table is used for free running counters that populate the > > two > > separate tables. Likewise, make the MIB simpler by having a single > > sample > > table that includes both data and availability. Do users really > > have a need > > to do independent history collections of availability and DDR? Would > > > > someone, for example, want fifty samples at 15 minute intervals for > > availability but want only 25 samples for DDR? > > The data and availability were both in one table in the pre-draft > state of this MIB. However, it was requested at that time that they > be separated. The extra table allows more flexibility without adding > much complication, so I did not disagree with the request. I can see > users wanting day samples of Availability and fifteen minute samples > of the other statistics. If they need to have different sampling characteristics then they can add a new row to the frsldSmplCtrlTable. They don't need to be in two different tables. When all is said and done, frsldPvcAvailSampleTable exists to support a grand total two objects: unavailable time and unavailable count. For simplicity without loss of function, collapse into a general sample table. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:15 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08330; Tue, 2 May 2000 16:29:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05424; Tue, 2 May 2000 14:28:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17382; Tue, 2 May 2000 13:27:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KRH916816 for frnetmib-dist; Tue, 2 May 2000 13:27:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRA716809 for ; Tue, 2 May 2000 13:27:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12599 for ; Tue, 2 May 2000 13:27:08 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA04675 for ; Tue, 2 May 2000 14:27:07 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:32:35 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:02 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BAF@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 1 - Implementation specific config variables Date: Tue, 2 May 2000 16:27:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 1) Section 2.5 states that this document does not suggest or > > recommend a > > particular implementation. The frsldPvcCtrlTable contains several > > configuration variables that certainly seem to imply specific > > implementations. These configuration objects should be removed or > > the > > implementation details should be described. For example: > > > > frsldPvcCtrlPacketFreq > > frsldPvcCtrlDelayLoc > > frsldPvcCtrlDelayFrSize > > frsldPvcCtrlDelayType > > frsldPvcCtrlDelayTimeOut > > > > The delay objects you mention > > frsldPvcCtrlPacketFreq - Frequency of delay packet - if > supported > frsldPvcCtrlDelayLoc - Location of delay calculation > frsldPvcCtrlDelayFrSize - Size of delay packet - if supported > frsldPvcCtrlDelayType - One way or Round Trip Delay > frsldPvcCtrlDelayTimeOut - Time out for delay response - if > supported > > are put in for the purpose of controlling delay measurement. They are > not specific to an implementation nor do they force the user to do > delay measurement in a specific manner. Delay is a definition as > stated in FRF.13, and there needs to be some means of controlling and > describing how this is measured. Both control and description are > important and are part of the basis of the MIB. The location and type > are important to adding meaning to how delay is measured, but I will > address this in a reply to your comment 8. > > Perhaps, we should move some of these variables into a separate groups > in the compliance section to allow them to be skipped easier. > > In your comment, you gave this list as a "for example." This suggests > that this is only a sampling of the objects you have problems with. > We cannot fully address your issues until your issue list is complete. I believe a generic SLA MIB (of which this MIB is variation) should focus on tracking the results of the SLA - not control of the mechanism which obtained those results. In the case of delay, frame size and test frequency may be elements of an SLA - but these are not elements that vary over time and thus should not be included in this MIB. A different MIB should exist to drive delay measurements. I anticipate a future FRF.OAM MIB that will instrument such tests. None of the objects above are valid for this MIB. They need to be removed. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:34 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08343; Tue, 2 May 2000 16:29:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05427; Tue, 2 May 2000 14:28:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17461; Tue, 2 May 2000 13:27:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KRUq16837 for frnetmib-dist; Tue, 2 May 2000 13:27:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRK716818 for ; Tue, 2 May 2000 13:27:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA15969 for ; Tue, 2 May 2000 13:27:19 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA11757 for ; Tue, 2 May 2000 13:27:17 -0700 (PDT) Received: from shemp by mail.visualnetworks.com via smtpd (for venus.Sun.COM [192.9.25.5]) with SMTP; 2 May 2000 20:32:45 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:17 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB0@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 2 - Free the Freerunning Counts! Date: Tue, 2 May 2000 16:27:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 2) The frsldPvcDataTable is a table of free-running counters. This > > means > > that the time period for the min, max, and average variables in the > > frsldPvcDataTable would be infinite, making these values > > meaningless. > > What's the point? > > The min, max and avg values in the data table were discussed in > Washington. I pointed the same thing out there, and this correction > was acceptable at the time. From the meeting minutes: > > Rob pointed out an error in the document on > frsldPvcDataDelayMin/Max/Avg. The reference is to the > free-running table and this should have relevance only to the > free running world. This will be corrected. > > Further, I showed this change again in Adelaide. We can either alter > the text to state how the object decay should be handled or add a > variable to show the life span of the value. This would bring up > implementation issues as to whether to use a sliding window or a > polled window. I don't feel comfortable removing the values in that > they are needed if the implementation chooses not to do any sampling. > What would you prefer? If Min/Max/Avg don't make sense in a table of free running counts then they should be removed. Don't add complexity by adding concepts such as object decay or life span. Eliminate the objects. If an implementation chooses not to do any sampling then the implementation can live with the choice. It is simple enough to use frsldSmplCtrlTable to structure a longish period of time which will be able to snag the Min/Max/Avg. Don't overload the free running counts to do this. Staring at this makes me wonder - why do we even need free running counters? This MIB should be restricted to the historical record as delimited by the interval boundaries. The MIB seems to be both a source of raw material for some manager that then "cooks" the data for reporting AND a source of "cooked" data for a manager to report. Pick one approach and stick with it! I recommend the "cooked" data approach as found in the sample tables. How these tables get created is an implementation specific issue. In conclusion, remove the table free running counters. Focus the MIB on reporting SLA results - not the mechanism for building the results. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:37 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08356; Tue, 2 May 2000 16:29:37 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05737; Tue, 2 May 2000 14:28:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01720; Tue, 2 May 2000 13:28:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KRob16878 for frnetmib-dist; Tue, 2 May 2000 13:27:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRX716844 for ; Tue, 2 May 2000 13:27:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01569 for ; Tue, 2 May 2000 13:27:31 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA04989 for ; Tue, 2 May 2000 14:27:29 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:32:57 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:29 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB2@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 4 - Bidirectional flow tracking and abandonmen t of the FR DTE MIB Date: Tue, 2 May 2000 16:27:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 4) Provide index mechanisms to support the modeling of a circuit as > > two > > half-duplex flows so that delivery success can be reported for the > > east-to-west direction as well as the west-to-east direction. > > This MIB is described as working with two devices to get the > information. The mechanism you describe is implementation specific > and requires that a single device can be used to get the statistics > for both ends of the PVC. However, if implementations exist that > currently do this, it should be covered. This issue is handled in my > solution to question 12. If we let the user index on reference points > as well, we can add both directions of data by selecting the > appropriate reference point. I don't think that solves the problem. The TC for FrsldRP is: srcRP(1), -- Source Reference Point ingRP(2), -- Ingress Reference Point tpRP(3), -- Traffic Policing Reference Point eqiRP(4), -- Egress Queue Input Reference Point eqoRP(5), -- Egress Queue Output Reference Point desRP(6), -- Destination Reference Point frsldPvcCtrlSrcRp would get set to srcRP, ingRP, or tpRP. frsldPvcCtrlDesRp would get set to eqiRP, eqoRP, or desRP. Simply indexing off these objects is insufficent. You would need a new object to represent flow direction. A far better approach would be to restrict this MIB to an environment that supports the FR Service MIB. Use the cross connect table of the FRS MIB to uniquely distinguish the bi-directional flows. Then, create a low-to-high flow sample table that is indexed by the cross connect index and represents service delivery for frames flowing from the low ifIndex to the high ifIndex. Create a high-to-low flow sample table also indexed by the cross connect index and represents service delivery for frames flowing from the high ifIndex to the low ifIndex. This also solves the problem with NNIs, because each segment of the DLCI will be found in a different cross-connect table. Elimination of support for the FR DTE MIB also makes sense when you look at what the purpose of the SLA MIB is: customer network management, the purpose behind the FR Service MIB! X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:48 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08369; Tue, 2 May 2000 16:29:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05864; Tue, 2 May 2000 14:28:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01809; Tue, 2 May 2000 13:28:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KRw616895 for frnetmib-dist; Tue, 2 May 2000 13:27:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRe716859 for ; Tue, 2 May 2000 13:27:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17434 for ; Tue, 2 May 2000 13:27:38 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA05088 for ; Tue, 2 May 2000 14:27:37 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:33:03 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:35 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB3@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 5 - Theory of Operations Date: Tue, 2 May 2000 16:27:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 5) Add a "theory of operations" section to the introductory sections > > so that > > the reader can understand how to setup, tear down, and read the > > service > > sample sessions. The theory should describe the operation for each > > of the > > permutations of data collection ("cooked" and "raw" - my terms, the > > current > > text uses an odd set of collection nomenclature). > > This section is a good idea, but it comes at the risk of being too > implementation specific. It will need to carry the warnings and > appropriate nomenclature (SHOULD, MAY, etc.). This is not implementation specific. It is an manual to guide developers in their utilization of the MIB. What does a NM system do to setup, tear down, and read the SLA session information. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:55 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08382; Tue, 2 May 2000 16:29:54 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05917; Tue, 2 May 2000 14:28:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01820; Tue, 2 May 2000 13:28:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KS1x16898 for frnetmib-dist; Tue, 2 May 2000 13:28:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRh716866 for ; Tue, 2 May 2000 13:27:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA16072 for ; Tue, 2 May 2000 13:27:42 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA05154 for ; Tue, 2 May 2000 14:27:40 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:33:08 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:40 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB4@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 6 - Collection Location Date: Tue, 2 May 2000 16:27:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 6) Why is the collection location distinction between > > source/destination/intermediate so important? How does the fact > > that the > > collection location is "source" versus "destination" versus > > "intermediate" > > change how the MIB is used or interpreted? The actions seem the > > same and > > each unit has to use implementation-specific mechanisms to pull > > together the > > data from the two endpoints. These should all be combined into a > > single > > value called "cooked" - because they all share the characteristic > > that all > > required data has been collected, correlated, and calculated. This > > is in > > contrast the "distributed" model where only information from one end > > is > > available. The distributed distinction should be divided into "raw > > source" > > and "raw destination". This provides the management system with > > clear > > indication that the data needs to be combined with another sample > > set. > > Section 2.6 describes the importance of the collection locations. In > that two devices are needed to get the information, the management > software needs to know where to go to get the appropriate data. The management software needs a lot more than the vague "location" information in the MIB today. The current attributes of location in the MIB are: source(1), -- Calculations occur at the -- source device. destination(2), -- Calculations occur at the -- destination device. intermediate(3), -- Calculations occur at some -- intermediate device such as -- a probe. distributed(4) -- Calculations are distributed -- between source and destination -- devices. What does the NM application do when the value is "destination"? Where does it go to get information? Not only is there insufficient information to be able to implement an NM application, but there is too much variety in how that information might be pulled together. Make this simple. Associate the SLA MIB with the FRS MIB (see my comment on Item 4) and you immediately have a definitive place for the management software to go. HOW the MIB is populated with data must be left as an implementation-specific issue. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:29:57 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08395; Tue, 2 May 2000 16:29:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05931; Tue, 2 May 2000 14:28:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA16313; Tue, 2 May 2000 13:28:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KS7b16908 for frnetmib-dist; Tue, 2 May 2000 13:28:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KRo716886 for ; Tue, 2 May 2000 13:27:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA16107 for ; Tue, 2 May 2000 13:27:48 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA12076 for ; Tue, 2 May 2000 13:27:47 -0700 (PDT) Received: from shemp by mail.visualnetworks.com via smtpd (for venus.Sun.COM [192.9.25.5]) with SMTP; 2 May 2000 20:33:15 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:47 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB5@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 7 - Distributed confusion Date: Tue, 2 May 2000 16:27:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 7) the second paragraph of Section 2.6, Distributed is confusing. > > What does > > it mean to act for separate source-destination pairs? What does this > > have to > > do with the concept of not having access to both source and > > destination sets > > of data? > > Data is sent from a source node to a destination node which form a > source-destination node pair. If the device collects data only about > itself as it acts as both a source and a destination, the data will > reflect this. The management software needs to know what the meaning > of the statistics is so that it can use them appropriately. My comments to Item 6 apply. Go to a simple model of reporting the resulting SLA information. Don't attempt to provide raw material to a wide variety of lower level data collection methods. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:30:07 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08427; Tue, 2 May 2000 16:30:06 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06327; Tue, 2 May 2000 14:29:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01944; Tue, 2 May 2000 13:28:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KSak16975 for frnetmib-dist; Tue, 2 May 2000 13:28:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KS9716918 for ; Tue, 2 May 2000 13:28:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12888 for ; Tue, 2 May 2000 13:28:08 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA12288 for ; Tue, 2 May 2000 13:28:07 -0700 (PDT) Received: from shemp by mail.visualnetworks.com via smtpd (for venus.Sun.COM [192.9.25.5]) with SMTP; 2 May 2000 20:33:34 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:28:06 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB8@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 10 - Comments Date: Tue, 2 May 2000 16:28:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 10) Make sure all comments are moved into object DESCRIPTION text. > > Especially for enumerations. > > Comments will be fixed. Great. I will assume this issue is closed. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:30:19 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08440; Tue, 2 May 2000 16:30:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06471; Tue, 2 May 2000 14:29:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17764; Tue, 2 May 2000 13:29:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KSdi16976 for frnetmib-dist; Tue, 2 May 2000 13:28:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KSE716931 for ; Tue, 2 May 2000 13:28:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01753 for ; Tue, 2 May 2000 13:28:12 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA12337 for ; Tue, 2 May 2000 13:28:11 -0700 (PDT) Received: from shemp by mail.visualnetworks.com via smtpd (for venus.Sun.COM [192.9.25.5]) with SMTP; 2 May 2000 20:33:38 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:28:10 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB9@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 11 - Octet delivery precision Date: Tue, 2 May 2000 16:28:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 11) The frssldPvcDataOffered objects will wrap too quickly for high > > speed > > frame relay interfaces. Use a high-capacity count. > > The same thing can be said about all current Frame Relay MIBs. Do we > fix all of them now, let them all work the same, or just fix this one? Actually, this is more of a problem with the FR SLA MIB because of the tracking of octet delivery and loss in the context of a legal contract. If octet loss is built into an SLA as a contractual commitment, then a precise of loss accounting is required. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:30:37 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08453; Tue, 2 May 2000 16:30:36 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06751; Tue, 2 May 2000 14:29:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA02051; Tue, 2 May 2000 13:29:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KSkV16982 for frnetmib-dist; Tue, 2 May 2000 13:28:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KSO716958 for ; Tue, 2 May 2000 13:28:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA16255 for ; Tue, 2 May 2000 13:28:22 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA05665 for ; Tue, 2 May 2000 14:28:21 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:33:45 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:28:17 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BBA@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 12 - Multiple reference points w/ NNI Date: Tue, 2 May 2000 16:28:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 12) The indexing of the CtrlTable and the frsldPvcCtrlSrcRP and > > frsldPvcCtrlDstRP objects would imply that a single device cannot do > > > > measurements between multiple reference points for the same PVC. For > > > > example, you couldn't measure end to end and end to NNI. Is this > > true? > > Good point. I can add the reference points as indices and this will > be fixed along with the comment as well as issue 4. I don't think more indices solve the problem. Refer to my comments on issue 4. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:30:43 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08470; Tue, 2 May 2000 16:30:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06535; Tue, 2 May 2000 14:29:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17788; Tue, 2 May 2000 13:29:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KSgF16979 for frnetmib-dist; Tue, 2 May 2000 13:28:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KSB716923 for ; Tue, 2 May 2000 13:28:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01726 for ; Tue, 2 May 2000 13:28:09 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA05512 for ; Tue, 2 May 2000 14:28:09 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:33:37 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:28:02 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB7@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 9 - Explici descriptions of operation Date: Tue, 2 May 2000 16:28:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 9) Explicitly describe how an agent should respond if access is > > attempted to > > an object that is not supported by the particular implementation. > > No Such Name Great. This is actually a duplicate (subset) of my Issue 5. I withdraw the issue. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 2 16:31:47 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08560; Tue, 2 May 2000 16:31:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06280; Tue, 2 May 2000 14:29:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17682; Tue, 2 May 2000 13:28:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e42KSTZ16965 for frnetmib-dist; Tue, 2 May 2000 13:28:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e42KS1716901 for ; Tue, 2 May 2000 13:28:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01715 for ; Tue, 2 May 2000 13:27:59 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA05370 for ; Tue, 2 May 2000 14:27:58 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 2 May 2000 20:33:26 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 May 2000 16:27:55 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A019E8BB6@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: frnetmib@sunroof.eng.sun.com Subject: (FRNETMIB) FR SLA MIB - Issue 8 - Different collection locations for single CtrlTable row Date: Tue, 2 May 2000 16:27:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ > > 8) Different collection location types are allowed for delay > > measurement and > > delivery measurement on the SAME sample - why? This just adds more > > complexity. > > Delay and data calculations can be calculated with different > mechanisms. Forcing only one location limits the ability to capture > all existing low level implementations. I know of implementations > that can separate the collection locations. Restricting this would > mean forcing an implementation on existing vendors, violate a goal of > the document, and reduce the general use of the MIB. We have got to come up from the low level implementation. Each SLM implementation will have different approaches towards collecting this information. What we need from this MIB is a way to communicate the resulting service level. I would expect that a future FRF.OAM MIB would carefully spell out how the FR SLA MIB would be supported by that particular interface. Restrict the reporting to the observed delay and loss. It is not possible to "configure" location nor is it important to the reporting of the SLA information as location is a static component of the SLA legal agreement. Hardly an object that needs to be captured in a MIB to control the NM application or a device. Now if you had said that there should be a policy schema for FR SLA that would include a description of the measurement location, then I would be in agreement! X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Wed May 3 13:11:31 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06676; Wed, 3 May 2000 13:11:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23283; Wed, 3 May 2000 11:07:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04901; Wed, 3 May 2000 10:05:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e43H4eY18945 for frnetmib-dist; Wed, 3 May 2000 10:04:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e43H4X718938 for ; Wed, 3 May 2000 10:04:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04647 for ; Wed, 3 May 2000 10:04:31 -0700 (PDT) Received: from kayla.dl.com (kayla.dl.com [204.31.125.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14561 for ; Wed, 3 May 2000 10:04:28 -0700 (PDT) Received: from Athena.dl.com (ns100dmz [204.31.125.1]) by kayla.dl.com (8.9.1/8.9.1) with SMTP id KAA02633 for ; Wed, 3 May 2000 10:06:16 -0700 (PDT) Received: by Athena.dl.com(Lotus SMTP MTA v1.2 (600.1 3-26-1998)) id 882568D4.005DC583 ; Wed, 3 May 2000 10:04:14 -0700 X-Lotus-FromDomain: DLNOTES From: "Santa Dasu" To: frnetmib@sunroof.eng.sun.com Message-ID: <882568D4.005B69D2.00@Athena.dl.com> Date: Wed, 3 May 2000 10:04:10 -0700 Subject: Re: (FRNETMIB) FR SLA MIB - Issue 1 - Implementation specific config variables Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ " I believe a generic SLA MIB (of which this MIB is variation) should focus on tracking the results of the SLA - not control of the mechanism which obtained those results. In the case of delay, frame size and test frequency may be elements of an SLA - but these are not elements that vary over time and thus should not be included in this MIB. A different MIB should exist to drive delay measurements. I anticipate a future FRF.OAM MIB that will instrument such tests. None of the objects above are valid for this MIB. They need to be removed. " I do not agree with this. It is not necessary to restrict this mib only to collected statistics. Even if some configuration info does not change with time, it must remain in the MIB. "Rehbehn, Kenneth" on 05/02/2000 01:27:00 PM To: frnetmib@sunroof.eng.sun.com cc: (bcc: Santa Dasu/DLNOTES/US) Subject: (FRNETMIB) FR SLA MIB - Issue 1 - Implementation specific config variables > > 1) Section 2.5 states that this document does not suggest or > > recommend a > > particular implementation. The frsldPvcCtrlTable contains several > > configuration variables that certainly seem to imply specific > > implementations. These configuration objects should be removed or > > the > > implementation details should be described. For example: > > > > frsldPvcCtrlPacketFreq > > frsldPvcCtrlDelayLoc > > frsldPvcCtrlDelayFrSize > > frsldPvcCtrlDelayType > > frsldPvcCtrlDelayTimeOut > > > > The delay objects you mention > > frsldPvcCtrlPacketFreq - Frequency of delay packet - if > supported > frsldPvcCtrlDelayLoc - Location of delay calculation > frsldPvcCtrlDelayFrSize - Size of delay packet - if supported > frsldPvcCtrlDelayType - One way or Round Trip Delay > frsldPvcCtrlDelayTimeOut - Time out for delay response - if > supported > > are put in for the purpose of controlling delay measurement. They are > not specific to an implementation nor do they force the user to do > delay measurement in a specific manner. Delay is a definition as > stated in FRF.13, and there needs to be some means of controlling and > describing how this is measured. Both control and description are > important and are part of the basis of the MIB. The location and type > are important to adding meaning to how delay is measured, but I will > address this in a reply to your comment 8. > > Perhaps, we should move some of these variables into a separate groups > in the compliance section to allow them to be skipped easier. > > In your comment, you gave this list as a "for example." This suggests > that this is only a sampling of the objects you have problems with. > We cannot fully address your issues until your issue list is complete. I believe a generic SLA MIB (of which this MIB is variation) should focus on tracking the results of the SLA - not control of the mechanism which obtained those results. In the case of delay, frame size and test frequency may be elements of an SLA - but these are not elements that vary over time and thus should not be included in this MIB. A different MIB should exist to drive delay measurements. I anticipate a future FRF.OAM MIB that will instrument such tests. None of the objects above are valid for this MIB. They need to be removed. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Wed May 3 17:18:37 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11482; Wed, 3 May 2000 17:18:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01899; Wed, 3 May 2000 15:14:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA07875; Wed, 3 May 2000 14:13:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e43LCvQ19250 for frnetmib-dist; Wed, 3 May 2000 14:12:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e43LCn719243 for ; Wed, 3 May 2000 14:12:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA09468 for ; Wed, 3 May 2000 14:12:46 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27199 for ; Wed, 3 May 2000 14:12:45 -0700 (PDT) Received: from malisa2.lucent.com ([152.148.90.98]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id RAA24572; Wed, 3 May 2000 17:12:44 -0400 (EDT) Message-Id: <4.3.1.2.20000503171102.02a91240@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 May 2000 17:12:41 -0400 To: frnetmib@sunroof.eng.sun.com From: "Andrew G. Malis" Subject: (FRNETMIB) Begin of WG last call for draft-ietf-frnetmib-mfrmib-02.txt Cc: amalis@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ This begins working group last call on draft-ietf-frnetmib-mfrmib-02.txt, to end in two weeks on 5/17/00. As always, comments to the list. Thanks, Andy ________________________________________________________________________ Andrew G. Malis amalis@lucent.com phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins Road Westford, MA 01886 X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Thu May 11 12:22:54 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01868; Thu, 11 May 2000 12:22:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08955; Thu, 11 May 2000 10:21:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05460; Thu, 11 May 2000 09:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4BGJ7a28840 for frnetmib-dist; Thu, 11 May 2000 09:19:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4BGJ0728833 for ; Thu, 11 May 2000 09:19:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05156 for ; Thu, 11 May 2000 09:18:57 -0700 (PDT) Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19684 for ; Thu, 11 May 2000 09:18:57 -0700 (PDT) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA21796 for ; Thu, 11 May 2000 12:18:56 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA21792 for ; Thu, 11 May 2000 12:18:55 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id ; Thu, 11 May 2000 18:18:54 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB072F8E78@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: frnetmib@sunroof.eng.sun.com Subject: RE: (FRNETMIB) FR SLA MIB - Issue 2 - Free the Freerunning Counts ! Date: Thu, 11 May 2000 16:53:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ For cookbook type statistics, you may want to take a look at RFC2493, which defines TC for 15 minute interval statistics Bert > ---------- > From: Rehbehn, Kenneth[SMTP:Krehbehn@VisualNetworks.com] > Sent: Tuesday, May 02, 2000 10:27 PM > To: frnetmib@sunroof.eng.sun.com > Subject: (FRNETMIB) FR SLA MIB - Issue 2 - Free the Freerunning > Counts! > > > > 2) The frsldPvcDataTable is a table of free-running counters. This > > > means > > > that the time period for the min, max, and average variables in the > > > frsldPvcDataTable would be infinite, making these values > > > meaningless. > > > What's the point? > > > > The min, max and avg values in the data table were discussed in > > Washington. I pointed the same thing out there, and this correction > > was acceptable at the time. From the meeting minutes: > > > > Rob pointed out an error in the document on > > frsldPvcDataDelayMin/Max/Avg. The reference is to the > > free-running table and this should have relevance only to the > > free running world. This will be corrected. > > > > Further, I showed this change again in Adelaide. We can either alter > > the text to state how the object decay should be handled or add a > > variable to show the life span of the value. This would bring up > > implementation issues as to whether to use a sliding window or a > > polled window. I don't feel comfortable removing the values in that > > they are needed if the implementation chooses not to do any sampling. > > What would you prefer? > > > If Min/Max/Avg don't make sense in a table of free running counts then > they > should be removed. Don't add complexity by adding concepts such as object > decay or life span. Eliminate the objects. > > If an implementation chooses not to do any sampling then the > implementation > can live with the choice. It is simple enough to use frsldSmplCtrlTable > to > structure a longish period of time which will be able to snag the > Min/Max/Avg. Don't overload the free running counts to do this. > > Staring at this makes me wonder - why do we even need free running > counters? > This MIB should be restricted to the historical record as delimited by the > interval boundaries. The MIB seems to be both a source of raw material > for > some manager that then "cooks" the data for reporting AND a source of > "cooked" data for a manager to report. Pick one approach and stick with > it! > I recommend the "cooked" data approach as found in the sample tables. How > these tables get created is an implementation specific issue. > > In conclusion, remove the table free running counters. > > Focus the MIB on reporting SLA results - not the mechanism for building > the > results. > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe frnetmib' in the body of the message. > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Thu May 11 12:38:10 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02302; Thu, 11 May 2000 12:38:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20836; Thu, 11 May 2000 10:36:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA08298; Thu, 11 May 2000 09:34:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4BGXOP28859 for frnetmib-dist; Thu, 11 May 2000 09:33:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4BGXG728852 for ; Thu, 11 May 2000 09:33:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13589 for ; Thu, 11 May 2000 09:33:14 -0700 (PDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29499 for ; Thu, 11 May 2000 09:33:13 -0700 (PDT) Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA22347 for ; Thu, 11 May 2000 12:33:11 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA22341 for ; Thu, 11 May 2000 12:33:10 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0) id ; Thu, 11 May 2000 18:33:09 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB072F8E89@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: frnetmib@sunroof.eng.sun.com, Rob Steinberger Cc: Orly Nicklass Subject: (FRNETMIB) draft-ietf-frnetmib-frmrelay-service-00.txt Date: Thu, 11 May 2000 17:00:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ I happened to be browsing this MIB. - Please do NOT import BITS (see RFC2578) - Pls use 4-digit years in LAST-UPDATED and REVISION Clauses from now on. I suggest to also use 4-digit yeras for 19xx years. Bert X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Mon May 22 08:45:35 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01266; Mon, 22 May 2000 08:45:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22329; Mon, 22 May 2000 06:44:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA17934; Mon, 22 May 2000 05:42:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4MCelP07859 for frnetmib-dist; Mon, 22 May 2000 05:40:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4MCeb707852 for ; Mon, 22 May 2000 05:40:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA17780; Mon, 22 May 2000 05:40:06 -0700 (PDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20325; Mon, 22 May 2000 06:40:04 -0600 (MDT) Received: from amalis.lucent.com ([152.148.173.63]) by alpo.casc.com (8.9.1a/8.9.1) with ESMTP id IAA24907; Mon, 22 May 2000 08:39:25 -0400 (EDT) Message-Id: <4.3.1.2.20000522083601.01cbc710@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 22 May 2000 08:38:46 -0400 To: frnetmib@sunroof.eng.sun.com, "Thomas Narten" , Erik Nordmark From: "Andrew G. Malis" Subject: (FRNETMIB) End of WG last call for draft-ietf-frnetmib-mfrmib-02.txt Cc: amalis@lucent.com, "Wijnen, Bert (Bert)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ This ends the working group last call on draft-ietf-frnetmib-mfrmib-02.txt (with a few extra days so I couldn't be accused of jumping the gun :-). No comments were received during the last call period, and it is being forwarded to the IESG to be published as a Proposed Standard RFC. Note that this MIB has also been reviewed by the Frame Relay Forum. Thanks, Andy ________________________________________________________________________ Andrew G. Malis amalis@lucent.com phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins Road Westford, MA 01886 X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message. From owner-frnetmib@sunroof.eng.sun.com Tue May 23 16:44:45 2000 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09372; Tue, 23 May 2000 16:44:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26883; Tue, 23 May 2000 14:43:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18459; Tue, 23 May 2000 13:42:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4NKg4s08942 for frnetmib-dist; Tue, 23 May 2000 13:42:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4NKfw708935 for ; Tue, 23 May 2000 13:41:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA21738 for ; Tue, 23 May 2000 13:41:56 -0700 (PDT) Received: from mail.visualnetworks.com ([208.22.72.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA25643 for ; Tue, 23 May 2000 14:41:56 -0600 (MDT) Received: from shemp by mail.visualnetworks.com via smtpd (for lukla.Sun.COM [192.18.98.31]) with SMTP; 23 May 2000 20:47:55 UT Received: by shemp.visualnetworks.com with Internet Mail Service (5.5.2448.0) id ; Tue, 23 May 2000 16:41:54 -0400 Message-ID: <0F9AE864A5ECD011B3100060977F354A029D8F2C@shemp.visualnetworks.com> From: "Rehbehn, Kenneth" To: "'Rob Steinberger'" , frnetmib@sunroof.eng.sun.com Subject: RE: (FRNETMIB) FR/ATM Interworking MIB Comments Date: Tue, 23 May 2000 16:41:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-frnetmib@sunroof.eng.sun.com Precedence: bulk X-Info: [Un]Subscribe to majordomo@sunroof.eng.sun.com X-Info: Submissions to frnetmib@sunroof.eng.sun.com X-Info: Email archive at ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/ I have been on the road and am only now getting to digesting your suggestions. I will update the MIB as reflected by my comments below and as a result of any further discussion on the mail list. Ken > -----Original Message----- > From: Rob Steinberger [mailto:ras@eng.paradyne.com] > Sent: Thursday, April 27, 2000 11:46 AM > To: frnetmib@sunroof.eng.sun.com > Subject: (FRNETMIB) FR/ATM Interworking MIB Comments > > > Developers here pointed out that frAtmIwfConnectionTable indexing is > confusing. There are 6 indices to the table, but based on the > description only one appears to be needed. The wording for > frAtmIwfConnIndex is: > > "A unique index to identify this interworking connection" > I will expand the description so it is more reality based. As you noted, the current text is really inadequate. > I realize that it is there to provide the point-to-multipoint > connectivity, but you need to read section 3.4 to get that information > out. Our developers were viewing each row in the table as an > individual connection in that they display a single cross-connect. > This problem may be alleviated with a modification to the > DESCRIPTION clause. We need to tell the user that this connection > index is a group of associated cross connections. We may also have to > define better what makes a valid group. > This information will go in the description. > However, there is nothing in either the indexing scheme or the text to > enforce that a "connection" is either point-to-point or > point-to-multipoint. In fact, the connection index can simply be an > index of a group of simple connections. All that is stated is that > the MUST use the same connection description. It appears to be legal > with this scheme to have every connection in the device use the exact > same connection index as long as there is only one connection > description used. This is not useful. The 2nd paragraph of the DESCRIPTION for frAtmIwfConnectionEntry does enforce that a connection is either p-p or p-mp. Connection descriptors are not unique to a single connection. Connection description has a one to many relationship with different connections. For example, all connections supporting bridging using descriptor 546. Some connections may be p-mp and others p-p. > > I view frAtmIwfConnIndex as a group of connections with the same > connection descriptor as well as a quicker search mechanism for > relation of DLCIs and VCLs. We don't want to replace the connection > index with the connection descriptor because an alternative purpose > for the connection index is to speed up the relational search from the > DLCI or VCL to the connection. This may be solved by making the > connection descriptor the second index of the table. Alternatively, > text can be added to the DESCRIPTION clauses of > frAtmIwfConnectionDescriptor and frAtmIwfConnRowStatus to state the > limitations. > frAtmIwfConnIndex is unique for each p-p or p-mp connection. It could not be replaced by the connection descriptor because the connection descriptor is shared by multiple p-p/p-mp connections. The connection descriptor has no place as an index into the table. It is merely a pointer to more information about the connection - information that is shared by other connections. The table organization is not driven by association with a particular type of connection and thus does not benefit from being indexed by the connection descriptor. I see no limitations that need to be explained in DESCRIPTION clauses of frAtmIwfConnectionDescriptor and frAtmIwfConnRowStatus. Is there something I am missing? > Further, the DESCRIPTION clause of frAtmIwfConnRowStatus is too > limiting. There is no need to be operational to configure a cross > connection. This limitation prevents the user from configuring the > cross connection prior to making the network operational and is not > usable in the field. Also, there is no need to check the admin status > on deleting a cross connection in that deleting it should have no > effect on the administrative status of the links. > I read the DESCRIPTION clause of frAtmIwfConnRowStatus differently. Activation requires the existance of a connection descriptor and up(1) status for each endpoint. No restriction exists that prevents configuration of the cross connection when the endpoints are not active. That having been said, I notice that the instructions in Section 3.5.1, Step 7 are at odds with the DESCRIPTION clause of frAtmIwfConnRowStatus. The current text of the object demands that both segments be up(1) prior to activation. Section 3.5.1 permits the agent to trigger the activation of the segments as a side-effect of processing the SET of up(1). Likewise, as you observed with the delete restriction, the inverse is permitted. I will update the DESCRIPTION clause to match Section 3.5.1 and remove the limitations. > I think that all of the problems can be fixed by changes to only > DESCRIPTION clauses. > I agree > Rob Steinberger > Paradyne Networks > > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with > X-Info: 'unsubscribe frnetmib' in the body of the message. > X-Info: To unsubscribe, email 'majordomo@sunroof.eng.sun.com' with X-Info: 'unsubscribe frnetmib' in the body of the message.