From isis-wg-bounces@ietf.org Thu Jun 02 09:57:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqCh-0005tF-WA; Thu, 02 Jun 2005 09:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqCg-0005t4-Gp for isis-wg@megatron.ietf.org; Thu, 02 Jun 2005 09:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15456 for ; Thu, 2 Jun 2005 09:57:44 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdqWf-0006gR-9l for isis-wg@ietf.org; Thu, 02 Jun 2005 10:18:28 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Thu, 2 Jun 2005 09:57:32 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 09:57:32 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.181 140.233.20.181 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 02 Jun 2005 09:57:31 -0400 Subject: Re: [Isis-wg] Question of different branch in protocol IS-IS MIB From: "Parker, Jeff" To: Enrique Gonz=?ISO-8859-1?B?4Q==?=lez , Message-ID: In-Reply-To: <001801c561cb$f85e6b80$551013ac@tcpsi.es> Mime-version: 1.0 X-OriginalArrivalTime: 02 Jun 2005 13:57:32.0291 (UTC) FILETIME=[059F9530:01C5677B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: arubio@tcpsi.es X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064307528==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2064307528== Content-type: multipart/alternative; boundary="B_3200551052_4294956649" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3200551052_4294956649 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Enrique - The MIB is in last call, so it is not yet a standard. Should it become a standard, IANA will assign it a valid OID outside the Experimental range. There have been some recent discussion on the list, should you have a chance to check the archives. - jeff parker - mib scribe ----- Prior Message in Ascii ------------ Hello. My name is Enrique Gonzalez. I am a Spanish company's engineer of systems management network that we are accomplishing a project of management service in and we need to monitoring a part of environment of network MPLS. For it, we need to know the OID needed to know the information correlated to the protocol IS-IS that it seems not to be very standardized, because in the IETF's RFC http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt) the iso.org.dod.internet.mgmt.mib-2 appears in the branch mib-2 ( 1.3.6.1.2.1 ) However, in the IANA (http://www.iana.org/assignments/smi-numbers) it hangs up on iso.org.dod.internet.experimental ( 1.3.6.1.3 ) It is an element that hangs up of the experimental branch such and how it can be appreciated from that page. I would like could have clarified what information is valid and why this difference. Thank you very much. Greetings. --B_3200551052_4294956649 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] Question of different branch in protocol IS-IS MIB</TI= TLE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Enriq= ue -<BR>     The MIB is in last call, so it is not yet a standar= d.  Should it become a standard, IANA will assign it a valid OID outsid= e the Experimental range.<BR> <BR>     There have been some recent discussion on the list,= should you have a chance to check the archives.<BR> <BR> - jeff parker<BR> - mib scribe<BR> <BR> ----- Prior Message in Ascii ------------<BR> <BR> Hello.<BR> <BR> My name is Enrique Gonzalez. I am a Spanish company's engineer of systems &= nbsp;management  network that we are  accomplishing a project of m= anagement service  in and we need to  monitoring a part of environ= ment of network MPLS.<BR> <BR> For it, we need to know the OID needed to know the information correlated t= o the protocol IS-IS  that it seems not to be very standardized, becaus= e in the IETF's RFC <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-= isis-wg-mib-20.txt)">http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-= mib-20.txt)</a> the iso.org.dod.internet.mgmt.mib-2 appears in the branch mi= b-2 ( 1.3.6.1.2.1 )<BR> However, in the IANA (<a href=3D"http://www.iana.org/assignments/smi-numbers)= ">http://www.iana.org/assignments/smi-numbers)</a> it hangs up on iso.org.do= d.internet.experimental ( 1.3.6.1.3 )<BR> It is an element that hangs up of the experimental branch such and how it c= an be appreciated from that page.<BR> I would like could have clarified what information is valid and why this di= fference.<BR> <BR> Thank you very much.<BR> <BR> Greetings.<BR> </SPAN></FONT> </BODY> </HTML> --B_3200551052_4294956649-- --===============2064307528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============2064307528==-- From isis-wg-bounces@ietf.org Thu Jun 02 10:01:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqFx-0007fG-0J; Thu, 02 Jun 2005 10:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdqFw-0007fA-2Z for isis-wg@megatron.ietf.org; Thu, 02 Jun 2005 10:01:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16449 for <isis-wg@ietf.org>; Thu, 2 Jun 2005 10:01:05 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdqZy-00075m-4m for isis-wg@ietf.org; Thu, 02 Jun 2005 10:21:50 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Thu, 2 Jun 2005 10:00:57 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 2 Jun 2005 10:00:57 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.181 140.233.20.181 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 02 Jun 2005 09:57:31 -0400 Subject: Re: [Isis-wg] Question of different branch in protocol IS-IS MIB From: "Parker, Jeff" <jeffp@middlebury.edu> To: Enrique Gonz=?ISO-8859-1?B?4Q==?=lez <egonzalez@tcpsi.es>, <isis-wg@ietf.org> Message-ID: <BEC4888B.441A%jeffp@middlebury.edu> In-Reply-To: <001801c561cb$f85e6b80$551013ac@tcpsi.es> Mime-version: 1.0 X-OriginalArrivalTime: 02 Jun 2005 14:00:57.0149 (UTC) FILETIME=[7FBA6ED0:01C5677B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: arubio@tcpsi.es X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0920187056==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0920187056== Content-type: multipart/alternative; boundary="B_3200551256_60379" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3200551256_60379 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Enrique - The MIB is in last call, so it is not yet a standard. Should it become a standard, IANA will assign it a valid OID outside the Experimental range. There have been some recent discussion on the list, should you have a chance to check the archives. - jeff parker - mib scribe ----- Prior Message in Ascii ------------ Hello. My name is Enrique Gonzalez. I am a Spanish company's engineer of systems management network that we are accomplishing a project of management service in and we need to monitoring a part of environment of network MPLS. For it, we need to know the OID needed to know the information correlated to the protocol IS-IS that it seems not to be very standardized, because in the IETF's RFC http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt) the iso.org.dod.internet.mgmt.mib-2 appears in the branch mib-2 ( 1.3.6.1.2.1 ) However, in the IANA (http://www.iana.org/assignments/smi-numbers) it hangs up on iso.org.dod.internet.experimental ( 1.3.6.1.3 ) It is an element that hangs up of the experimental branch such and how it can be appreciated from that page. I would like could have clarified what information is valid and why this difference. Thank you very much. Greetings. --B_3200551256_60379 Content-type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Isis-wg] Question of different branch in protocol IS-IS MIB</TI= TLE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Enriq= ue -<BR>     The MIB is in last call, so it is not yet a standar= d.  Should it become a standard, IANA will assign it a valid OID outsid= e the Experimental range.<BR> <BR>     There have been some recent discussion on the list,= should you have a chance to check the archives.<BR> <BR> - jeff parker<BR> - mib scribe<BR> <BR> ----- Prior Message in Ascii ------------<BR> <BR> Hello.<BR> <BR> My name is Enrique Gonzalez. I am a Spanish company's engineer of systems &= nbsp;management  network that we are  accomplishing a project of m= anagement service  in and we need to  monitoring a part of environ= ment of network MPLS.<BR> <BR> For it, we need to know the OID needed to know the information correlated t= o the protocol IS-IS  that it seems not to be very standardized, becaus= e in the IETF's RFC <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-= isis-wg-mib-20.txt)">http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-= mib-20.txt)</a> the iso.org.dod.internet.mgmt.mib-2 appears in the branch mi= b-2 ( 1.3.6.1.2.1 )<BR> However, in the IANA (<a href=3D"http://www.iana.org/assignments/smi-numbers)= ">http://www.iana.org/assignments/smi-numbers)</a> it hangs up on iso.org.do= d.internet.experimental ( 1.3.6.1.3 )<BR> It is an element that hangs up of the experimental branch such and how it c= an be appreciated from that page.<BR> I would like could have clarified what information is valid and why this di= fference.<BR> <BR> Thank you very much.<BR> <BR> Greetings.<BR> </SPAN></FONT> </BODY> </HTML> --B_3200551256_60379-- --===============0920187056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0920187056==-- From isis-wg-bounces@ietf.org Mon Jun 13 14:20:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhtXy-0005xL-Kf; Mon, 13 Jun 2005 14:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhtXx-0005xG-6g for isis-wg@megatron.ietf.org; Mon, 13 Jun 2005 14:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05427 for <isis-wg@ietf.org>; Mon, 13 Jun 2005 14:20:27 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhtuG-0001SA-T0 for isis-wg@ietf.org; Mon, 13 Jun 2005 14:43:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2005 11:20:19 -0700 X-IronPort-AV: i="3.93,194,1115017200"; d="scan'208"; a="278104575:sNHT31216292" Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j5DIKDlq010285; Mon, 13 Jun 2005 11:20:16 -0700 (PDT) Received: from [10.32.9.225] (cfcentral.cisco.com [64.101.210.32]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA13417; Mon, 13 Jun 2005 13:20:05 -0500 (CDT) Mime-Version: 1.0 X-Sender: wardd@127.0.0.1 Message-Id: <p06110402bed37c93f70d@[10.32.9.225]> Date: Mon, 13 Jun 2005 13:20:01 -0500 To: isis-wg@ietf.org From: David Ward <dward@cisco.com> Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: chopps@rawdofmt.org Subject: [Isis-wg] ISIS WG Last Last Call - 72 hour timeout X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org All - This is an announcement of a "Last Last call" (famous last words, eh?) with a 72 hour duration on several drafts that have had multiple WG Last Calls and now have passed idnits. Please review, comment, pick nits, etc on the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt http://www.ietf.org/internet-drafts/draft-ietf-isis-caps-03.txt http://www.ietf.org/internet-drafts/draft-ietf-isis-link-attr-01.txt http://www.ietf.org/internet-drafts/draft-ietf-isis-admin-tags-03.txt If you have any comments on these drafts, please include the common name of the draft in the subject line and cc all authors of the draft. E.g. Subject: Admin Tags LLC showstopper commment Many thanks. Pending no further comments, all the drafts above will proceed to the next step in the process. We aren't expecting any showstopper comments since the only changes are idnits and grammer. But again, these are famous last words. DWard and Chopps _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jun 14 17:25:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIuc-0001Fx-Ld; Tue, 14 Jun 2005 17:25:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIua-0001Eg-3T for isis-wg@megatron.ietf.org; Tue, 14 Jun 2005 17:25:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07426 for <isis-wg@ietf.org>; Tue, 14 Jun 2005 17:25:29 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiJH7-0003Di-Se for isis-wg@ietf.org; Tue, 14 Jun 2005 17:48:51 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Tue, 14 Jun 2005 17:25:18 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jun 2005 17:25:17 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.182 140.233.20.182 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 14 Jun 2005 17:25:18 -0400 From: "Parker, Jeff" <jeffp@middlebury.edu> To: ISIS WG <isis-wg@ietf.org> Message-ID: <BED4C37E.46FE%jeffp@middlebury.edu> In-Reply-To: <E1DaWua-000Dkz-MS@oceanus.uk.clara.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 21:25:17.0968 (UTC) FILETIME=[8FC59100:01C57127] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Wide Counters X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I am reviewing comments that came in during last call. ------ Forwarded Message > From: Adrian Farrel <olddog@clara.co.uk> > Reply-To: <adrian@olddog.co.uk> > Date: Tue, 24 May 2005 11:45:24 +0100 > To: <isis-wg@ietf.org> > Cc: <adrian@olddog.co.uk> > Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB. > 11. Wide counters > > Are you happy with running the hello and packet counters at > only 32 bits? Woth considering how often they would wrap in > normal (default timer) processing. Then note that they would > be used to diagnose misconfiguration of timers when packet > thrash might occur. ------ End of Forwarded Message It is easy for me to make this change, but I'd like to ask other implementors what they think pro and con about such a change (to change all 32 bit counters to 64 bit counters) - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jun 14 18:24:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJpt-0005aN-US; Tue, 14 Jun 2005 18:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiJpr-0005aI-Ph for isis-wg@megatron.ietf.org; Tue, 14 Jun 2005 18:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12917 for <isis-wg@ietf.org>; Tue, 14 Jun 2005 18:24:40 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiKCQ-00072V-Lr for isis-wg@ietf.org; Tue, 14 Jun 2005 18:48:03 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Tue, 14 Jun 2005 18:24:33 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jun 2005 18:24:33 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.182 140.233.20.182 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 14 Jun 2005 18:24:34 -0400 From: "Parker, Jeff" <jeffp@middlebury.edu> To: ISIS WG <isis-wg@ietf.org> Message-ID: <BED4D162.470E%jeffp@middlebury.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Jun 2005 22:24:33.0320 (UTC) FILETIME=[D6ED3A80:01C5712F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Changes for Last Call X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I have run through the suggestions from Last call, and I have made an initial draft which I would be happy to circulate to interested parties. Here are the changes 1) Combine the various flavors of L1, L2, L1L2 into one type and change some terms, as per requests. 2) Changed Integer32 to Unsigned32 throughout 3) Changed Syntax of *UpTime to TimeStamp 4) Attempted to clarify interaction between circuit level and system level. The goal is to allow a circuit level to retain an value that may not match the current system level so that values can survive administrator setting L1L2 System to L1 to clear some issue and return to L1L2. 5) Remove reference to RFC 2863 in AdminState 6) Added text to try to clarify interaction between isisSysLevelSetOverload and isisSysLevelSetOverloadUntil per request 7) Add RFC numbers to MIB names There are a couple of issues remaining. A) Wide counters (see previous mail) B) Counter behavior around discontinuity. C) Text for isisCircIfSubSelector. D) Do we need to turn off notifications? Any opinions or contributions on these topics are welcome. I'd be happy to send a copy of the MIB or the draft off-line to anyone interested. Diffs in the MIB portion are below. - jeff parker ================= myrmidon:~/MIB jeff$ diff mib.20 mib 3,4c3,4 < TEXTUAL-CONVENTION, RowStatus, TruthValue < FROM SNMPv2-TC --- > TEXTUAL-CONVENTION, RowStatus, TruthValue, TimeStamp > FROM SNMPv2-TC -- RFC2579 6,7c6,7 < Integer32, Unsigned32, Counter32, mib-2 < FROM SNMPv2-SMI --- > Unsigned32, Counter32, mib-2 > FROM SNMPv2-SMI -- RFC2578 9c9 < FROM SNMPv2-CONF --- > FROM SNMPv2-CONF -- RFC2580 11c11 < FROM SNMP-FRAMEWORK-MIB --- > FROM SNMP-FRAMEWORK-MIB -- RFC2571 13c13 < FROM DIFFSERV-MIB --- > FROM DIFFSERV-MIB -- RFC3289 15c15 < FROM IF-MIB --- > FROM IF-MIB -- RFC2863 17c17 < FROM INET-ADDRESS-MIB; --- > FROM INET-ADDRESS-MIB; -- RFC3291 125,126c125 < "Type used in enabling and disabling a row. < Values match those in RFC 2863." --- > "Type used in enabling and disabling a row." 138c137 < SYNTAX Integer32 (512..16000) --- > SYNTAX Unsigned32 (512..16000) 172c171 < SYNTAX Integer32 (0..63) --- > SYNTAX Unsigned32 (0..63) 222c221 < IsisAdjLevel ::= TEXTUAL-CONVENTION --- > IsisLevel ::= TEXTUAL-CONVENTION 250c249 < SYNTAX Integer32 (0..127) --- > SYNTAX Unsigned32 (0..127) 312,317c311 < SYNTAX INTEGER < { < level1IS (1), < level2IS (2), < level1L2IS (3) < } --- > SYNTAX IsisLevel 326c320 < DEFVAL { level1L2IS } --- > DEFVAL { level1and2 } 346c340 < SYNTAX Integer32 (1..32) --- > SYNTAX Unsigned32 (1..32) 359c353 < SYNTAX Integer32 (1..65235) --- > SYNTAX Unsigned32 (1..65235) 526,527c520,521 < an attempt is made to set this object to the value 'destroy' < or 'notInService' when this is the only --- > an attempt is made to set this object to the value > 'destroy' or 'notInService' when this is the only 1014c1008,1012 < isisSysLevelSetOverload object." --- > isisSysLevelSetOverload object. > > If isisSysLevelSetOverload is false, the system clears > the overload bit when isisSysLevelSetOverloadUntil > jave elapsed, if the system has not run out of memory." 1106c1104 < Integer32, --- > Unsigned32, 1115,1116c1113,1114 < isisCircLevel < INTEGER, --- > isisCircLevelType > IsisLevel, 1126c1124 < Unsigned32, --- > TimeStamp, 1158c1156 < SYNTAX Integer32 --- > SYNTAX Unsigned32 1226,1232c1224,1225 < isisCircLevel OBJECT-TYPE < SYNTAX INTEGER < { < level1(1), < level2(2), < level1L2(3) < } --- > isisCircLevelType OBJECT-TYPE > SYNTAX IsisLevel 1237,1240c1230,1237 < accepted on this circuit. The values used will be < modified by the settings of isisSysType. This < object follows the replaceOnlyWhileDisabled behavior." < DEFVAL { level1L2 } --- > accepted on this circuit. The values set will be > saved, but the values used will be modified by > the settings of isisSysType. Thus if the > isisSysTpe is level2 and the isisCircLevelType > for a circuit is level1, the circuit will not send > or receive IS-IS packets. This object follows the > replaceOnlyWhileDisabled behavior." > DEFVAL { level1and2 } 1299,1300c1296 < SYNTAX Unsigned32 < UNITS "Seconds since startup when this circuit was last 'on'" --- > SYNTAX TimeStamp 1366c1362 < Integer32, --- > Unsigned32, 1372c1368 < Integer32, --- > Unsigned32, 1374c1370 < Integer32, --- > Unsigned32, 1376c1372 < Integer32, --- > Unsigned32, 1380c1376 < Integer32, --- > Unsigned32, 1382c1378 < Integer32, --- > Unsigned32, 1384c1380 < Integer32 --- > Unsigned32 1426c1422 < SYNTAX Integer32(0..255) --- > SYNTAX Unsigned32(0..255) 1477c1473 < SYNTAX Integer32 (2..100) --- > SYNTAX Unsigned32 (2..100) 1490c1486 < SYNTAX Integer32 (10..600000) --- > SYNTAX Unsigned32 (10..600000) 1508c1504 < SYNTAX Integer32 (10..120000) --- > SYNTAX Unsigned32 (10..120000) 1535c1531 < SYNTAX Integer32 (1..300) --- > SYNTAX Unsigned32 (1..300) 1552c1548 < SYNTAX Integer32 (1..600) --- > SYNTAX Unsigned32 (1..600) 1567c1563 < SYNTAX Integer32 (1..120) --- > SYNTAX Unsigned32 (1..120) 2114c2110 < IsisAdjLevel, --- > IsisLevel, 2120c2116 < Unsigned32 --- > TimeStamp 2211c2207 < SYNTAX IsisAdjLevel --- > SYNTAX IsisLevel 2245,2246c2241 < SYNTAX Unsigned32 < UNITS "Seconds since startup when Adjacency was last up" --- > SYNTAX TimeStamp 3137c3132 < SYNTAX IsisAdjLevel --- > SYNTAX IsisLevel 3145c3140 < SYNTAX Integer32 (1..2147483647) --- > SYNTAX Unsigned32 (1..2147483647) 3198c3193 < SYNTAX Integer32 (0..2147483647) --- > SYNTAX Unsigned32 (0..2147483647) 3694,3695c3689,3690 < related objects, are expressed below in pseudo- < OBJECT clause form in this description: --- > related objects, are expressed below in > pseudo-OBJECT clause form in this description: 3743,3744c3738,3739 < related objects, are expressed below in pseudo- < OBJECT clause form in this description: --- > related objects, are expressed below in > pseudo-OBJECT clause form in this description: 3806,3809c3801,3804 < "When this MIB is implemented without support for read- < create (i.e. in read-only mode), the implementation can < claim read-only compliance. Such a device can then be < monitored but can not be configured with this MIB." --- > "When this MIB is implemented without support for > read-create (i.e. in read-only mode), the implementation > can claim read-only compliance. Such a device can then > be monitored but can not be configured with this MIB." 3952c3947 < OBJECT isisCircLevel --- > OBJECT isisCircLevelType 4102a4098 > isisCircLevelType, 4112d4107 < isisCircLevel, _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 15 06:56:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiVZe-0006Lr-EZ; Wed, 15 Jun 2005 06:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiVZc-0006KW-IT for isis-wg@megatron.ietf.org; Wed, 15 Jun 2005 06:56:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01545 for <isis-wg@ietf.org>; Wed, 15 Jun 2005 06:56:41 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiVwH-0007D2-MK for isis-wg@ietf.org; Wed, 15 Jun 2005 07:20:11 -0400 Received: from enfimail1.datcon.co.uk ([172.19.14.253]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 11:56:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Wide Counters X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 15 Jun 2005 11:56:22 +0100 Message-ID: <A863E1894A42FC41BABEA67D2DE5243F07136E@enfimail1.datcon.co.uk> Thread-Topic: [Isis-wg] Wide Counters Thread-Index: AcVxJ7bDttMghjGWTdKgkG8Cq+cbIAAbTBlA From: "Jonathan Harrison" <jon.harrison@dataconnection.com> To: "Parker, Jeff" <jeffp@middlebury.edu>, "ISIS WG" <isis-wg@ietf.org> X-OriginalArrivalTime: 15 Jun 2005 10:56:22.0303 (UTC) FILETIME=[DDF9CAF0:01C57198] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Jeff, The isisSystemCounter and isisCircuitCounter should definitely stay as = 32-bit counters, as these count rare events (for most of these, any = change indicates a configuration issue). My view is that the packet counts are also fine as 32-bit counters. If = I were using the counters to check for timer misconfiguration, I would = expect to check the values initially, and then check the values again a = short time later. The main requirement for the size of the counter is = that it should give an unambiguous count of packets received over this = short period. For example, if the reading is 1000 on the first check, = and 1001 on the second check shortly afterwards, the network manager = should be able to be confident that 1 packet has been received and the = counter hasn't wrapped in-between the two checks. At the fairly high rate for steady state IS-IS of 10 packets a second, = it will be 13.6 years before the 32-bit counter wraps. Even a packet = thrash with, say, 10,000 packets a second would only cause the counters = to wrap after 5 days - which ought to be long enough to check the MIB a = couple of times. So I'm happy with the counters as they are now. Jon -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Parker, Jeff Sent: 14 June 2005 22:25 To: ISIS WG Subject: [Isis-wg] Wide Counters I am reviewing comments that came in during last call. ------ Forwarded Message > From: Adrian Farrel <olddog@clara.co.uk> > Reply-To: <adrian@olddog.co.uk> > Date: Tue, 24 May 2005 11:45:24 +0100 > To: <isis-wg@ietf.org> > Cc: <adrian@olddog.co.uk> > Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB. =20 > 11. Wide counters >=20 > Are you happy with running the hello and packet counters at > only 32 bits? Woth considering how often they would wrap in > normal (default timer) processing. Then note that they would > be used to diagnose misconfiguration of timers when packet > thrash might occur. ------ End of Forwarded Message It is easy for me to make this change, but I'd like to ask other implementors what they think pro and con about such a change (to change = all 32 bit counters to 64 bit counters) - jeff parker =20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 16 15:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dizar-0003wh-0j; Thu, 16 Jun 2005 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dizap-0003uE-1h for isis-wg@megatron.ietf.org; Thu, 16 Jun 2005 14:59:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25563 for <isis-wg@ietf.org>; Thu, 16 Jun 2005 14:59:53 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dizxj-0005Ao-TM for isis-wg@ietf.org; Thu, 16 Jun 2005 15:23:42 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Thu, 16 Jun 2005 14:59:42 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Jun 2005 14:59:42 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.182 140.233.20.182 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 16 Jun 2005 14:59:42 -0400 From: "Parker, Jeff" <jeffp@middlebury.edu> To: ISIS WG <isis-wg@ietf.org> Message-ID: <BED7445E.47AE%jeffp@middlebury.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Jun 2005 18:59:42.0388 (UTC) FILETIME=[8DC95740:01C572A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] More Last Call Changes X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org We have had a few comments since my last post. Here are the changes from prior edit. 1) Combine the various flavors of L1, L2, L1L2 into one type and change some terms, as per requests. 2) Changed Integer32 to Unsigned32 throughout 3) Changed Syntax of *UpTime to TimeStamp 4) Attempted to clarify interaction between circuit level and system level. The operator is able to set circuit to level L1L2 while system is at L1, to prepare for a move to L1L2. 5) Remove reference to RFC 2863 in AdminState 6) Added text to try to clarify interaction between isisSysLevelSetOverload and isisSysLevelSetOverloadUntil per request 7) Add RFC numbers to MIB names Actions on the remaining issues A) Wide counters (see previous mail) I have not heard a request for 64 bit counters. The only counters that are in danger of wrapping are the packet counters, and those are an aid to debugging rather than a management tool. No change B) Counter behavior around discontinuity. I don't see this as an issue No change C) Text for isisCircIfSubSelector. I have modified the description D) Do we need to turn off notifications? I have added a field isisSysNotificationEnable and added a reference when defining the notifications I believe this represents the remaining issues. I will wait for at least 24 hours and then resubmit a draft. I'd be happy to send a copy of the MIB or the draft off-line to anyone Interested in the interim. - jeff parker Diffs for C & D since last set of diffs. 458a459,469 > isisSysNotificationEnable OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "If this object is set to true(1), then it enables > the emission of IS-IS Notifications. If it is > set to false(2), these notifications are not sent." > DEFVAL { true } > ::= { isisSysObject 13 } > 1162c1173,1176 < This object cannot be modified after creation. --- > If an implementation uses a single ifIndex for distinct > IS-IS circuits, the isisCircIfSubSelector may be used > to distinguish them. This object cannot be modified after > creation. 3270a3285,3287 > -- > -- Note that notifications can be disabled by setting > -- isisSysNotificationEnable false 4053a4071 > isisSysNotificationEnable, _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 23 10:14:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSTp-0002a1-A9; Thu, 23 Jun 2005 10:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlSTo-0002Zo-8T for isis-wg@megatron.ietf.org; Thu, 23 Jun 2005 10:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14706 for <isis-wg@ietf.org>; Thu, 23 Jun 2005 10:14:54 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlSs8-00060k-6r for isis-wg@ietf.org; Thu, 23 Jun 2005 10:40:05 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Thu, 23 Jun 2005 10:14:44 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Thu, 23 Jun 2005 10:14:44 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.182 140.233.20.182 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 23 Jun 2005 10:14:41 -0400 From: "Parker, Jeff" <jeffp@middlebury.edu> To: ISIS WG <isis-wg@ietf.org> Message-ID: <BEE03C11.48E4%jeffp@middlebury.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jun 2005 14:14:44.0305 (UTC) FILETIME=[E76D2C10:01C577FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Isis-wg] MIB v.21 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I have forwarded a new draft of the MIB to the IETF this morning, and I just received their acknowledgement. The changes are as reflected in my mail of last Friday. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 24 15:50:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluCM-0005SQ-9d; Fri, 24 Jun 2005 15:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DluBk-0005Aa-Oa; Fri, 24 Jun 2005 15:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08828; Fri, 24 Jun 2005 15:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DluaJ-0007x1-LO; Fri, 24 Jun 2005 16:15:32 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DluBd-00056W-IJ; Fri, 24 Jun 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1DluBd-00056W-IJ@newodin.ietf.org> Date: Fri, 24 Jun 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-21.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-21.txt Pages : 102 Date : 2005-6-24 This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-mib-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-mib-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@ietf.org" Content-Type: text/plain Content-ID: <2005-6-24150714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-24150714.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Jun 24 22:00:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlzy1-0001zW-K8; Fri, 24 Jun 2005 22:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlzxz-0001zO-U9 for isis-wg@megatron.ietf.org; Fri, 24 Jun 2005 22:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20266 for <isis-wg@ietf.org>; Fri, 24 Jun 2005 22:00:17 -0400 (EDT) From: jcucchiara@mindspring.com Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm0Mc-0005wx-G5 for isis-wg@ietf.org; Fri, 24 Jun 2005 22:25:47 -0400 Received: from h-67-100-203-200.cmbrmaor.dynamic.covad.net ([67.100.203.200] helo=jluciani-laptop) by pop06.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1Dlzxc-0003eb-00; Fri, 24 Jun 2005 21:59:56 -0400 Message-Id: <3.0.1.32.20050624203818.012d15d0@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 24 Jun 2005 20:38:18 -0400 To: Christian Hopps <chopps@rawdofmt.org>, ISIS WG <isis-wg@ietf.org> In-Reply-To: <3.0.1.32.20050528155041.0149ba78@pop.mindspring.com> References: <CF7B5E82-B811-45A1-876B-01C0B38966EB@rawdofmt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.5 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: Subject: [Isis-wg] Version 21 of ISIS MIB X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org The following which is preceeded with > is my original email for the Last call of this MIB. A few concerns have not been addressed in version 21 and these are indicated inline below. At 03:50 PM 5/28/05 -0400, jcucchiara@mindspring.com wrote: > >Most of my comments deal with the following 2 objects: > > >isisSysType OBJECT-TYPE > SYNTAX INTEGER > { > level1IS (1), > level2IS (2), > level1L2IS (3) > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "At which levels is the Intermediate System > running? This object may not be modified when > the isisSysAdminState variable is in state 'on' > for this Intermediate System." > REFERENCE "{ISIS.aoi iSType (2)}" > DEFVAL { level1L2IS } > ::= { isisSysObject 2 } > > >isisCircLevel OBJECT-TYPE > SYNTAX INTEGER > { > level1(1), > level2(2), > level1L2(3) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Indicates which type of packets will be sent and > accepted on this circuit. The values used will be > modified by the settings of isisSysType. This > object follows the replaceOnlyWhileDisabled behavior." > DEFVAL { level1L2 } > ::= { isisCircEntry 8 } > > > >1a) Why can't the TC IsisAdjLevel be used for isisSysType and isisCircLevel? > > >IsisAdjLevel ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Identifies one or more levels." > SYNTAX INTEGER > { > level1(1), > level2(2), > level1and2(3) > } > > >If this TC can be used (and I think that it can/should) then >please rename this to something more generic such as IsisLevelType > done. Thank you. > >1b) The naming is inconsistent for the following related objects > > >isisSysType and >isisCircLevel > > >Since these are related, could they be renamed >so as to indicate they are related, e.g. isisSysType, isisCircType >or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType? > not done, so why not? > >1c) Could the description of isisCircLevel be clarified such that >an implementor understands what the agent is supposed to >return for an error in the event that isisSysType has a value of level1(1) >and an operator attempts to set isisCircLevel to level2(2) or level1and2(3)? > not done and the behavior of this object has been changed. I am not in favor of allowing this object to be set and having no indication of whether or not the specific circuit level is passing packets and would like to understand why this change was made. If this is thought by the working group to be a change for the better, then I would ask that an CircLevelOperStatus object be added to the CircLevel Table. >2) Several Entry descriptions contain a phrase similar to > "Configured values will survive an agent reboot", I don't understand > why this would be dictated by a MIB? In other words, why isn't > a StorageType object present in these tables? Mike explained why the original description is valid. > > >3) The following object's > > > > isisCircIfSubSelector OBJECT-TYPE > SYNTAX Integer32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "A specifier for the part of the interface ifIndex to which > this circuit corresponds, such as a DLCI or VPI/VCI. > This object cannot be modified after creation. > > Holds 0 if not used." > DEFVAL { 0 } > ::= { isisCircEntry 3 } > >DESCRIPTION is confusing. In the case of ATM, does this value contain >an ifIndex or zero, and if so, what is the ifType that corresponds to this >ifIndex? > >Or, could it contain an actual VPI/VCI in which case 0 could be a valid >VPI/VCI? > >Furthermore, the Abstract states: > > "This document describes a management information base for the IS-IS > Routing protocol when it is used to construct routing tables for IP > networks." > >so why is there a need to have this object at all? > The description has changed slightly, but the original concerns have not been addressed. Additionally, if there is an ifIndex which corresponds to an IS-IS circuit, as this new description says, then an ifType should also be defined. Thanks, -Joan >Thanks, > -Joan > > > > > >At 08:43 AM 5/18/05 -0700, Christian Hopps wrote: >>As the MIB doctor review is complete the IS-IS MIB is now in WG last >>call. Please recall that we are only looking for issues with the >>current version of the MIB as we need to get this document published. >>It was pointed out that we could add support for graceful restart; >>however, changes such as this will have to be addressed in a later >>revision of the MIB. >> >>Please post any comments by June 1st. >> >>Chris and Dave. >> >>_______________________________________________ >>Isis-wg mailing list >>Isis-wg@ietf.org >>https://www1.ietf.org/mailman/listinfo/isis-wg >> > > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Jun 25 12:16:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmDKV-0007Kh-70; Sat, 25 Jun 2005 12:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmDKT-0007Kc-Bu for isis-wg@megatron.ietf.org; Sat, 25 Jun 2005 12:16:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14925 for <isis-wg@ietf.org>; Sat, 25 Jun 2005 12:16:22 -0400 (EDT) Received: from mail01.net-streams.fr ([62.23.133.110] helo=6wind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmDjB-0001qL-H1 for isis-wg@ietf.org; Sat, 25 Jun 2005 12:42:00 -0400 Date: Sat, 25 Jun 2005 18:14:58 +0200 Message-Id: <10506251814.AA22138@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "mohit.thakur" <mohit.thakur@6wind.com> To: isis-wg@ietf.org X-Mailer: <SMTP32 v8.20> Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Isis-wg] automated response X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Reply-To: mohit.thakur@6wind.com List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, I am out of country, would get back to you with the first opportunity once i am back. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sun Jun 26 03:55:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmRzh-0004Y5-6s; Sun, 26 Jun 2005 03:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm0sS-0005SP-Ad for isis-wg@megatron.ietf.org; Fri, 24 Jun 2005 22:58:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23666 for <isis-wg@ietf.org>; Fri, 24 Jun 2005 22:58:38 -0400 (EDT) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm1H6-0007NO-P8 for isis-wg@ietf.org; Fri, 24 Jun 2005 23:24:09 -0400 Received: from 209-150-50-52.c3-0.nwt-ubr3.sbo-nwt.ma.cable.rcn.com (HELO [192.168.1.100]) (209.150.50.52) by smtp04.mrf.mail.rcn.net with ESMTP; 24 Jun 2005 22:58:38 -0400 X-IronPort-AV: i="3.93,229,1115006400"; d="scan'208"; a="51533528:sNHT24233624" Mime-Version: 1.0 X-Sender: jparker@pop.theworld.com Message-Id: <p06100500bee27474f092@[192.168.1.100]> In-Reply-To: <3.0.1.32.20050624203818.012d15d0@pop.mindspring.com> References: <CF7B5E82-B811-45A1-876B-01C0B38966EB@rawdofmt.org> <3.0.1.32.20050624203818.012d15d0@pop.mindspring.com> Date: Fri, 24 Jun 2005 23:04:00 -0400 To: jcucchiara@mindspring.com From: Jeff Parker <jparker@world.std.com> Subject: Re: [Isis-wg] Version 21 of ISIS MIB Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff X-Mailman-Approved-At: Sun, 26 Jun 2005 03:55:37 -0400 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org >The following which is preceeded with > is my original email >for the Last call of this MIB. A few concerns have not been >addressed in version 21 and these are indicated inline below. > Julia - Sorry that you missed the earlier discussion and diffs. >At 03:50 PM 5/28/05 -0400, jcucchiara@mindspring.com wrote: >> >>Most of my comments deal with the following 2 objects: >> >> >>isisSysType OBJECT-TYPE >> SYNTAX INTEGER >> { >> level1IS (1), >> level2IS (2), >> level1L2IS (3) >> } >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "At which levels is the Intermediate System >> running? This object may not be modified when >> the isisSysAdminState variable is in state 'on' >> for this Intermediate System." >> REFERENCE "{ISIS.aoi iSType (2)}" >> DEFVAL { level1L2IS } >> ::= { isisSysObject 2 } >> >> >>isisCircLevel OBJECT-TYPE >> SYNTAX INTEGER >> { >> level1(1), >> level2(2), >> level1L2(3) >> } >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Indicates which type of packets will be sent and >> accepted on this circuit. The values used will be >> modified by the settings of isisSysType. This >> object follows the replaceOnlyWhileDisabled behavior." >> DEFVAL { level1L2 } >> ::= { isisCircEntry 8 } >> >> >> >>1a) Why can't the TC IsisAdjLevel be used for isisSysType and isisCircLevel? >> >> >>IsisAdjLevel ::= TEXTUAL-CONVENTION >> STATUS current >> DESCRIPTION >> "Identifies one or more levels." >> SYNTAX INTEGER >> { >> level1(1), >> level2(2), >> level1and2(3) >> } >> >> >>If this TC can be used (and I think that it can/should) then >>please rename this to something more generic such as IsisLevelType >> > >done. Thank you. > >> >>1b) The naming is inconsistent for the following related objects >> >> >>isisSysType and >>isisCircLevel >> >> >>Since these are related, could they be renamed >>so as to indicate they are related, e.g. isisSysType, isisCircType >>or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType? >> > >not done, so why not? There is already something called isisCircType, so I could not use that name. I changed the name to isisCircLevelType in an attempt to address your concern. Do you have a specific proposal? > >> >>1c) Could the description of isisCircLevel be clarified such that >>an implementor understands what the agent is supposed to >>return for an error in the event that isisSysType has a value of level1(1) >>and an operator attempts to set isisCircLevel to level2(2) or level1and2(3)? >> > >not done and the behavior of this object has been changed. >I am not in favor of allowing this object to be set and having no >indication of whether or not the specific circuit level >is passing packets and would like to understand why >this change was made. > >If this is thought by the working group to be a change for the >better, then I would ask that an CircLevelOperStatus object be >added to the CircLevel Table. > I'm sorry if the intent was not clear: this has been my aim all along. I think it is useful to allow an administrator to have a system running at level L1, and prepare circuits to run at L2 or L1L2 before switching the system to L1L2 to reduce the changes in state that are seen in the network. You can find out if the circuit is passing packets or not by performing a logical OR on the system level and the circuit level. > > >>3) The following object's >> >> >> >> isisCircIfSubSelector OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "A specifier for the part of the interface ifIndex to which >> this circuit corresponds, such as a DLCI or VPI/VCI. > > This object cannot be modified after creation. >> >> Holds 0 if not used." >> DEFVAL { 0 } >> ::= { isisCircEntry 3 } >> >>DESCRIPTION is confusing. In the case of ATM, does this value contain >>an ifIndex or zero, and if so, what is the ifType that corresponds to this >>ifIndex? >> >>Or, could it contain an actual VPI/VCI in which case 0 could be a valid >>VPI/VCI? >> >>Furthermore, the Abstract states: >> >> "This document describes a management information base for the IS-IS >> Routing protocol when it is used to construct routing tables for IP >> networks." >> >>so why is there a need to have this object at all? >> > >The description has changed slightly, but the original concerns have >not been addressed. There were several original concerns. Is your remaining concern the value 0? Do you have a specific suggestion? >Additionally, if there is an ifIndex which corresponds to an IS-IS circuit, >as this new description says, then an ifType should also be defined. > >Thanks, > -Joan There is an isisCircIfIndex which refers to the ifIndex. Can't you fetch the ifType out of the Interface MIB? I admit that we have more circuit indicies than any two MIBs need, but this dates back to a specific request. It sounds to me as though your implementation has no need for this field. Can't you can return 0 and be done with this? - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jun 28 11:13:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHmd-0004hV-Sn; Tue, 28 Jun 2005 11:13:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnHmc-0004hQ-DZ for isis-wg@megatron.ietf.org; Tue, 28 Jun 2005 11:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17990 for <isis-wg@ietf.org>; Tue, 28 Jun 2005 11:13:52 -0400 (EDT) From: jcucchiara@mindspring.com Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnIBz-0005TX-LE for isis-wg@ietf.org; Tue, 28 Jun 2005 11:40:08 -0400 Received: from h-67-101-123-240.cmbrmaor.dynamic.covad.net ([67.101.123.240] helo=jluciani-laptop) by pop06.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1DnHmQ-0002hg-00; Tue, 28 Jun 2005 11:13:42 -0400 Message-Id: <3.0.1.32.20050628091542.0136b5ec@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 28 Jun 2005 09:15:42 -0400 To: Jeff Parker <jparker@world.std.com> Subject: Re: [Isis-wg] Version 21 of ISIS MIB In-Reply-To: <p06100500bee27474f092@[192.168.1.100]> References: <3.0.1.32.20050624203818.012d15d0@pop.mindspring.com> <CF7B5E82-B811-45A1-876B-01C0B38966EB@rawdofmt.org> <3.0.1.32.20050624203818.012d15d0@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 11:04 PM 6/24/05 -0400, Jeff Parker wrote: >>The following which is preceeded with > is my original email >>for the Last call of this MIB. A few concerns have not been >>addressed in version 21 and these are indicated inline below. >> > >Julia - > Sorry that you missed the earlier discussion and diffs. > > >>At 03:50 PM 5/28/05 -0400, jcucchiara@mindspring.com wrote: >>> >>>Most of my comments deal with the following 2 objects: >>> >>> >>>isisSysType OBJECT-TYPE >>> SYNTAX INTEGER >>> { >>> level1IS (1), >>> level2IS (2), >>> level1L2IS (3) >>> } >>> MAX-ACCESS read-write >>> STATUS current >>> DESCRIPTION >>> "At which levels is the Intermediate System >>> running? This object may not be modified when >>> the isisSysAdminState variable is in state 'on' >>> for this Intermediate System." >>> REFERENCE "{ISIS.aoi iSType (2)}" >>> DEFVAL { level1L2IS } >>> ::= { isisSysObject 2 } >>> >>> >>>isisCircLevel OBJECT-TYPE >>> SYNTAX INTEGER >>> { >>> level1(1), >>> level2(2), >>> level1L2(3) >>> } >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Indicates which type of packets will be sent and >>> accepted on this circuit. The values used will be >>> modified by the settings of isisSysType. This >>> object follows the replaceOnlyWhileDisabled behavior." >>> DEFVAL { level1L2 } >>> ::= { isisCircEntry 8 } >>> >>> >>> >>>1a) Why can't the TC IsisAdjLevel be used for isisSysType and isisCircLevel? >>> >>> >>>IsisAdjLevel ::= TEXTUAL-CONVENTION >>> STATUS current >>> DESCRIPTION >>> "Identifies one or more levels." >>> SYNTAX INTEGER >>> { >>> level1(1), >>> level2(2), >>> level1and2(3) >>> } >>> >>> >>>If this TC can be used (and I think that it can/should) then >>>please rename this to something more generic such as IsisLevelType >>> >> >>done. Thank you. >> >>> >>>1b) The naming is inconsistent for the following related objects >>> >>> >>>isisSysType and >>>isisCircLevel >>> >>> >>>Since these are related, could they be renamed >>>so as to indicate they are related, e.g. isisSysType, isisCircType >>>or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType? >>> >> >>not done, so why not? > > >There is already something called isisCircType, so I could not use >that name. I changed the name to isisCircLevelType in an attempt to >address your concern. > >Do you have a specific proposal? Yes, isisSysLevelType and isisCircLevelType. This way the suffixes are the SAME and indicate that there is a relationship between these objects. > >> >>> >>>1c) Could the description of isisCircLevel be clarified such that >>>an implementor understands what the agent is supposed to >>>return for an error in the event that isisSysType has a value of level1(1) >>>and an operator attempts to set isisCircLevel to level2(2) or level1and2(3)? >>> >> >>not done and the behavior of this object has been changed. >>I am not in favor of allowing this object to be set and having no >>indication of whether or not the specific circuit level >>is passing packets and would like to understand why >>this change was made. >> >>If this is thought by the working group to be a change for the >>better, then I would ask that an CircLevelOperStatus object be >>added to the CircLevel Table. >> > >I'm sorry if the intent was not clear: this has been my aim all along. > >I think it is useful to allow an administrator to have a system >running at level L1, and prepare circuits to run at L2 or L1L2 >before switching the system to L1L2 to reduce the changes in state >that are seen in the network. Operators typically do not make sweeping changes as you describe above. Typically they would change the system level and then turn up one circuit at a time to make sure that the network comes back as expected. They don't tend to trust preconfiguration. > >You can find out if the circuit is passing packets or not by >performing a logical OR on the system level and the circuit level. > What about at the far end of a circuit, and it all of a sudden stops receiving packets? An CircLevelOperStatus object would be beneficial in this case. >> > >>>3) The following object's >>> >>> >>> >>> isisCircIfSubSelector OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "A specifier for the part of the interface ifIndex to which >>> this circuit corresponds, such as a DLCI or VPI/VCI. >> > This object cannot be modified after creation. >>> >>> Holds 0 if not used." >>> DEFVAL { 0 } >>> ::= { isisCircEntry 3 } >>> >>>DESCRIPTION is confusing. In the case of ATM, does this value contain >>>an ifIndex or zero, and if so, what is the ifType that corresponds to this >>>ifIndex? >>> >>>Or, could it contain an actual VPI/VCI in which case 0 could be a valid >>>VPI/VCI? >>> >>>Furthermore, the Abstract states: >>> >>> "This document describes a management information base for the IS-IS >>> Routing protocol when it is used to construct routing tables for IP >>> networks." >>> >>>so why is there a need to have this object at all? >>> >> >>The description has changed slightly, but the original concerns have >>not been addressed. > >There were several original concerns. Is your remaining concern the value 0? > >Do you have a specific suggestion? > Yes, since this object is not IP specific, it should be removed. >>Additionally, if there is an ifIndex which corresponds to an IS-IS circuit, >>as this new description says, then an ifType should also be defined. >> >>Thanks, >> -Joan > >There is an isisCircIfIndex which refers to the ifIndex. Can't you >fetch the ifType out of the Interface MIB? > As I state above the DESCRIPTION now refers to an ISIS circuit as having an ifIndex, if this is accurate, then there needs to be an ifType and I couldn't find one, so am asking what this would be? >I admit that we have more circuit indicies than any two MIBs need, >but this dates back to a specific request. It sounds to me as though >your implementation has no need for this field. Can't you can return >0 and be done with this? > > Jeff, the point is that this object is not sufficiently defined, so am asking for it to be removed, OR be better defined. Perhaps an additional object which states the ifType needs to be added. Also, why isn't this doesn't this object have the SYNTAX of InterfaceIndexOrZero? -Joan >- jeff parker > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 29 02:36:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnWBW-0003eo-SO; Wed, 29 Jun 2005 02:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnWBV-0003ej-E9 for isis-wg@megatron.ietf.org; Wed, 29 Jun 2005 02:36:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14958 for <isis-wg@ietf.org>; Wed, 29 Jun 2005 02:36:32 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnWb0-0004Vi-9U for isis-wg@ietf.org; Wed, 29 Jun 2005 03:02:54 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j5T6aELb011518; Tue, 28 Jun 2005 23:36:14 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j5T6aAl0006118; Tue, 28 Jun 2005 23:36:10 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j5T6a9pr006113; Tue, 28 Jun 2005 23:36:09 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 28 Jun 2005 23:36:09 -0700 (PDT) From: "C. M. Heard" <heard@pobox.com> X-Sender: heard@shell4.bayarea.net To: ISIS WG <isis-wg@ietf.org> In-Reply-To: <E1DluBd-00056W-IJ@newodin.ietf.org> Message-ID: <Pine.LNX.4.10.10506281336350.10774-100000@shell4.bayarea.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com> Subject: [Isis-wg] MIB doctor issues with draft-ietf-isis-wg-mib-21.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Fri, 24 Jun 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > IS-IS for IP Internets Working Group of the IETF. > > Title : Management Information Base for IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-wg-mib-21.txt > Pages : 102 > Date : 2005-6-24 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-21.txt With a few exceptions noted below, the changes in going from version 20 to version 21 look OK to me. I didn't catch these issues in the pre-submission discussion because I don't regularly monitor this list; sorry about that. Anyway, here are the complaints: - Typo in isisSysLevelSetOverloadUntil DESCRIPTION clause: OLD: If isisSysLevelSetOverload is false, the system clears the overload bit when isisSysLevelSetOverloadUntil jave elapsed, if the system has not run out of memory." NEW: If isisSysLevelSetOverload is false, the system clears the overload bit when isisSysLevelSetOverloadUntil seconds have elapsed, if the system has not run out of memory." - The DESCRIPTION clauses for the objects isisCircLastUpTime and isisISAdjLastUpTime are now inconsistent with the SYNTAX values. What has happened is that these objects are now of type TimeStamp, and so are values of sysUpTime (see RFC 2579), which has units of 1/100 of a second since the last re-initialization of the network management portion of the system (RFC 3418). However, the DESCRIPTION clauses say that the xyzLastUpTime objects represent the "number of seconds since system startup" that the relevent event occurred. Possible remedies are: (a) re-instate the version 20 SYNTAX of Unsigned32 in both definitions; (b) change the phrase "number of seconds since system startup" to "number of hundredths of a second since the network management portion of the system was last re-initialized" in both definitions. These are the only MIB Doctor issues that I personally have with the draft. However, I would like to say that Joan Cucchiara's suggestion to change the SYNTAX of isisCircIfIndex from InterfaceIndex to InterfaceIndexOrZero is the correct thing to do _if_ it is agreed that there may be circuits for which there is no corresponding IfEntry. Regards, Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 29 10:49:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dndsk-0000Wn-4X; Wed, 29 Jun 2005 10:49:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dndsc-0000Um-TT for isis-wg@megatron.ietf.org; Wed, 29 Jun 2005 10:49:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28107 for <isis-wg@ietf.org>; Wed, 29 Jun 2005 10:49:32 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DneI8-0000pA-UW for isis-wg@ietf.org; Wed, 29 Jun 2005 11:16:00 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.33 ; Wed, 29 Jun 2005 10:48:18 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Jun 2005 10:47:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] MIB doctor issues with draft-ietf-isis-wg-mib-21.txt Date: Wed, 29 Jun 2005 10:44:58 -0400 Message-ID: <664FBBD972927F499753DB2E44E2430C02BE2733@grasshopper.middlebury.edu> Thread-Topic: [Isis-wg] MIB doctor issues with draft-ietf-isis-wg-mib-21.txt Thread-Index: AcV8deObfTDnknYvTbGtpndx7Q3BwQAQyCp2 From: "Parker, Jeff" <jeffp@middlebury.edu> To: "C. M. Heard" <heard@pobox.com>, "ISIS WG" <isis-wg@ietf.org> X-OriginalArrivalTime: 29 Jun 2005 14:47:21.0173 (UTC) FILETIME=[744A0850:01C57CB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: "Wijnen, Bert \(Bert\)" <bwijnen@lucent.com> X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/isis-wg> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Mike, Julia - Thanks: I will address these issues early next week. =20 - jeff parker -----Original Message----- From: isis-wg-bounces@ietf.org on behalf of C. M. Heard Sent: Wed 6/29/2005 2:36 AM To: ISIS WG Cc: Wijnen, Bert (Bert) Subject: [Isis-wg] MIB doctor issues with draft-ietf-isis-wg-mib-21.txt=20 On Fri, 24 Jun 2005 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > IS-IS for IP Internets Working Group of the IETF. >=20 > Title : Management Information Base for IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-wg-mib-21.txt > Pages : 102 > Date : 2005-6-24 ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-21.txt With a few exceptions noted below, the changes in going from version 20 to version 21 look OK to me. I didn't catch these issues in the pre-submission discussion because I don't regularly monitor this list; sorry about that. Anyway, here are the complaints: - Typo in isisSysLevelSetOverloadUntil DESCRIPTION clause: OLD: If isisSysLevelSetOverload is false, the system clears the overload bit when isisSysLevelSetOverloadUntil jave elapsed, if the system has not run out of memory." NEW: If isisSysLevelSetOverload is false, the system clears the overload bit when isisSysLevelSetOverloadUntil seconds have elapsed, if the system has not run out of memory." - The DESCRIPTION clauses for the objects isisCircLastUpTime and isisISAdjLastUpTime are now inconsistent with the SYNTAX values. What has happened is that these objects are now of type TimeStamp, and so are values of sysUpTime (see RFC 2579), which has units of 1/100 of a second since the last re-initialization of the network management portion of the system (RFC 3418). However, the DESCRIPTION clauses say that the xyzLastUpTime objects represent the "number of seconds since system startup" that the relevent event occurred. Possible remedies are: (a) re-instate the version 20 SYNTAX of Unsigned32 in both definitions; (b) change the phrase "number of seconds since system startup" to "number of hundredths of a second since the network management portion of the system was last re-initialized" in both definitions. These are the only MIB Doctor issues that I personally have with the draft. However, I would like to say that Joan Cucchiara's suggestion to change the SYNTAX of isisCircIfIndex from InterfaceIndex to InterfaceIndexOrZero is the correct thing to do _if_ it is agreed that there may be circuits for which there is no corresponding IfEntry. Regards, Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg