From isis-wg-bounces@ietf.org Thu Jun 3 17:12:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17792 for ; Thu, 3 Jun 2004 17:12:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVyUh-0001dc-A1; Thu, 03 Jun 2004 16:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVyHN-0005ts-PC; Thu, 03 Jun 2004 15:53:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08408; Thu, 3 Jun 2004 15:53:31 -0400 (EDT) Message-Id: <200406031953.PAA08408@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 03 Jun 2004 15:53:31 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-15.txt 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: , 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-15.txt Pages : 91 Date : 2004-6-3 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental 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 [1]. 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-15.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-15.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-15.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: <2004-6-3154256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-3154256.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Tue Jun 15 18:03:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20804 for ; Tue, 15 Jun 2004 18:03:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaLyU-0005it-HM; Tue, 15 Jun 2004 18:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaLra-00048a-Ck for isis-wg@megatron.ietf.org; Tue, 15 Jun 2004 17:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19376 for ; Tue, 15 Jun 2004 17:52:59 -0400 (EDT) From: jcucchiara@mindspring.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaLrY-0002qc-E0 for isis-wg@ietf.org; Tue, 15 Jun 2004 17:53:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaKBS-0005jK-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 16:05:27 -0400 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1BaJJ3-0006XG-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 15:09:14 -0400 Received: from wamui09.slb.atl.earthlink.net ([192.168.167.47]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BaJJ0-0003hT-00; Tue, 15 Jun 2004 15:09:10 -0400 Message-ID: <2828073.1087326550162.JavaMail.root@wamui09.slb.atl.earthlink.net> Date: Tue, 15 Jun 2004 15:09:03 -0400 (EDT) To: jparker@axiowave.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org Subject: [Isis-wg] questions on draft-ietf-isis-wg-mib-15.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jcucchiara@mindspring.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Jeff, I had some questions/comments on the ISIS-MIB. I do apologize as I realize these comments appear late in the life of the MIB. thanks, -Joan These are mostly in the order they appear in the MIB. * Is there really a need for the OBJECT-IDENTITY part. These are not really used as OBJECT-IDENTITY's, so think that using an OBJECT-IDENTIFIER is probably more appropriate. * The TC "SupportedProtocol" includes iso8473(129) and the beginning of this MIB says it is for ipv6 and ipv4, so was wondering why this included here? If so, then maybe the only needed TC would be from the INET-ADDRESS-MIB (InetAddressType) and conformance statements could be used to support a subset such as { unknown(0), ipv4(1), and ipv6(2) } * isisSysVersion is an SnmpAdminString and it would be easier for the Network Management apps if this were an enum such as INTEGER { unknown(0), one(1) } * (related to the comment about the TC "SupportedProtocols" above) Could cnIetfIsisSysProtSuppProtocol have a conformance statement such that only ipv4 and ipv6 are supported and iso8473(129) is not supported? * since the isisSys is no longer a table, think that removing the word Entry from these objects would be better, as they are now scalars. so isisSysEntry could be isisSysObjects Also, some of the descriptions refer to "this instance" and maybe this could be changed to say, the instance of ISIS on this router. * is isisSysLogAdjacencyChanges part of the protocol? Usually objects like these are left for enterprise MIBs for example, I worked on enterprise MIBs which have all these sort of logging options in one MIB instead of spread in various protocol MIBs. Can this object be removed? * isisSysNextCircIndex could be moved to just prior to the isisCircTable and become part of the isisCircObjects rather than with the isisSysObjects. Also, from an implementation point, the IndexInteger and IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) are easier to implement so would prefer those TC rather than the TestAndIncr TC. * Now that these system Objects are scalars, you probably don't need the cnIetfIsisSysExistState scalar. * could isisCircIfIndex be InterfaceIndex ? * could isisCircIfSubIndex be InterfaceIndexOrNull (or at least these should start with 1 which is the minimum value for ifIndex) * could isisCircSmallHellos appear in the conformance statement as optional, it doesn't seem like this feature is part of ISIS * MAJOR comment on the following Notifications: Since the agent needs to keep track of sources for a bunch of situations which trigger notifications, it might be better to have a table which tracks this, and configurable threshold values such that if these occur from a source, that these can be tracked back to the source. My point is that if the agent is supposed to track these sources internally as to only send a notification after one occurance, then why not make this table of sources visable and then have thresholds with defVal of 1 which will trigger the notification. With a external table there is more info and this table can be polled by NMS. (My point is that if the agent is already tracking this information internally, then maybe adding a table to the MIB will allow this information to be external and visable to operator/NMS. I would also encourage that these Notifications and this external table be made optional in the Conformance, as this is really a lot of work for not much gain that I could see. In other words, it's lots of overhead for the router to track all these situations which seem sort of unlikely to occur. The notifications which could possibly benefit from such a table are: - isisIDLenMismatch - isisMaxAreaAddressesMismatch - isisAuthenticationTypeFailure - isisAuthenticationFailure - isisVersionSkew - isisAreaMismatch - isisRejectedAdjacency - isisLSPTooLargeToPropagate - isisOrigLSPBuffSizeMismatch - isisProtocolsSupportedMismatch the beginning of this MIB says it is for ipv6 and ipv4, so was wondering why this included here? If so, then maybe the only needed TC would be from the INET-ADDRESS-MIB (InetAddressType) and conformance statements could be used to support a subset such as { unknown(0), ipv4(1), and ipv6(2) } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jun 15 20:59:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28819 for ; Tue, 15 Jun 2004 20:59:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaOiN-0006Qi-W6; Tue, 15 Jun 2004 20:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaOdC-0002hb-MB for isis-wg@megatron.ietf.org; Tue, 15 Jun 2004 20:50:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28480 for ; Tue, 15 Jun 2004 20:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaOdB-000745-04 for isis-wg@ietf.org; Tue, 15 Jun 2004 20:50:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaLL1-0006Ks-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 17:19:26 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1BaJrW-0003Mp-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 15:44:50 -0400 Message-ID: From: Jeff Parker To: "'jcucchiara@mindspring.com'" , Jeff Parker Date: Tue, 15 Jun 2004 15:44:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: isis-wg@ietf.org Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Thanks for the thoughtful review. > These are mostly in the order they appear in the MIB. > > * Is there really a need for the > OBJECT-IDENTITY part. These are not really used > as OBJECT-IDENTITY's, so think that using > an OBJECT-IDENTIFIER is probably more appropriate. Will investigate the difference. > * The TC "SupportedProtocol" includes iso8473(129) and > > the beginning of this MIB says it is for ipv6 and > ipv4, so was wondering why this included here? > If so, then maybe the only needed TC would be > from the INET-ADDRESS-MIB (InetAddressType) > and conformance statements could be used to support > a subset such as { unknown(0), ipv4(1), and ipv6(2) } IS-IS isn't really ours to modify: we just get to play with it. IS-IS was designed to route iso8473 and the like. So while the IETF isn't interested in iso8473, ISO is. > * isisSysVersion is an SnmpAdminString and it would be > easier for the Network Management apps > if this were an enum such as > > INTEGER { > unknown(0), > one(1) > } Fine > * (related to the comment about the TC "SupportedProtocols" above) > Could cnIetfIsisSysProtSuppProtocol have a conformance > statement such that only ipv4 and ipv6 are supported > and iso8473(129) is not supported? See above > * since the isisSys is no longer a table, think that > removing the word Entry from these objects would > be better, as they are now scalars. > > so isisSysEntry could be isisSysObjects > Also, some of the descriptions refer to "this instance" and > maybe this could be changed to say, the instance of ISIS on > this router. Will try to address > * is isisSysLogAdjacencyChanges part of the protocol? > Usually objects like these are left for enterprise MIBs > for example, I worked on enterprise MIBs which have all these > sort of logging options in one MIB instead of spread in > various protocol MIBs. Can this object be removed? If there are no objections > * isisSysNextCircIndex could be moved to just prior to the > isisCircTable and become part of the isisCircObjects > rather than with the isisSysObjects. I'm not sure I follow. The Circ Table has an entry for each circuit. The NextCircIndex is a system wide item. There is no system wide Circ specific table. Where are you suggesting this be placed? > Also, from an implementation point, the IndexInteger and > IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) > are easier to implement so would prefer those TC rather > than the TestAndIncr TC. Comments from others? > > * Now that these system Objects are scalars, you probably > don't need the cnIetfIsisSysExistState scalar. Good point > * could isisCircIfIndex be InterfaceIndex ? It could, and it probably is the same thing. But don't you think there is some value in the naming convention used here? > * could isisCircIfSubIndex be > InterfaceIndexOrNull > (or at least these should start with 1 which > is the minimum value for ifIndex) This isn't really an ifIndex: it was added by request for some sub-interface identifiers. > * could isisCircSmallHellos appear in the > conformance statement as optional, it doesn't seem like > this feature is part of ISIS Padded hellos were an important part of the protocol at one time. This provides a way for the administrator to tell if the other side is not padding, or really thinks that the MTU is 36. > * MAJOR comment on the following Notifications: > > Since the agent needs to keep track of > sources for a bunch of situations which trigger > notifications, it might be better to have a table > which tracks this, and configurable threshold values such > that if these occur from a source, that these can > be tracked back to the source. My point is that if > the agent is supposed to track these sources internally > as to only send a notification after one occurance, then why > not make this > table of sources visable and then have thresholds with > defVal of 1 which will trigger the notification. With a > external table > there is more info and this table can > be polled by NMS. (My point is that if the agent is already tracking > this information internally, then maybe adding a table to the MIB > will allow this information to be external and visable to > operator/NMS. I may have stepped over the line with the requirement that these be damped. However, I am uncomfortable requireding a specific damping strategy. > I would also encourage that these Notifications and > this external table be made optional in the Conformance, as this is > really a lot of work for not much gain that I could see. > In other words, it's lots of overhead for the router to track > all these > situations which seem sort of unlikely to occur. I agree that there is some overhead here. I will try to reword so that a bitmap per interface would suffice for conformance. > The notifications which could possibly benefit from > such a table are: > - isisIDLenMismatch > - isisMaxAreaAddressesMismatch > - isisAuthenticationTypeFailure > - isisAuthenticationFailure > - isisVersionSkew > - isisAreaMismatch > - isisRejectedAdjacency > - isisLSPTooLargeToPropagate > - isisOrigLSPBuffSizeMismatch > - isisProtocolsSupportedMismatch > > > > the beginning of this MIB says it is for ipv6 and > ipv4, so was wondering why this included here? > If so, then maybe the only needed TC would be > from the INET-ADDRESS-MIB (InetAddressType) > and conformance statements could be used to support > a subset such as { unknown(0), ipv4(1), and ipv6(2) } This is here so that contact with a router that is only supporting iso8473 can be documented and tracked. - 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 16 01:11:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23527 for ; Wed, 16 Jun 2004 01:11:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSbr-00046e-5q; Wed, 16 Jun 2004 01:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba1Yw-0001fn-Er for isis-wg@megatron.ietf.org; Mon, 14 Jun 2004 20:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14891 for ; Mon, 14 Jun 2004 20:12:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba1Yu-0001ik-P4 for isis-wg@ietf.org; Mon, 14 Jun 2004 20:12:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba1Xz-0001R3-00 for isis-wg@ietf.org; Mon, 14 Jun 2004 20:11:28 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Ba1XI-0000qO-00 for isis-wg@ietf.org; Mon, 14 Jun 2004 20:10:44 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i5F0AFm6011428 for ; Mon, 14 Jun 2004 17:10:15 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i5F0AE24011425 for ; Mon, 14 Jun 2004 17:10:14 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 14 Jun 2004 17:10:14 -0700 (PDT) From: Kireeti Kompella To: isis-wg@ietf.org In-Reply-To: <200405121412.KAA06827@ietf.org> Message-ID: <20040614170235.H11354@kummer.juniper.net> References: <200405121412.KAA06827@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 X-Mailman-Approved-At: Wed, 16 Jun 2004 01:02:40 -0400 Subject: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Wed, 12 May 2004 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 : TLV for Experimental Use > Author(s) : P. Christian > Filename : draft-ietf-isis-experimental-tlv-03.txt > Pages : 6 > Date : 2004-5-6 > > This document defines a TLV that may be used by any individual, > company or other organisation for experimental extensions to the > IS-IS routing protocol, and defines the format of the TLV. I have a request, if I may. Either change the "discriminator" from an OUI to an SNMP Enterprise Code (http://www.iana.org/assignments/enterprise-numbers), OR Have a parallel experimental TLV (251?) that uses Enterprise Codes. Everything else is exactly the same, except (of course) the Enterprise Code is 4 octets. Thanks, Kireeti. ------- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 16 04:41:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22921 for ; Wed, 16 Jun 2004 04:41:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaVN9-0005VC-It; Wed, 16 Jun 2004 04:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaT6v-0005oy-Ss for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 01:37:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29064 for ; Wed, 16 Jun 2004 01:37:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaT6t-0000Ml-O8 for isis-wg@ietf.org; Wed, 16 Jun 2004 01:37:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaPcI-00054g-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 21:53:32 -0400 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1BaLko-0001h4-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 17:46:02 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i5FNvcuH069304 for ; Tue, 15 Jun 2004 16:57:38 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5FLjQd1003110 for ; Tue, 15 Jun 2004 14:45:26 -0700 (PDT) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 Jun 2004 14:45:26 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <683AECDA-7C59-11D8-9354-00039303E9E2@procket.com> References: <683AECDA-7C59-11D8-9354-00039303E9E2@procket.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5084420E-BF15-11D8-AD86-00039303E9E2@procket.com> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] ISIS to go standards track. Date: Tue, 15 Jun 2004 14:45:27 -0700 To: ISIS-WG (E-mail) X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 15 Jun 2004 21:45:26.0649 (UTC) FILETIME=[11D6A690:01C45322] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit > The next step will be to determine which documents should be placed on > the standards track. This decision should be based on (1) and (2) from > above, and the ISO agreement RFC 3563 > (http://www.ietf.org/rfc/rfc3563.txt). We will do this in a separate > thread. Alex proposed to me an initial set of documents which we might consider for taking down the STDs track. RFC 1195 (IPv4)-- Already PS RFC 2966 (Two-level prefix distribution) draft-ietf-isis-wg-mib-13.txt draft-ietf-isis-traffic-05.txt draft-ietf-isis-ipv6-05.txt draft-ietf-isis-gmpls-extensions-19.txt RFC 3787 (IP Interop) He also points out that in taking these documents down standards track we may want to consider combining RFC 1195, RFC 2966, traffic, and RFC 3787 into a single standards track document. This would leave the MIB, IPv6 and GMPLS documents to go STDs track standalone. I'd like to open this up for discussion at this point. Thanks, Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 16 05:41:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23043 for ; Wed, 16 Jun 2004 05:41:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaWmw-0001YO-Eo; Wed, 16 Jun 2004 05:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaTPG-0003RC-Fu for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 01:56:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03650 for ; Wed, 16 Jun 2004 01:56:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaTPE-0003kc-BF for isis-wg@ietf.org; Wed, 16 Jun 2004 01:56:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaQOm-0001rb-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 22:43:40 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1BaLzE-0004J1-00 for isis-wg@ietf.org; Tue, 15 Jun 2004 18:00:56 -0400 Message-ID: From: Jeff Parker To: "'jcucchiara@mindspring.com'" , Jeff Parker Date: Tue, 15 Jun 2004 18:00:17 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C45324.24AE7E80" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: isis-wg@ietf.org Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt 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: , 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. ------_=_NextPart_000_01C45324.24AE7E80 Content-Type: text/plain; charset="iso-8859-1" Joan - Here is a list of diffs for the changes you proposed, modulo my reservations expressed in the previous mail. I will also send you a new version for your review: I'd be happy to send to other interested parties - jeff parker > Hi Jeff, > > I had some questions/comments on the ISIS-MIB. I do > apologize as I realize these comments appear late > in the life of the MIB. > > thanks, > -Joan > > > These are mostly in the order they appear in the MIB. > > * Is there really a need for the > OBJECT-IDENTITY part. These are not really used > as OBJECT-IDENTITY's, so think that using > an OBJECT-IDENTIFIER is probably more appropriate. > > > * The TC "SupportedProtocol" includes iso8473(129) and > > the beginning of this MIB says it is for ipv6 and > ipv4, so was wondering why this included here? > If so, then maybe the only needed TC would be > from the INET-ADDRESS-MIB (InetAddressType) > and conformance statements could be used to support > a subset such as { unknown(0), ipv4(1), and ipv6(2) } > > > * isisSysVersion is an SnmpAdminString and it would be > easier for the Network Management apps > if this were an enum such as > > > INTEGER { > unknown(0), > one(1) > } > > > > > * (related to the comment about the TC "SupportedProtocols" above) > Could cnIetfIsisSysProtSuppProtocol have a conformance > statement such that only ipv4 and ipv6 are supported > and iso8473(129) is not supported? > > > * since the isisSys is no longer a table, think that > removing the word Entry from these objects would > be better, as they are now scalars. > > > so isisSysEntry could be isisSysObjects > Also, some of the descriptions refer to "this instance" and > maybe this could be changed to say, the instance of ISIS on > this router. > > * is isisSysLogAdjacencyChanges part of the protocol? > Usually objects like these are left for enterprise MIBs > for example, I worked on enterprise MIBs which have all these > sort of logging options in one MIB instead of spread in > various protocol MIBs. Can this object be removed? > > > * isisSysNextCircIndex could be moved to just prior to the > isisCircTable and become part of the isisCircObjects > rather than with the isisSysObjects. > > > Also, from an implementation point, the IndexInteger and > IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) > are easier to implement so would prefer those TC rather > than the TestAndIncr TC. > > > > > * Now that these system Objects are scalars, you probably > don't need the cnIetfIsisSysExistState scalar. > > > * could isisCircIfIndex be InterfaceIndex ? > > > * could isisCircIfSubIndex be > InterfaceIndexOrNull > (or at least these should start with 1 which > is the minimum value for ifIndex) > > > * could isisCircSmallHellos appear in the > conformance statement as optional, it doesn't seem like > this feature is part of ISIS > > > > > * MAJOR comment on the following Notifications: > > > Since the agent needs to keep track of > sources for a bunch of situations which trigger > notifications, it might be better to have a table > which tracks this, and configurable threshold values such > that if these occur from a source, that these can > be tracked back to the source. My point is that if > the agent is supposed to track these sources internally > as to only send a notification after one occurance, then why > not make this > table of sources visable and then have thresholds with > defVal of 1 which will trigger the notification. With a > external table > there is more info and this table can > be polled by NMS. (My point is that if the agent is already tracking > this information internally, then maybe adding a table to the MIB > will allow this information to be external and visable to > operator/NMS. > > > I would also encourage that these Notifications and > this external table be made optional in the Conformance, as this is > really a lot of work for not much gain that I could see. > In other words, it's lots of overhead for the router to track > all these > situations which seem sort of unlikely to occur. > > > The notifications which could possibly benefit from > such a table are: > - isisIDLenMismatch > - isisMaxAreaAddressesMismatch > - isisAuthenticationTypeFailure > - isisAuthenticationFailure > - isisVersionSkew > - isisAreaMismatch > - isisRejectedAdjacency > - isisLSPTooLargeToPropagate > - isisOrigLSPBuffSizeMismatch > - isisProtocolsSupportedMismatch > > > > the beginning of this MIB says it is for ipv6 and > ipv4, so was wondering why this included here? > If so, then maybe the only needed TC would be > from the INET-ADDRESS-MIB (InetAddressType) > and conformance statements could be used to support > a subset such as { unknown(0), ipv4(1), and ipv6(2) } > > > ------_=_NextPart_000_01C45324.24AE7E80 Content-Type: text/plain; name="diff.txt" Content-Disposition: attachment; filename="diff.txt" Content-Transfer-Encoding: quoted-printable 9c9 < TEXTUAL-CONVENTION, RowStatus, TruthValue, TestAndIncr --- > TEXTUAL-CONVENTION, RowStatus, TruthValue 11,13c11,12 < MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Integer32,=20 < Unsigned32, Counter32, experimental, TimeTicks, < NOTIFICATION-TYPE --- > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32,=20 > Counter32, experimental, TimeTicks, NOTIFICATION-TYPE 18a18,19 > IndexIntegerNextFree > FROM DIFFSERV-MIB 58,62c59,60 < isisSystem OBJECT-IDENTITY < STATUS current < DESCRIPTION < "The object describes system wide attributes." < ::=3D { isisObjects 1 } --- > -- System wide attributes. > isisSystem OBJECT IDENTIFIER ::=3D { isisObjects 1 } 64,69c62,63 < isisSysLevel OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < the domain or with the area." < ::=3D { isisObjects 2 } --- > -- Attributes associated with the domain or with the area. > isisSysLevel OBJECT IDENTIFIER ::=3D { isisObjects 2 } 71,76c65,66 < isisCirc OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < one Circuit" < ::=3D { isisObjects 3 } --- > -- Attributes associated with one Circuit > isisCirc OBJECT IDENTIFIER ::=3D { isisObjects 3 } 78,83c68,69 < isisCircLevelValues OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < area or domain relevant within a Circuit." < ::=3D { isisObjects 4 } --- > -- Attributes associated with area or domain relevant within a = Circuit. > isisCircLevelValues OBJECT IDENTIFIER ::=3D { isisObjects 4 } 85,89c71,72 < isisCounters OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object collects system and circuit counters" < ::=3D { isisObjects 5 } --- > -- System and circuit counters. > isisCounters OBJECT IDENTIFIER ::=3D { isisObjects 5 } 91,96c74,75 < isisISAdj OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with an < adjacent Protocol Peer." < ::=3D { isisObjects 6 } --- > -- Attributes associated with an adjacent Protocol Peer. > isisISAdj OBJECT IDENTIFIER ::=3D { isisObjects 6 } 98,103d76 < isisReachAddr OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < a configured address" < ::=3D { isisObjects 7 } 105,111c78,79 < isisIPReachAddr OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < IP routes learned by configuration or through another < protocol." < ::=3D { isisObjects 8 } --- > -- Attributes associated with a configured address. > isisReachAddr OBJECT IDENTIFIER ::=3D { isisObjects 7 } 113,118c81,83 < isisLSPDataBase OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes the collection of Link State PDUs < known to the system." < ::=3D { isisObjects 9 } --- > -- Attributes associated with IP routes learned by=20 > -- configuration or through another protocol. > isisIPReachAddr OBJECT IDENTIFIER ::=3D { isisObjects 8 } 120,124c85,89 < isisNotification OBJECT-IDENTITY < STATUS current < DESCRIPTION < "Objects included in Notifications." < ::=3D { isisObjects 10 } --- > -- The collection of Link State PDUs known to the Intermediate System > isisLSPDataBase OBJECT IDENTIFIER ::=3D { isisObjects 9 } >=20 > -- Objects included in Notifications. > isisNotification OBJECT IDENTIFIER ::=3D { isisObjects 10 } 302c267 < isisSysEntry OBJECT IDENTIFIER ::=3D { isisSystem 1 } --- > isisSysObject OBJECT IDENTIFIER ::=3D { isisSystem 1 } 305c270,274 < SYNTAX SnmpAdminString --- > SYNTAX INTEGER > { > unknown(0), > one(1) > } 309,310c278,279 < "The version number of the IS-IS protocol which this < instance implements." --- > "The version number of the IS-IS protocol that > is implemented." 312,313c281,282 < DEFVAL { "1" } < ::=3D { isisSysEntry 1 } --- > DEFVAL { one } > ::=3D { isisSysObject 1 } 325,326c294,295 < "The type of this instance of the Integrated < IS-IS protocol. This object follows the --- > "At which levels is the Intermediate System > running? This object follows the 330c299 < ::=3D { isisSysEntry 2 } --- > ::=3D { isisSysObject 2 } 337,338c306,307 < "The ID for this instance of the Integrated IS-IS < protocol. This value is appended to each of the --- > "The ID for this Intermediate System. > This value is appended to each of the 346c315 < ::=3D { isisSysEntry 3 } --- > ::=3D { isisSysObject 3 } 358c327 < ::=3D { isisSysEntry 4 } --- > ::=3D { isisSysObject 4 } 367c336 < by this instance of the protocol. This object follows --- > by this Intermediate System. This object follows 374c343 < ::=3D { isisSysEntry 5 } --- > ::=3D { isisSysObject 5 } 387c356 < ::=3D { isisSysEntry 6 } --- > ::=3D { isisSysObject 6 } 400c369 < ::=3D { isisSysEntry 7 } --- > ::=3D { isisSysObject 7 } 407,411c376,379 < "The administrative state of this instance of the < Integrated IS-IS protocol. Setting this object to the < value 'on' when its current value is 'off' enables=20 < operation of this instance of the Integrated IS-IS=20 < protocol." --- > "The administrative state of this Intermediate=20 > System. Setting this object to the value 'on'=20 > when its current value is 'off' enables=20 > the Intermediate System." 413,423c381 < ::=3D { isisSysEntry 8 } <=20 < isisSysLogAdjacencyChanges OBJECT-TYPE < SYNTAX TruthValue < MAX-ACCESS read-write < STATUS current < DESCRIPTION < "If true, causes IS-IS to generate a log message when an < IS-IS adjacency changes state (up or down)." < DEFVAL { false } < ::=3D { isisSysEntry 9 } --- > ::=3D { isisSysObject 8 } 426c384 < SYNTAX TestAndIncr --- > SYNTAX IndexIntegerNextFree 431,441c389,390 < isisCircIndex as described in 'Textual < Conventions for SNMPv2'. The network manager < reads this object, and then writes the value < back as the isisCircIndex in a SET that creates < a new instance of isisCircEntry. If the SET < fails with the code 'inconsistentValue', then < the process must be repeated; If the SET succeeds, < then the object is incremented, and the new < isisCircuit is created according to the manager's < directions." < ::=3D { isisSysEntry 10 } --- > new isisCircIndex." > ::=3D { isisSysObject 9 } 450c399 < ::=3D { isisSysEntry 11 } --- > ::=3D { isisSysObject 10 } 463c412 < ::=3D { isisSysEntry 12 } --- > ::=3D { isisSysObject 11 } 481,493c430 < ::=3D { isisSysEntry 13 } <=20 < isisSysExistState OBJECT-TYPE < SYNTAX RowStatus < MAX-ACCESS read-write < STATUS current < DESCRIPTION < "The state of the IS-IS router. Turning this to < state 'destroy' forces the router to forget all < the current configuration. Setting the state to < 'notInService' stops protocol processing, but < retains the configuration." < ::=3D { isisSysEntry 14 } --- > ::=3D { isisSysObject 12 } 497c434 < -- for each instance of the Integrated IS-IS protocol. --- > -- for this Intermediate System. 499,502c436,438 < -- is active must be present for each active instance of < -- the protocol The maximum number of rows in this table for < -- each instance of the protocol for which the object < -- isisManAreaAddrExistState has the value active is 3 --- > -- is active must be present. The maximum number of rows=20 > -- in this table for for which the object > -- isisManAreaAddrExistState has the value active is 3. 557c493 < for this instance of the IS-IS protocol is 'on', and an --- > for this Intermediate System is 'on', and an 560,561c496,497 < isisManAreaAddrEntry in state 'active' for this instance = < of the IS-IS protocol should return inconsistentValue." --- > isisManAreaAddrEntry in state 'active' for this=20 > Intermediate System should return inconsistentValue." 577,578c513,514 < instance of the protocol from Intermediate Systems which < are reachable via Level 1 routing." --- > Intermediate System from other Intermediate Systems=20 > which are reachable via Level 1 routing." 588,589c524 < Level 1 LSP received by this instance of the IS-IS < protocol." --- > Level 1 LSP received by this Intermediate System."=20 605c540 < this instance of the IS-IS protocol." --- > this Intermediate System."=20 612,613c547,548 < -- configured set of protocols supported by each < -- instance of the Integrated IS-IS protocol. --- > -- configured set of protocols supported by this > -- Intermediate System. 621,622c556 < protocols supported by each instance of the Integrated < IS-IS protocol." --- > protocols supported by this Intermediate System." 630,631c564,565 < "Each entry contains one protocol supported by an < instance of the Integrated IS-IS protocol." --- > "Each entry contains one protocol supported by=20 > this Intermediate System." 667,668c601 < -- addresses manually configured for each instance of < -- IP Integrated IS-IS on the system. --- > -- addresses manually configured for the Intermediate System. 974c907 < this instance of the protocol at this level. --- > this Intermediate System at this level. 989c922 < by this instance of the protocol. This object=20 --- > by this Intermediate System. This object 1075,1076c1008,1009 < "The table of circuits used by each instance of < Integrated IS-IS on this system." --- > "The table of circuits used by this=20 > Intermediate System." 1129c1062 < instance of the IS-IS protocol. This object follows --- > Intermediate System. This object follows 1564,1565c1497 < "System wide counters for one instance of the IS-IS < protocol on the system." --- > "System wide counters for this Intermediate System." 1642c1574 < by this instance of the protocol." --- > by this Intermediate System." 1652c1584 < instance of the protocol." --- > Intermediate System." 1749,1750c1681,1682 < "Circuit specific counters for one instance of the IS-IS < protocol on the system." --- > "Circuit specific counters for this=20 > Intermediate System." 3272,3275c3204 < PDUs received from what seem to be the same source. < This decision is up to the agent to make, and may < be based on the circuit or on some MAC level < information." --- > PDUs received on the same circuit." 3297c3226 < PDUs received from what seem to be the same source." --- > PDUs received from the same circuit." 3353c3282 < PDUs received from what seem to be the same source." --- > PDUs received from the same circuit." 3373c3302 < PDUs received from what seem to be the same source." --- > PDUs received from the same circuit." 3395,3398c3324 < PDUs received from what seem to be the same source. < This decision is up to the agent to make, and may < be based on the circuit or on some MAC level < information." --- > PDUs received from the same circuit." 3418,3421c3344 < PDUs received from what seem to be the same source. < This decision is up to the agent to make, and may < be based on the circuit or on some MAC level < information." --- > PDUs received from the same circuit." 3439c3362 < PDUs received from the same source." --- > PDUs received from the circuit." 3457c3380 < PDUs received from the same source." --- > PDUs received from the same circuit." 3481c3404 < PDUs received from the same source." --- > PDUs received from the same circuit." 3506c3429 < PDUs received from the same source." --- > PDUs received from the same circuit." 3611d3533 < isisSysLogAdjacencyChanges, 3613d3534 < isisSysExistState, ------_=_NextPart_000_01C45324.24AE7E80 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_000_01C45324.24AE7E80-- From isis-wg-bounces@ietf.org Wed Jun 16 12:34:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17638 for ; Wed, 16 Jun 2004 12:34:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacsU-0000XH-QS; Wed, 16 Jun 2004 12:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacU2-0007Xs-7X for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 11:37:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11179 for ; Wed, 16 Jun 2004 11:37:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacTy-0003Q0-IF for isis-wg@ietf.org; Wed, 16 Jun 2004 11:37:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Babot-0004S3-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 10:55:21 -0400 Received: from mx4.tellabs.com ([204.154.129.57] helo=tellabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bab0c-0004FS-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 10:03:22 -0400 Received: from ([172.23.207.12]) by mx4.tellabs.com with ESMTP ; Wed, 16 Jun 2004 09:02:14 -0500 Received: from localhost (root@localhost) by mailw02.hq.tellabs.com with ESMTP (8.11.1/8.7.1) id i5GE2FM26089; Wed, 16 Jun 2004 09:02:15 -0500 (CDT) X-OpenMail-Hops: 1 Date: Wed, 16 Jun 2004 09:02:15 -0500 Message-Id: Subject: RE: Re: [Isis-wg] ISIS to go standards track. MIME-Version: 1.0 From: Jonathan.Sadler@tellabs.com TO: chopps@procket.com, isis-wg@ietf.org Content-Disposition: inline ;Creation-Date="Wed, 16 Jun 2004 09:02:15 -0500" Content-Type: text/plain; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Chris - I know that a liaison was issued by ITU Q14/15 requesting two documents be given priority. The documents in the liaison were: RFC 2966 RFC 3373 My understanding is that RFC 3373 is a change to the base IS-IS spec, so under the agreement with JTC1 would require fast track processing in JTC1 before it could go to standards track. Since JTC1 SC6's next meeting (November 2004) is in Orlando, it may be easy to accomplish this in short order. I can look into the details necessary to accomplish this if you'd like. You can find the ITU liaison at: ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/isis/index.html Thanks, Jonathan Sadler -----Original Message----- From: chopps@procket.com [mailto:chopps@procket.com] Sent: Tuesday, June 15, 2004 4:45 PM To: isis-wg@ietf.org Subject: Re: [Isis-wg] ISIS to go standards track. > The next step will be to determine which documents should be placed on > the standards track. This decision should be based on (1) and (2) from > above, and the ISO agreement RFC 3563 > (http://www.ietf.org/rfc/rfc3563.txt). We will do this in a separate > thread. Alex proposed to me an initial set of documents which we might consider for taking down the STDs track. RFC 1195 (IPv4)-- Already PS RFC 2966 (Two-level prefix distribution) draft-ietf-isis-wg-mib-13.txt draft-ietf-isis-traffic-05.txt draft-ietf-isis-ipv6-05.txt draft-ietf-isis-gmpls-extensions-19.txt RFC 3787 (IP Interop) He also points out that in taking these documents down standards track we may want to consider combining RFC 1195, RFC 2966, traffic, and RFC 3787 into a single standards track document. This would leave the MIB, IPv6 and GMPLS documents to go STDs track standalone. I'd like to open this up for discussion at this point. Thanks, Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ----------------------------------------- ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 16 12:44:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19303 for ; Wed, 16 Jun 2004 12:44:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BadCe-0001AH-Hp; Wed, 16 Jun 2004 12:23:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bache-00043g-SI for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 11:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12981 for ; Wed, 16 Jun 2004 11:51:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bachb-0005mT-6r for isis-wg@ietf.org; Wed, 16 Jun 2004 11:51:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BacAb-0000AW-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 11:17:46 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BabNf-00004M-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 10:27:11 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2004 10:32:05 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5GEQUc3015840; Wed, 16 Jun 2004 10:26:31 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-206-107.cisco.com [64.102.206.107]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id AZZ27929; Wed, 16 Jun 2004 07:26:30 -0700 (PDT) Message-Id: <4.3.2.7.2.20040616101215.02706990@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Jun 2004 10:27:06 -0400 To: Kireeti Kompella , isis-wg@ietf.org From: Jeff Learman Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <20040614170235.H11354@kummer.juniper.net> References: <200405121412.KAA06827@ietf.org> <200405121412.KAA06827@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org It would be a bad idea to change the current interpretation of this TLV, since it could lead to ambiguities. It might also be a bad idea to assign a new TLV number for this; how many different numbering plans are there we might be asked to accommodate in the future? One possibility, albeit "wasting" 3 octets pre TLV, would be to assign an org ID for this purpose (". We could also choose a value with the "local" bit set, which would never be assigned as a valid OUI. We could assign any number of these "local OUIs" to identify any future numbering plans. The alternative would be to choose a new TLV value, where the first octet of the value identifies the numbering plan, something like this: 0 - OUI (treat TLV as synonymous to original TLV and same OUI) 1 - SNMP Enterprise ID This would provide a more concise format for future numbering plans. First we'd need to find out if there's enough support for this idea to justify the change. I have no opinion on that. Regards, Jeff At 08:10 PM 6/14/2004, Kireeti Kompella wrote: >On Wed, 12 May 2004 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 : TLV for Experimental Use >> Author(s) : P. Christian >> Filename : draft-ietf-isis-experimental-tlv-03.txt >> Pages : 6 >> Date : 2004-5-6 >> >> This document defines a TLV that may be used by any individual, >> company or other organisation for experimental extensions to the >> IS-IS routing protocol, and defines the format of the TLV. > >I have a request, if I may. > >Either change the "discriminator" from an OUI to an SNMP Enterprise >Code (http://www.iana.org/assignments/enterprise-numbers), > >OR > >Have a parallel experimental TLV (251?) that uses Enterprise Codes. > >Everything else is exactly the same, except (of course) the Enterprise >Code is 4 octets. > >Thanks, >Kireeti. >------- > >_______________________________________________ >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 Wed Jun 16 19:57:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02492 for ; Wed, 16 Jun 2004 19:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bak9m-0005ed-2v; Wed, 16 Jun 2004 19:49:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bajww-0006n7-Js for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 19:36:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01549 for ; Wed, 16 Jun 2004 19:36:09 -0400 (EDT) From: jcucchiara@mindspring.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bajws-0001SL-9x for isis-wg@ietf.org; Wed, 16 Jun 2004 19:36:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bajw5-00013w-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 19:35:18 -0400 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 1Bajv9-0000g5-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 19:34:19 -0400 Received: from h-67-100-203-34.cmbrmaor.dynamic.covad.net ([67.100.203.34] helo=jluciani-laptop) by hall.mail.mindspring.net with smtp (Exim 3.33 #1) id 1Bajv8-0000CZ-00; Wed, 16 Jun 2004 19:34:18 -0400 Message-Id: <3.0.1.32.20040616192706.012c0b38@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 16 Jun 2004 19:27:06 -0400 To: Jeff Parker , Jeff Parker In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Cc: isis-wg@ietf.org Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Jeff, A few responses inline...I saw the diff file and that looked good. Thank you for your quick response. At 03:44 PM 6/15/04 -0400, Jeff Parker wrote: >Thanks for the thoughtful review. > >> These are mostly in the order they appear in the MIB. >> >> * Is there really a need for the >> OBJECT-IDENTITY part. These are not really used >> as OBJECT-IDENTITY's, so think that using >> an OBJECT-IDENTIFIER is probably more appropriate. > >Will investigate the difference. > >> * The TC "SupportedProtocol" includes iso8473(129) and >> >> the beginning of this MIB says it is for ipv6 and >> ipv4, so was wondering why this included here? >> If so, then maybe the only needed TC would be >> from the INET-ADDRESS-MIB (InetAddressType) >> and conformance statements could be used to support >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } > >IS-IS isn't really ours to modify: we just get to play with >it. IS-IS was designed to route iso8473 and the like. >So while the IETF isn't interested in iso8473, ISO is. > Okay. Could this value be made optional in the Conformance Statement? >> * isisSysVersion is an SnmpAdminString and it would be >> easier for the Network Management apps >> if this were an enum such as >> > >> INTEGER { >> unknown(0), >> one(1) >> } > >Fine > >> * (related to the comment about the TC "SupportedProtocols" above) >> Could cnIetfIsisSysProtSuppProtocol have a conformance >> statement such that only ipv4 and ipv6 are supported >> and iso8473(129) is not supported? > >See above > >> * since the isisSys is no longer a table, think that >> removing the word Entry from these objects would >> be better, as they are now scalars. >> > >> so isisSysEntry could be isisSysObjects >> Also, some of the descriptions refer to "this instance" and >> maybe this could be changed to say, the instance of ISIS on >> this router. > >Will try to address > >> * is isisSysLogAdjacencyChanges part of the protocol? >> Usually objects like these are left for enterprise MIBs >> for example, I worked on enterprise MIBs which have all these >> sort of logging options in one MIB instead of spread in >> various protocol MIBs. Can this object be removed? > >If there are no objections > >> * isisSysNextCircIndex could be moved to just prior to the >> isisCircTable and become part of the isisCircObjects >> rather than with the isisSysObjects. > >I'm not sure I follow. The Circ Table has an entry for >each circuit. The NextCircIndex is a system wide item. >There is no system wide Circ specific table. > >Where are you suggesting this be placed? > I'm suggesting this be placed before the table that uses it. Admittedly this is a style issue. DIFFSERV-MIB has examples of this (you can grep on IndexIntegerNextFree and you'll see that the objects are actually prior to the table where it is used. >> Also, from an implementation point, the IndexInteger and >> IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) >> are easier to implement so would prefer those TC rather >> than the TestAndIncr TC. > >Comments from others? > >> >> * Now that these system Objects are scalars, you probably >> don't need the isisSysExistState scalar. > >Good point > >> * could isisCircIfIndex be InterfaceIndex ? > >It could, and it probably is the same thing. >But don't you think there is some value in the >naming convention used here? The range of Integer32 and InterfaceIndex differ because ifIndices do not have a value of zero. My preference would be to use InterfaceIndex from IF-MIB, but could you at least supply a range value? > >> * could isisCircIfSubIndex be >> InterfaceIndexOrNull >> (or at least these should start with 1 which >> is the minimum value for ifIndex) > >This isn't really an ifIndex: it was added by >request for some sub-interface identifiers. The DESCRIPTION makes it sound like an ifIndex, and name (use of "if") make it sound like an InterfaceIndex. Maybe a name change and clarifying the description would help. I don't have any idea of what value this is supposed to be except for some sublayer ifIndex. > >> * could isisCircSmallHellos appear in the >> conformance statement as optional, it doesn't seem like >> this feature is part of ISIS > >Padded hellos were an important part of the protocol at >one time. This provides a way for the administrator to >tell if the other side is not padding, or really thinks >that the MTU is 36. okay. > >> * MAJOR comment on the following Notifications: >> > >> Since the agent needs to keep track of >> sources for a bunch of situations which trigger >> notifications, it might be better to have a table >> which tracks this, and configurable threshold values such >> that if these occur from a source, that these can >> be tracked back to the source. My point is that if >> the agent is supposed to track these sources internally >> as to only send a notification after one occurance, then why >> not make this >> table of sources visable and then have thresholds with >> defVal of 1 which will trigger the notification. With a >> external table >> there is more info and this table can >> be polled by NMS. (My point is that if the agent is already tracking >> this information internally, then maybe adding a table to the MIB >> will allow this information to be external and visable to >> operator/NMS. > >I may have stepped over the line with the requirement that these >be damped. However, I am uncomfortable requireding a specific >damping strategy. > >> I would also encourage that these Notifications and >> this external table be made optional in the Conformance, as this is >> really a lot of work for not much gain that I could see. >> In other words, it's lots of overhead for the router to track >> all these >> situations which seem sort of unlikely to occur. > >I agree that there is some overhead here. >I will try to reword so that a bitmap per interface would >suffice for conformance. > Okay, thanks! From my perspective, I think the burden being put on the router is excessive for not very much gain (with regard to the notifications below). Making these optional in the Conformance would be my preference....Maybe others could relate what their experience is with these notifications? Thanks, -Joan >> The notifications which could possibly benefit from >> such a table are: >> - isisIDLenMismatch >> - isisMaxAreaAddressesMismatch >> - isisAuthenticationTypeFailure >> - isisAuthenticationFailure >> - isisVersionSkew >> - isisAreaMismatch >> - isisRejectedAdjacency >> - isisLSPTooLargeToPropagate >> - isisOrigLSPBuffSizeMismatch >> - isisProtocolsSupportedMismatch >> >> >> >> the beginning of this MIB says it is for ipv6 and >> ipv4, so was wondering why this included here? >> If so, then maybe the only needed TC would be >> from the INET-ADDRESS-MIB (InetAddressType) >> and conformance statements could be used to support >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } > >This is here so that contact with a router that is >only supporting iso8473 can be documented and tracked. > >- 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 16 20:35:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04247 for ; Wed, 16 Jun 2004 20:35:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bakn9-0000RG-0g; Wed, 16 Jun 2004 20:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BakeM-0006wk-Uz for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 20:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03640 for ; Wed, 16 Jun 2004 20:21:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BakeI-0002Ro-LV for isis-wg@ietf.org; Wed, 16 Jun 2004 20:20:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BakdG-00023j-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 20:19:56 -0400 Received: from nn5.excitenetwork.com ([207.159.120.59] helo=excite.com) by ietf-mx with esmtp (Exim 4.12) id 1BakcZ-0001KG-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 20:19:11 -0400 Received: by xprdmailfe8.nwk.excite.com (Postfix, from userid 110) id 4A6DA3DB5; Wed, 16 Jun 2004 20:18:43 -0400 (EDT) To: jparker@axiowave.com, jcucchiara@mindspring.com Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt Received: from [64.47.48.10] by xprdmailfe8.nwk.excite.com via HTTP; Wed, 16 Jun 2004 20:18:43 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20040617001843.4A6DA3DB5@xprdmailfe8.nwk.excite.com> Date: Wed, 16 Jun 2004 20:18:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgoodspe@excite.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit All, My comments are inline marked with DG>>. I am also looking at Jeff's proposed changes in the followup email as I type this. Any places I did not comment mean I am in implicit agreement. My comments come from having worked with both routing protocols AND SNMP/NMS systems for a number of years, meaning I've had these discussions many times before. Cheers, Don =============================================== Thanks for the thoughtful review. > These are mostly in the order they appear in the MIB. > > * Is there really a need for the > OBJECT-IDENTITY part. These are not really used > as OBJECT-IDENTITY's, so think that using > an OBJECT-IDENTIFIER is probably more appropriate. Will investigate the difference. DG>> Changes look OK > * The TC "SupportedProtocol" includes iso8473(129) and > > the beginning of this MIB says it is for ipv6 and > ipv4, so was wondering why this included here? > If so, then maybe the only needed TC would be > from the INET-ADDRESS-MIB (InetAddressType) > and conformance statements could be used to support > a subset such as { unknown(0), ipv4(1), and ipv6(2) } IS-IS isn't really ours to modify: we just get to play with it. IS-IS was designed to route iso8473 and the like. So while the IETF isn't interested in iso8473, ISO is. > * isisSysVersion is an SnmpAdminString and it would be > easier for the Network Management apps > if this were an enum such as > > INTEGER { > unknown(0), > one(1) > } Fine DG>> Looks OK > * (related to the comment about the TC "SupportedProtocols" above) > Could cnIetfIsisSysProtSuppProtocol have a conformance > statement such that only ipv4 and ipv6 are supported > and iso8473(129) is not supported? See above > * since the isisSys is no longer a table, think that > removing the word Entry from these objects would > be better, as they are now scalars. > > so isisSysEntry could be isisSysObjects > Also, some of the descriptions refer to "this instance" and > maybe this could be changed to say, the instance of ISIS on > this router. Will try to address DG>> Looks OK > * is isisSysLogAdjacencyChanges part of the protocol? > Usually objects like these are left for enterprise MIBs > for example, I worked on enterprise MIBs which have all these > sort of logging options in one MIB instead of spread in > various protocol MIBs. Can this object be removed? If there are no objections DG>> True, this is better left to the enterprise MIBs > * isisSysNextCircIndex could be moved to just prior to the > isisCircTable and become part of the isisCircObjects > rather than with the isisSysObjects. I'm not sure I follow. The Circ Table has an entry for each circuit. The NextCircIndex is a system wide item. There is no system wide Circ specific table. Where are you suggesting this be placed? DG>> I think she means instead of having it at isisSysObject 10, to have it at isisCirc 2. > Also, from an implementation point, the IndexInteger and > IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) > are easier to implement so would prefer those TC rather > than the TestAndIncr TC. Comments from others? DG>> The issue here is that TestAndIncr functionality is already implemented in the working code and while we can change that, we'd make a lot of ISIS developers unhappy while making only a few MIB people happy. Also, TestAndIncr is defined in SNMPv2-TC which 99% of implementations already support whereas DIFFSERV-MIB is supported in a far smaller number of implementations. > > * Now that these system Objects are scalars, you probably > don't need the cnIetfIsisSysExistState scalar. Good point DG>> OK with me > * could isisCircIfIndex be InterfaceIndex ? It could, and it probably is the same thing. But don't you think there is some value in the naming convention used here? DG>> I think she means changing the SYNTAX from Integer32 to InterfaceIndex as IMPORTed from IF-MIB > * could isisCircIfSubIndex be > InterfaceIndexOrNull > (or at least these should start with 1 which > is the minimum value for ifIndex) This isn't really an ifIndex: it was added by request for some sub-interface identifiers. DG>> True, this does not comply with an existing textual convention in the IF-MIB > * could isisCircSmallHellos appear in the > conformance statement as optional, it doesn't seem like > this feature is part of ISIS Padded hellos were an important part of the protocol at one time. This provides a way for the administrator to tell if the other side is not padding, or really thinks that the MTU is 36. DG>> True, reporting the value should be mandatory, not optional > * MAJOR comment on the following Notifications: > > Since the agent needs to keep track of > sources for a bunch of situations which trigger > notifications, it might be better to have a table > which tracks this, and configurable threshold values such > that if these occur from a source, that these can > be tracked back to the source. My point is that if > the agent is supposed to track these sources internally > as to only send a notification after one occurance, then why > not make this > table of sources visable and then have thresholds with > defVal of 1 which will trigger the notification. With a > external table > there is more info and this table can > be polled by NMS. (My point is that if the agent is already tracking > this information internally, then maybe adding a table to the MIB > will allow this information to be external and visable to > operator/NMS. I may have stepped over the line with the requirement that these be damped. However, I am uncomfortable requireding a specific damping strategy. DG>> General damping strategies are best left out of individual MIBs and handled either by a separate Operations and Management group or by the individual enterprise. Also, the DESCRIPTION clauses use "should" in every location, so that's a suggestion, not a hard requirement, so it's up to the implementation to adhere or not. I'm OK with the existing language. > I would also encourage that these Notifications and > this external table be made optional in the Conformance, as this is > really a lot of work for not much gain that I could see. > In other words, it's lots of overhead for the router to track > all these > situations which seem sort of unlikely to occur. I agree that there is some overhead here. I will try to reword so that a bitmap per interface would suffice for conformance. DG>> Once again, any damping strategies or supported trap bitmaps are best left out of this MIB and handled either on a global basis as defined by the O&M Area or by the individual enterprises. We don't want a bitmask like the OSPF-TRAP-MIB has, do we? > The notifications which could possibly benefit from > such a table are: > - isisIDLenMismatch > - isisMaxAreaAddressesMismatch > - isisAuthenticationTypeFailure > - isisAuthenticationFailure > - isisVersionSkew > - isisAreaMismatch > - isisRejectedAdjacency > - isisLSPTooLargeToPropagate > - isisOrigLSPBuffSizeMismatch > - isisProtocolsSupportedMismatch > > > > the beginning of this MIB says it is for ipv6 and > ipv4, so was wondering why this included here? > If so, then maybe the only needed TC would be > from the INET-ADDRESS-MIB (InetAddressType) > and conformance statements could be used to support > a subset such as { unknown(0), ipv4(1), and ipv6(2) } This is here so that contact with a router that is only supporting iso8473 can be documented and tracked. - jeff parker _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jun 16 20:44:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04574 for ; Wed, 16 Jun 2004 20:44:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bakwl-0003DY-3E; Wed, 16 Jun 2004 20:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bakp6-0000vq-6d for isis-wg@megatron.ietf.org; Wed, 16 Jun 2004 20:32:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04019 for ; Wed, 16 Jun 2004 20:32:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bakp1-0006Xr-Om for isis-wg@ietf.org; Wed, 16 Jun 2004 20:32:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bako1-0006B5-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 20:31:02 -0400 Received: from nn6.excitenetwork.com ([207.159.120.60] helo=excite.com) by ietf-mx with esmtp (Exim 4.12) id 1BaknL-0005iF-00 for isis-wg@ietf.org; Wed, 16 Jun 2004 20:30:19 -0400 Received: by xprdmailfe17.nwk.excite.com (Postfix, from userid 110) id 85A9BB6D0; Wed, 16 Jun 2004 20:29:46 -0400 (EDT) To: jcucchiara@mindspring.com, jparker@axiowave.com Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt Received: from [64.47.48.10] by xprdmailfe17.nwk.excite.com via HTTP; Wed, 16 Jun 2004 20:29:46 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20040617002946.85A9BB6D0@xprdmailfe17.nwk.excite.com> Date: Wed, 16 Jun 2004 20:29:46 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgoodspe@excite.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit OK, I won't repeat any items I addressed in my last email but only new ones here. Cheers, Don ======================== Hi Jeff, A few responses inline...I saw the diff file and that looked good. Thank you for your quick response. At 03:44 PM 6/15/04 -0400, Jeff Parker wrote: >Thanks for the thoughtful review. > >> These are mostly in the order they appear in the MIB. >> >> * Is there really a need for the >> OBJECT-IDENTITY part. These are not really used >> as OBJECT-IDENTITY's, so think that using >> an OBJECT-IDENTIFIER is probably more appropriate. > >Will investigate the difference. > >> * The TC "SupportedProtocol" includes iso8473(129) and >> >> the beginning of this MIB says it is for ipv6 and >> ipv4, so was wondering why this included here? >> If so, then maybe the only needed TC would be >> from the INET-ADDRESS-MIB (InetAddressType) >> and conformance statements could be used to support >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } > >IS-IS isn't really ours to modify: we just get to play with >it. IS-IS was designed to route iso8473 and the like. >So while the IETF isn't interested in iso8473, ISO is. > Okay. Could this value be made optional in the Conformance Statement? DG>> I think the point is that this MIB applies to ISO implementations as well and it is most definitely not optional to them. >> * isisSysVersion is an SnmpAdminString and it would be >> easier for the Network Management apps >> if this were an enum such as >> > >> INTEGER { >> unknown(0), >> one(1) >> } > >Fine > >> * (related to the comment about the TC "SupportedProtocols" above) >> Could cnIetfIsisSysProtSuppProtocol have a conformance >> statement such that only ipv4 and ipv6 are supported >> and iso8473(129) is not supported? > >See above > >> * since the isisSys is no longer a table, think that >> removing the word Entry from these objects would >> be better, as they are now scalars. >> > >> so isisSysEntry could be isisSysObjects >> Also, some of the descriptions refer to "this instance" and >> maybe this could be changed to say, the instance of ISIS on >> this router. > >Will try to address > >> * is isisSysLogAdjacencyChanges part of the protocol? >> Usually objects like these are left for enterprise MIBs >> for example, I worked on enterprise MIBs which have all these >> sort of logging options in one MIB instead of spread in >> various protocol MIBs. Can this object be removed? > >If there are no objections > >> * isisSysNextCircIndex could be moved to just prior to the >> isisCircTable and become part of the isisCircObjects >> rather than with the isisSysObjects. > >I'm not sure I follow. The Circ Table has an entry for >each circuit. The NextCircIndex is a system wide item. >There is no system wide Circ specific table. > >Where are you suggesting this be placed? > I'm suggesting this be placed before the table that uses it. Admittedly this is a style issue. DIFFSERV-MIB has examples of this (you can grep on IndexIntegerNextFree and you'll see that the objects are actually prior to the table where it is used. DG>> Addressed in previous email. >> Also, from an implementation point, the IndexInteger and >> IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) >> are easier to implement so would prefer those TC rather >> than the TestAndIncr TC. > >Comments from others? > >> >> * Now that these system Objects are scalars, you probably >> don't need the isisSysExistState scalar. > >Good point > >> * could isisCircIfIndex be InterfaceIndex ? > >It could, and it probably is the same thing. >But don't you think there is some value in the >naming convention used here? The range of Integer32 and InterfaceIndex differ because ifIndices do not have a value of zero. My preference would be to use InterfaceIndex from IF-MIB, but could you at least supply a range value? DG>> See previous email. > >> * could isisCircIfSubIndex be >> InterfaceIndexOrNull >> (or at least these should start with 1 which >> is the minimum value for ifIndex) > >This isn't really an ifIndex: it was added by >request for some sub-interface identifiers. The DESCRIPTION makes it sound like an ifIndex, and name (use of "if") make it sound like an InterfaceIndex. Maybe a name change and clarifying the description would help. I don't have any idea of what value this is supposed to be except for some sublayer ifIndex. DG>> Yes, isisCircSubIndex would be better > >> * could isisCircSmallHellos appear in the >> conformance statement as optional, it doesn't seem like >> this feature is part of ISIS > >Padded hellos were an important part of the protocol at >one time. This provides a way for the administrator to >tell if the other side is not padding, or really thinks >that the MTU is 36. okay. > >> * MAJOR comment on the following Notifications: >> > >> Since the agent needs to keep track of >> sources for a bunch of situations which trigger >> notifications, it might be better to have a table >> which tracks this, and configurable threshold values such >> that if these occur from a source, that these can >> be tracked back to the source. My point is that if >> the agent is supposed to track these sources internally >> as to only send a notification after one occurance, then why >> not make this >> table of sources visable and then have thresholds with >> defVal of 1 which will trigger the notification. With a >> external table >> there is more info and this table can >> be polled by NMS. (My point is that if the agent is already tracking >> this information internally, then maybe adding a table to the MIB >> will allow this information to be external and visable to >> operator/NMS. > >I may have stepped over the line with the requirement that these >be damped. However, I am uncomfortable requireding a specific >damping strategy. > >> I would also encourage that these Notifications and >> this external table be made optional in the Conformance, as this is >> really a lot of work for not much gain that I could see. >> In other words, it's lots of overhead for the router to track >> all these >> situations which seem sort of unlikely to occur. > >I agree that there is some overhead here. >I will try to reword so that a bitmap per interface would >suffice for conformance. > Okay, thanks! From my perspective, I think the burden being put on the router is excessive for not very much gain (with regard to the notifications below). Making these optional in the Conformance would be my preference....Maybe others could relate what their experience is with these notifications? DG>> See my previous email for mine Thanks, -Joan >> The notifications which could possibly benefit from >> such a table are: >> - isisIDLenMismatch >> - isisMaxAreaAddressesMismatch >> - isisAuthenticationTypeFailure >> - isisAuthenticationFailure >> - isisVersionSkew >> - isisAreaMismatch >> - isisRejectedAdjacency >> - isisLSPTooLargeToPropagate >> - isisOrigLSPBuffSizeMismatch >> - isisProtocolsSupportedMismatch >> >> >> >> the beginning of this MIB says it is for ipv6 and >> ipv4, so was wondering why this included here? >> If so, then maybe the only needed TC would be >> from the INET-ADDRESS-MIB (InetAddressType) >> and conformance statements could be used to support >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } > >This is here so that contact with a router that is >only supporting iso8473 can be documented and tracked. > >- jeff parker > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 17 06:50:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17520 for ; Thu, 17 Jun 2004 06:50:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BauNt-0003T3-4z; Thu, 17 Jun 2004 06:44:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BauHq-0001Cg-Ih for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 06:38:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16913 for ; Thu, 17 Jun 2004 06:38:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BauHk-0003zZ-7U for isis-wg@ietf.org; Thu, 17 Jun 2004 06:38:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BauGk-0003cj-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 06:37:19 -0400 Received: from mercury0.easily.co.uk ([213.161.76.90] helo=easily.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BauFm-0002wI-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 06:36:25 -0400 Received: from [149.254.200.215] (account ee7a30ha8ykg HELO pchristi.christiantena.co.uk) by easily.co.uk (CommuniGate Pro SMTP 4.1.3) with ESMTP id 71921000; Thu, 17 Jun 2004 10:51:40 +0100 Message-Id: <5.2.1.1.1.20040617100610.00a8e430@customermail.easily.co.uk> X-Sender: ee7a30ha8ykg@customermail.easily.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 17 Jun 2004 10:52:39 +0100 To: Jeff Learman , Kireeti Kompella , isis-wg@ietf.org From: Philip Christian Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <4.3.2.7.2.20040616101215.02706990@dingdong.cisco.com> References: <20040614170235.H11354@kummer.juniper.net> <200405121412.KAA06827@ietf.org> <200405121412.KAA06827@ietf.org> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-76231; boundary="=======38942411=======" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --=======38942411======= Content-Type: text/plain; x-avg-checked=avg-ok-76231; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit Also someone (such as Juniper :-) ) could even donate an OUI the use of which would indicate that the next four bytes is an SNMP ID. In hindsight maybe I should have put an extra byte before the OUI to indicate that OUI is the mechanism. I suppose that we could write a new draft that goes No. of Octets +---------------------------+ | CODE =250 | 1 +---------------------------+ | LENGTH =n+4 | 1 +---------------------------+ | 11000001 | 1 +---------------------------+ | OUI | 3 +---------------------------+ | DATA | n +---------------------------+ No. of Octets +---------------------------+ | CODE =250 | 1 +---------------------------+ | LENGTH =n+5 | 1 +---------------------------+ | 11000010 | 1 +---------------------------+ | SNMP ID | 4 +---------------------------+ | DATA | n +---------------------------+ This would not clash with the current draft provided that no-one has used an OUI with both the multicast and the locally assigned bit set. No-one would do that, would they ? It would give us 64 ways of defining indicators in the future. Regards, Philip At 10:27 16/06/2004 -0400, Jeff Learman wrote: >It would be a bad idea to change the current interpretation of >this TLV, since it could lead to ambiguities. It might also >be a bad idea to assign a new TLV number for this; how many >different numbering plans are there we might be asked to >accommodate in the future? > >One possibility, albeit "wasting" 3 octets pre TLV, would be to >assign an org ID for this purpose (". We could also choose >a value with the "local" bit set, which would never be >assigned as a valid OUI. We could assign any number of these >"local OUIs" to identify any future numbering plans. > >The alternative would be to choose a new TLV value, where the >first octet of the value identifies the numbering plan, something >like this: > > 0 - OUI (treat TLV as synonymous to original TLV and same OUI) > 1 - SNMP Enterprise ID > >This would provide a more concise format for future numbering >plans. > >First we'd need to find out if there's enough support for this >idea to justify the change. I have no opinion on that. > >Regards, >Jeff > >At 08:10 PM 6/14/2004, Kireeti Kompella wrote: > >On Wed, 12 May 2004 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 : TLV for Experimental Use > >> Author(s) : P. Christian > >> Filename : draft-ietf-isis-experimental-tlv-03.txt > >> Pages : 6 > >> Date : 2004-5-6 > >> > >> This document defines a TLV that may be used by any individual, > >> company or other organisation for experimental extensions to the > >> IS-IS routing protocol, and defines the format of the TLV. > > > >I have a request, if I may. > > > >Either change the "discriminator" from an OUI to an SNMP Enterprise > >Code (http://www.iana.org/assignments/enterprise-numbers), > > > >OR > > > >Have a parallel experimental TLV (251?) that uses Enterprise Codes. > > > >Everything else is exactly the same, except (of course) the Enterprise > >Code is 4 octets. > > > >Thanks, > >Kireeti. > >------- > > > >_______________________________________________ > >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 > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.690 / Virus Database: 451 - Release Date: 22/05/2004 --=======38942411======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-76231 Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.690 / Virus Database: 451 - Release Date: 22/05/2004 --=======38942411======= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --=======38942411=======-- From isis-wg-bounces@ietf.org Thu Jun 17 09:22:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28103 for ; Thu, 17 Jun 2004 09:22:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bawjq-00026a-El; Thu, 17 Jun 2004 09:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BawYj-0007st-Rl for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 09:04:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26797 for ; Thu, 17 Jun 2004 09:04:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BawYj-0007HM-9v for isis-wg@ietf.org; Thu, 17 Jun 2004 09:04:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BawWe-0006QT-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 09:01:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1BawU7-00055O-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 08:59:15 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2004 09:03:47 -0400 X-BrightmailFiltered: true Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5HCwDhD003178; Thu, 17 Jun 2004 08:58:14 -0400 (EDT) Received: from dhcp-64-102-48-241.cisco.com (dhcp-64-102-48-241.cisco.com [64.102.48.241]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA06543; Thu, 17 Jun 2004 08:58:13 -0400 (EDT) Date: Thu, 17 Jun 2004 08:58:44 -0400 (EDT) From: Russ White To: Christian Hopps Subject: Re: [Isis-wg] ISIS to go standards track. In-Reply-To: <5084420E-BF15-11D8-AD86-00039303E9E2@procket.com> Message-ID: References: <683AECDA-7C59-11D8-9354-00039303E9E2@procket.com> <5084420E-BF15-11D8-AD86-00039303E9E2@procket.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ISIS-WG X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Russ White List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > RFC 1195 (IPv4)-- Already PS > RFC 2966 (Two-level prefix distribution) > draft-ietf-isis-wg-mib-13.txt > draft-ietf-isis-traffic-05.txt > draft-ietf-isis-ipv6-05.txt > draft-ietf-isis-gmpls-extensions-19.txt > RFC 3787 (IP Interop) > > He also points out that in taking these documents down standards track we > may want to consider combining RFC 1195, RFC 2966, traffic, and RFC 3787 > into a single standards track document. This would leave the MIB, IPv6 > and GMPLS documents to go STDs track standalone. I would tend to agree with this--it should be easy enough to combine them into one doc, and it might actually save the WG some time in the process, rather than juggling four different doc's. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 17 11:08:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08427 for ; Thu, 17 Jun 2004 11:08:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BayJ3-0005oY-LA; Thu, 17 Jun 2004 10: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 1Bay5K-0001Tm-KO for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 10:41:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05986 for ; Thu, 17 Jun 2004 10:41:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bay5J-0006Og-TC for isis-wg@ietf.org; Thu, 17 Jun 2004 10:41:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bay4M-00060B-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 10:40:47 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1Bay33-00053C-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 10:39:25 -0400 Message-ID: From: Jeff Parker To: "'jcucchiara@mindspring.com'" Date: Thu, 17 Jun 2004 10:38:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: isis-wg@ietf.org Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > >> * The TC "SupportedProtocol" includes iso8473(129) and > >> > > >> the beginning of this MIB says it is for ipv6 and > >> ipv4, so was wondering why this included here? > >> If so, then maybe the only needed TC would be > >> from the INET-ADDRESS-MIB (InetAddressType) > >> and conformance statements could be used to support > >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } > > > >IS-IS isn't really ours to modify: we just get to play with > >it. IS-IS was designed to route iso8473 and the like. > >So while the IETF isn't interested in iso8473, ISO is. > > > > Okay. Could this value be made optional in the Conformance > Statement? Joan - You don't need to support CLNS, and you don't need to generate this value. You will see it on the wire. > >> * isisSysNextCircIndex could be moved to just prior to the > >> isisCircTable and become part of the isisCircObjects > >> rather than with the isisSysObjects. > > > >I'm not sure I follow. The Circ Table has an entry for > >each circuit. The NextCircIndex is a system wide item. > >There is no system wide Circ specific table. > > > >Where are you suggesting this be placed? > > > > I'm suggesting this be placed before the table that > uses it. Admittedly this is a style issue. DIFFSERV-MIB > has examples of this (you can grep on IndexIntegerNextFree > and you'll see that the objects are actually prior to the > table where it is used. Joan - I am a bear of very little brain. Can you suggest a specific edit? Perhaps to the version I sent you? > >> * could isisCircIfIndex be InterfaceIndex ? > > > >It could, and it probably is the same thing. > >But don't you think there is some value in the > >naming convention used here? > > The range of Integer32 and InterfaceIndex differ > because ifIndices do not have a value of zero. > My preference would be to use InterfaceIndex from IF-MIB, > but could you at least supply a range value? Fine. I can do this > >> * could isisCircIfSubIndex be > >> InterfaceIndexOrNull > >> (or at least these should start with 1 which > >> is the minimum value for ifIndex) > > > >This isn't really an ifIndex: it was added by > >request for some sub-interface identifiers. > > The DESCRIPTION makes it sound like an ifIndex, and name > (use of "if") make it sound like an InterfaceIndex. Maybe > a name change and clarifying the description would help. > I don't have any idea of what value this is supposed to be > except for some sublayer ifIndex. I will try some word smithing > >I agree that there is some overhead here. > >I will try to reword so that a bitmap per interface would > >suffice for conformance. > > > > Okay, thanks! From my perspective, I think the burden being > put on the router is excessive for not very much gain (with regard > to the notifications below). Making these optional in the Conformance > would be my preference....Maybe others could relate what their > experience is with these notifications? > > Thanks, > -Joan > > > >> The notifications which could possibly benefit from > >> such a table are: > >> - isisIDLenMismatch > >> - isisMaxAreaAddressesMismatch > >> - isisAuthenticationTypeFailure > >> - isisAuthenticationFailure > >> - isisVersionSkew > >> - isisAreaMismatch > >> - isisRejectedAdjacency > >> - isisLSPTooLargeToPropagate > >> - isisOrigLSPBuffSizeMismatch > >> - isisProtocolsSupportedMismatch > >> > >> > >> > >> the beginning of this MIB says it is for ipv6 and > >> ipv4, so was wondering why this included here? > >> If so, then maybe the only needed TC would be > >> from the INET-ADDRESS-MIB (InetAddressType) > >> and conformance statements could be used to support > >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } > > > >This is here so that contact with a router that is > >only supporting iso8473 can be documented and tracked. > > > >- jeff parker Much of this is historic: values such as MaxAreaAddress and IDLen were not fixed in older versions. So checking for these values is probably a good idea. Others, such as AuthFailure, provide an easy way to debug a problem that we certainly see while testing - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 17 14:02:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29034 for ; Thu, 17 Jun 2004 14:02:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb0lL-0004GK-KZ; Thu, 17 Jun 2004 13:33:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bazye-0007Kl-7F for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 12:43:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18443 for ; Thu, 17 Jun 2004 12:42:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bazyd-0003pX-AZ for isis-wg@ietf.org; Thu, 17 Jun 2004 12:42:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bazqm-0002Cf-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 12:34:53 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1BaziE-0007VX-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 12:26:02 -0400 Message-ID: From: Jeff Parker To: "'jcucchiara@mindspring.com'" , Jeff Parker , Jeff Parker Date: Thu, 17 Jun 2004 12:23:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: isis-wg@ietf.org Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Joan - As per your suggestions. % diff mib ~/mib 18,21c18,19 < InterfaceIndex < FROM IF-MIB 1029c1027 < InterfaceIndex, --- > Integer32, 1059c1057 < SYNTAX Integer32 (1..4294967294) --- > SYNTAX Integer32 (1..2000000000) 1071c1069 < SYNTAX InterfaceIndex --- > SYNTAX Integer32 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 17 16:11:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10357 for ; Thu, 17 Jun 2004 16:11:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2zM-0001eg-4x; Thu, 17 Jun 2004 15:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2nb-0006tm-Ox for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 15:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08591 for ; Thu, 17 Jun 2004 15:43:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2na-0000JS-IR for isis-wg@ietf.org; Thu, 17 Jun 2004 15:43:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2mX-0007lq-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 15:42:42 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb2lT-0007Ar-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 15:41:35 -0400 Message-ID: From: Jeff Parker To: "'dgoodspe@excite.com'" , Jeff Parker , jcucchiara@mindspring.com Subject: RE: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt Date: Thu, 17 Jun 2004 15:40:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > > * isisSysNextCircIndex could be moved to just prior to the > > isisCircTable and become part of the isisCircObjects > > rather than with the isisSysObjects. > .... > > Where are you suggesting this be placed? > > DG>> I think she means instead of having it at isisSysObject 10, > to have it at isisCirc 2. The circ table is a sequence of circuits. The NextCircIndex is a scalar. The only table of pure scalars is the system table, so I still don't see a solution here. isisCircTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of circuits used by this Intermediate System." ::= { isisCirc 1 } ... IsisCircEntry ::= SEQUENCE { isisCircIndex Integer32, isisCircIfIndex > > Also, from an implementation point, the IndexInteger and > > IndexIntegerNext TCs from the DIFFSERV-MIB (rfc3289) > > are easier to implement so would prefer those TC rather > > than the TestAndIncr TC. > > Comments from others? > > DG>> The issue here is that TestAndIncr functionality is > already implemented in the working code and while we can > change that, we'd make a lot of ISIS developers unhappy > while making only a few MIB people happy. Also, TestAndIncr > is defined in SNMPv2-TC which 99% of implementations already > support whereas DIFFSERV-MIB is supported in a far smaller > number of implementations. Dan - How big a difference is this? Is what Joan is proposing Right enough that we should fix this now? > DG>> I think she means changing the SYNTAX from Integer32 > to InterfaceIndex as IMPORTed from IF-MIB Done > I may have stepped over the line with the requirement that these > be damped. However, I am uncomfortable requireding a specific > damping strategy. > > DG>> General damping strategies are best left out of individual > MIBs and handled either by a separate Operations and Management > group or by the individual enterprise. Also, the DESCRIPTION > clauses use "should" in every location, so that's a suggestion, > not a hard requirement, so it's up to the implementation to > adhere or not. I'm OK with the existing language. > > > I would also encourage that these Notifications and > > this external table be made optional in the Conformance, as this is > > really a lot of work for not much gain that I could see. > > In other words, it's lots of overhead for the router to track > > all these > > situations which seem sort of unlikely to occur. > > I agree that there is some overhead here. > I will try to reword so that a bitmap per interface would > suffice for conformance. > > DG>> Once again, any damping strategies or supported trap > bitmaps are best left out of this MIB and handled either on > a global basis as defined by the O&M Area or by the individual > enterprises. We don't want a bitmask like the OSPF-TRAP-MIB > has, do we? > > > The notifications which could possibly benefit from > > such a table are: > > - isisIDLenMismatch > > - isisMaxAreaAddressesMismatch > > - isisAuthenticationTypeFailure > > - isisAuthenticationFailure > > - isisVersionSkew > > - isisAreaMismatch > > - isisRejectedAdjacency > > - isisLSPTooLargeToPropagate > > - isisOrigLSPBuffSizeMismatch > > - isisProtocolsSupportedMismatch Don raises a good point: this is SHOULD, not MUST. The overhead of a word per circuit seems a small price to pay for the increased visibility provided. While most of these are rare, there are several that we see with some frequency. If I see any of the issues above, I want to be able to debug the situation without haveing to run through syslog files. For many of these, the problem indicates a serious mismatch. In each case, knowing the circuit the packet was seen on is a first step in debugging the problem. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 17 16:34:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11847 for ; Thu, 17 Jun 2004 16:34:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3Mw-0002J6-8v; Thu, 17 Jun 2004 16:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3HL-0000Gt-3T for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 16:14:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10543 for ; Thu, 17 Jun 2004 16:14:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3HJ-0002mY-OD for isis-wg@ietf.org; Thu, 17 Jun 2004 16:14:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3Ga-0002Sl-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 16:13:45 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Bb3Fa-00027y-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 16:12:42 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bb3Fa-000OpI-It; Thu, 17 Jun 2004 20:12:43 +0000 Date: Thu, 17 Jun 2004 13:12:41 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1025245450.20040617131241@psg.com> To: Kireeti Kompella Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <20040614170235.H11354@kummer.juniper.net> References: <200405121412.KAA06827@ietf.org> <20040614170235.H11354@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 8bit Kireeti, Why isn't the current scheme good enough? -- Alex http://www.psg.com/~zinin Monday, June 14, 2004, 5:10:14 PM, Kireeti Kompella wrote: > On Wed, 12 May 2004 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 : TLV for Experimental Use >> Author(s) : P. Christian >> Filename : draft-ietf-isis-experimental-tlv-03.txt >> Pages : 6 >> Date : 2004-5-6 >> >> This document defines a TLV that may be used by any individual, >> company or other organisation for experimental extensions to the >> IS-IS routing protocol, and defines the format of the TLV. > I have a request, if I may. > Either change the "discriminator" from an OUI to an SNMP Enterprise > Code (http://www.iana.org/assignments/enterprise-numbers), > OR > Have a parallel experimental TLV (251?) that uses Enterprise Codes. > Everything else is exactly the same, except (of course) the Enterprise > Code is 4 octets. > Thanks, > Kireeti. > ------- > _______________________________________________ > 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 Fri Jun 18 09:05:55 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18514 for ; Fri, 18 Jun 2004 09:05:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIsU-0002g0-Og; Fri, 18 Jun 2004 08:53:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbIjl-0000Ei-Dj for isis-wg@megatron.ietf.org; Fri, 18 Jun 2004 08:44:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17622 for ; Fri, 18 Jun 2004 08:44:51 -0400 (EDT) From: jcucchiara@mindspring.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbIjk-0002sM-Gd for isis-wg@ietf.org; Fri, 18 Jun 2004 08:44:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbIih-0002Uj-00 for isis-wg@ietf.org; Fri, 18 Jun 2004 08:43:48 -0400 Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx with esmtp (Exim 4.12) id 1BbIhq-00027s-00 for isis-wg@ietf.org; Fri, 18 Jun 2004 08:42:54 -0400 Received: from h-66-167-249-109.cmbrmaor.dynamic.covad.net ([66.167.249.109] helo=jluciani-laptop) by smtp6.mindspring.com with smtp (Exim 3.33 #1) id 1BbIhn-0000cn-00; Fri, 18 Jun 2004 08:42:51 -0400 Message-Id: <3.0.1.32.20040618083150.012c78d8@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jun 2004 08:31:50 -0400 To: Jeff Parker In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Cc: isis-wg@ietf.org Subject: [Isis-wg] RE: questions on draft-ietf-isis-wg-mib-15.txt 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 10:38 AM 6/17/04 -0400, Jeff Parker wrote: > >> >> * The TC "SupportedProtocol" includes iso8473(129) and >> >> >> >> >> the beginning of this MIB says it is for ipv6 and >> >> ipv4, so was wondering why this included here? >> >> If so, then maybe the only needed TC would be >> >> from the INET-ADDRESS-MIB (InetAddressType) >> >> and conformance statements could be used to support >> >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } >> > >> >IS-IS isn't really ours to modify: we just get to play with >> >it. IS-IS was designed to route iso8473 and the like. >> >So while the IETF isn't interested in iso8473, ISO is. >> > >> >> Okay. Could this value be made optional in the Conformance >> Statement? > >Joan - > You don't need to support CLNS, and you don't need to >generate this value. You will see it on the wire. > >> >> * isisSysNextCircIndex could be moved to just prior to the >> >> isisCircTable and become part of the isisCircObjects >> >> rather than with the isisSysObjects. >> > >> >I'm not sure I follow. The Circ Table has an entry for >> >each circuit. The NextCircIndex is a system wide item. >> >There is no system wide Circ specific table. >> > >> >Where are you suggesting this be placed? >> > >> >> I'm suggesting this be placed before the table that >> uses it. Admittedly this is a style issue. DIFFSERV-MIB >> has examples of this (you can grep on IndexIntegerNextFree >> and you'll see that the objects are actually prior to the >> table where it is used. > >Joan - > I am a bear of very little brain. Can you suggest >a specific edit? Perhaps to the version I sent you? Hi Jeff, Here's an edit. Basically, it involves moving the scalar object to right before the table. Scalars do not have to be grouped together, although you do see that many usually appear together. But for this particular scalar, think it is best to appear before the table as it sort of goes with the table. Note the name change (removing Sys and also the OID change). There are many examples of this sort of scalar being in front of the table that the scalar is associated with, so it is an accepted MIB style. isisNextCircIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to assign values to isisCircIndex as described in 'Textual Conventions for SNMPv2'. The network manager reads this object, and then writes the value back as the isisCircIndex in a SET that creates a new instance of isisCircEntry. If the SET fails with the code 'inconsistentValue', then the process must be repeated; If the SET succeeds, then the object is incremented, and the new isisCircuit is created according to the manager's directions." ::= { isisCirc 1 } isisCircTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of circuits used by each instance of Integrated IS-IS on this system." ::= { isisCirc 2 } isisCircEntry OBJECT-TYPE SYNTAX IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircEntry exists for each circuit used by Integrated IS-IS on this system." INDEX { isisCircIndex } ::= { isisCircTable 1 } IsisCircEntry ::= SEQUENCE { isisCircIndex Integer32, isisCircIfIndex Integer32, isisCircIfSubIndex Integer32, isisCircAdminState AdminState, isisCircExistState RowStatus, isisCircType INTEGER, isisCircExtDomain TruthValue, isisCircLevel INTEGER, isisCircPassiveCircuit TruthValue, isisCircMeshGroupEnabled INTEGER, isisCircMeshGroup Unsigned32, isisCircSmallHellos TruthValue, isisCircLastUpTime TimeTicks, isisCirc3WayEnabled TruthValue, isisCircExtendedCircID Unsigned32 } isisCircIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of this circuit, unique within the instance of the IS-IS protocol. This object follows the index behavior. This is for SNMP Indexing purposes only and need not have any relation to any protocol value." ::= { isisCircEntry 1 } Thanks, -Joan > >> >> * could isisCircIfIndex be InterfaceIndex ? >> > >> >It could, and it probably is the same thing. >> >But don't you think there is some value in the >> >naming convention used here? >> >> The range of Integer32 and InterfaceIndex differ >> because ifIndices do not have a value of zero. >> My preference would be to use InterfaceIndex from IF-MIB, >> but could you at least supply a range value? > >Fine. I can do this > >> >> * could isisCircIfSubIndex be >> >> InterfaceIndexOrNull >> >> (or at least these should start with 1 which >> >> is the minimum value for ifIndex) >> > >> >This isn't really an ifIndex: it was added by >> >request for some sub-interface identifiers. >> >> The DESCRIPTION makes it sound like an ifIndex, and name >> (use of "if") make it sound like an InterfaceIndex. Maybe >> a name change and clarifying the description would help. >> I don't have any idea of what value this is supposed to be >> except for some sublayer ifIndex. > >I will try some word smithing > >> >I agree that there is some overhead here. >> >I will try to reword so that a bitmap per interface would >> >suffice for conformance. >> > >> >> Okay, thanks! From my perspective, I think the burden being >> put on the router is excessive for not very much gain (with regard >> to the notifications below). Making these optional in the Conformance >> would be my preference....Maybe others could relate what their >> experience is with these notifications? >> >> Thanks, >> -Joan >> >> >> >> The notifications which could possibly benefit from >> >> such a table are: >> >> - isisIDLenMismatch >> >> - isisMaxAreaAddressesMismatch >> >> - isisAuthenticationTypeFailure >> >> - isisAuthenticationFailure >> >> - isisVersionSkew >> >> - isisAreaMismatch >> >> - isisRejectedAdjacency >> >> - isisLSPTooLargeToPropagate >> >> - isisOrigLSPBuffSizeMismatch >> >> - isisProtocolsSupportedMismatch >> >> >> >> >> >> >> >> the beginning of this MIB says it is for ipv6 and >> >> ipv4, so was wondering why this included here? >> >> If so, then maybe the only needed TC would be >> >> from the INET-ADDRESS-MIB (InetAddressType) >> >> and conformance statements could be used to support >> >> a subset such as { unknown(0), ipv4(1), and ipv6(2) } >> > >> >This is here so that contact with a router that is >> >only supporting iso8473 can be documented and tracked. >> > >> >- jeff parker > >Much of this is historic: values such as MaxAreaAddress >and IDLen were not fixed in older versions. So checking >for these values is probably a good idea. Others, such >as AuthFailure, provide an easy way to debug a problem >that we certainly see while testing > >- 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 18 10:52:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28526 for ; Fri, 18 Jun 2004 10:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbKWL-00069F-MR; Fri, 18 Jun 2004 10:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb8ls-0001Bo-Gl for isis-wg@megatron.ietf.org; Thu, 17 Jun 2004 22:06:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05546 for ; Thu, 17 Jun 2004 22:06:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb8lq-0003XB-RV for isis-wg@ietf.org; Thu, 17 Jun 2004 22:06:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb8kz-0003Cx-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 22:05:30 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1Bb8k7-0002YE-00 for isis-wg@ietf.org; Thu, 17 Jun 2004 22:04:35 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i5I23Em6029621; Thu, 17 Jun 2004 19:03:16 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i5I23EUF029618; Thu, 17 Jun 2004 19:03:14 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 17 Jun 2004 19:03:14 -0700 (PDT) From: Kireeti Kompella To: Philip Christian Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <5.2.1.1.1.20040617100610.00a8e430@customermail.easily.co.uk> Message-ID: <20040617185155.T29575@kummer.juniper.net> References: <20040614170235.H11354@kummer.juniper.net> <200405121412.KAA06827@ietf.org> <200405121412.KAA06827@ietf.org> <5.2.1.1.1.20040617100610.00a8e430@customermail.easily.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 X-Mailman-Approved-At: Fri, 18 Jun 2004 10:39:08 -0400 Cc: Jeff Learman , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Thu, 17 Jun 2004, Philip Christian wrote: > Also someone (such as Juniper :-) ) could even donate an OUI the use of > which would indicate that the next four bytes is an SNMP ID. Well, Juniper (and many others, I suspect) doesn't have an OUI. We do have an SNMP enterprise code, and if we didn't, it would cost a couple of emails to get one. (Alex, does that answer your question?) [I'm speaking with 20/20 hindsight -- if you look at the RSVP change draft (draft-kompella-rsvp-change-02.txt), the experimental code space for uses SNMP enterprise IDs, but the first idea was to use an OUI.] > In hindsight maybe I should have put an extra byte before the OUI to > indicate that OUI is the mechanism. > > I suppose that we could write a new draft that goes I'd be in violent agreement with this. > This would not clash with the current draft provided that no-one has used > an OUI with both the multicast and the locally assigned bit set. No-one > would do that, would they ? Nah! > It would give us 64 ways of defining indicators in the future. Sounds plenty to me. A poll of how many have implemented the 250 TLV as currently defined may help sort out how to proceed .... Juniper hasn't (would you have guessed???) Kireeti. ------- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Jun 21 15:52:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22065 for ; Mon, 21 Jun 2004 15:52:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcUOU-0000AW-SN; Mon, 21 Jun 2004 15:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcU3N-0008Fe-AQ for isis-wg@megatron.ietf.org; Mon, 21 Jun 2004 15:02:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17157 for ; Mon, 21 Jun 2004 15:01:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcU3M-00055c-4u for isis-wg@ietf.org; Mon, 21 Jun 2004 15:02:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcU2O-0004p3-00 for isis-wg@ietf.org; Mon, 21 Jun 2004 15:01:01 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BcU1W-0004IP-00; Mon, 21 Jun 2004 15:00:06 -0400 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i5LIx0J06268; Mon, 21 Jun 2004 11:59:00 -0700 (PDT) Message-Id: <200406211859.i5LIx0J06268@boreas.isi.edu> To: IETF-Announce: ; From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 21 Jun 2004 11:59:00 -0700 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-8.9 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME,USER_IN_DEF_WHITELIST autolearn=no version=2.60 Cc: isis-wg@ietf.org, rfc-editor@rfc-editor.org Subject: [Isis-wg] RFC 3784 on Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3784 Title: Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) Author(s): H. Smit, T. Li Status: Informational Date: June 2004 Mailbox: hhwsmit@xs4all.nl, tony.li@tony.li Pages: 13 Characters: 27422 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isis-traffic-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3784.txt This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <040621115732.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3784 --OtherAccess Content-Type: Message/External-body; name="rfc3784.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <040621115732.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Tue Jun 22 19:10:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08036 for ; Tue, 22 Jun 2004 19:10:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctn9-0007xR-Lc; Tue, 22 Jun 2004 18:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqB4-0000zg-W7 for isis-wg@megatron.ietf.org; Tue, 22 Jun 2004 14:39:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14966 for ; Tue, 22 Jun 2004 14:39:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqB3-0003K7-T8 for isis-wg@ietf.org; Tue, 22 Jun 2004 14:39:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcpnX-0006yK-00 for isis-wg@ietf.org; Tue, 22 Jun 2004 14:15:08 -0400 Received: from io.iol.unh.edu ([132.177.123.82]) by ietf-mx with esmtp (Exim 4.12) id 1Bcp6H-00072V-00 for isis-wg@ietf.org; Tue, 22 Jun 2004 13:30:25 -0400 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.13.0/8.13.0) with ESMTP id i5MHTq3W025757 for ; Tue, 22 Jun 2004 13:29:52 -0400 Received: from io.iol.unh.edu (eaburns@localhost) by io.iol.unh.edu (8.13.0/8.13.0/Submit) with ESMTP id i5MHTqeH025754 for ; Tue, 22 Jun 2004 13:29:52 -0400 Message-Id: <200406221729.i5MHTqeH025754@io.iol.unh.edu> To: isis-wg@ietf.org Date: Tue, 22 Jun 2004 13:29:52 -0400 From: Ethan Burns X-UNH-IOL-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-UNH-IOL-MailScanner: Found to be clean X-MailScanner-From: eaburns@io.iol.unh.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Isis-wg] Checksum 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hello, I was wondering if someone could help me. I am trying to implement the checksum algorithem in the LSP packets of IS-IS. I am very confused as to what values to use in the initialization of C0 and C1. Any help on this would be greatly appreciated. --Ethan Burns-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 24 13:40:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04252 for ; Thu, 24 Jun 2004 13:40:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXKQ-000237-0S; Thu, 24 Jun 2004 12:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd8oC-0001kC-NJ for isis-wg@megatron.ietf.org; Wed, 23 Jun 2004 10:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12124 for ; Wed, 23 Jun 2004 05:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd4Oc-0004Ri-BL for isis-wg@ietf.org; Wed, 23 Jun 2004 05:50:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd4Ni-00045D-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 05:49:27 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 1Bd4N7-0003iK-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 05:48:49 -0400 Received: from ghostrider.gredler.at (localhost [127.0.0.1]) by ghostrider.gredler.at (8.12.11/8.12.9) with ESMTP id i5N9miLC015101; Wed, 23 Jun 2004 11:48:44 +0200 Received: (from hannes@localhost) by ghostrider.gredler.at (8.12.11/8.12.11/Submit) id i5N9miUl015100; Wed, 23 Jun 2004 11:48:44 +0200 Date: Wed, 23 Jun 2004 11:48:44 +0200 From: Hannes Gredler To: Ethan Burns Subject: Re: [Isis-wg] Checksum Message-ID: <20040623094844.GA15065@juniper.net> References: <200406221729.i5MHTqeH025754@io.iol.unh.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <200406221729.i5MHTqeH025754@io.iol.unh.edu> User-Agent: Mutt/1.5.6i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 22, 2004 at 01:29:52PM -0400, Ethan Burns wrote: | Hello, | I was wondering if someone could help me. I am trying to implement the | checksum algorithem in the LSP packets of IS-IS. I am very confused | as to what values to use in the initialization of C0 and C1. Any help on this | would be greatly appreciated. you may want to have a look at isisd/isis_checksum.c [attached]; /hannes --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="iso_checksum.c" /* * IS-IS Rout(e)ing protocol - iso_checksum.c * ISO checksum related routines * * Copyright (C) 2001,2002 Sampo Saaristo * Tampere University of Technology * Institute of Communications Engineering * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public Licenseas published by the Free * Software Foundation; either version 2 of the License, or (at your option) * any later version. * * This program is distributed in the hope that it will be useful,but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. * You should have received a copy of the GNU General Public License along * with this program; if not, write to the Free Software Foundation, Inc., * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include #include "iso_checksum.h" /* * Calculations of the OSI checksum. * ISO/IEC 8473 defines the sum as * * L * sum a (mod 255) = 0 * 1 i * * L * sum (L-i+1)a (mod 255) = 0 * 1 i * */ /* * Verifies that the checksum is correct. * Return 0 on correct and 1 on invalid checksum. * Based on Annex C.4 of ISO/IEC 8473 * FIXME: Check for overflow */ int iso_csum_verify (u_char *buffer, int len, uint16_t *csum) { u_int8_t *p; u_int32_t c0; u_int32_t c1; u_int16_t checksum; int i; p = buffer; checksum = 0; c0 = *csum & 0xff00; c1 = *csum & 0x00ff; /* * If both are zero return correct */ if (c0 == 0 && c1 == 0) return 0; /* * If either, but not both are zero return incorrect */ if (c0 == 0 || c1 == 0) return 1; /* * Otherwise initialize to zero and calculate... */ c0 = 0; c1 = 0; for (i = 0; i < len; i++) { c0 = c0 + *(p++); c1 += c0; } c0 = c0 % 255; c1 = c1 % 255; if ( c0 == 0 && c1 == 0) return 0; return 1; } /* * Creates the checksum. *csum points to the position of the checksum in the * PDU. * Based on Annex C.4 of ISO/IEC 8473 * we will not overflow until about length of 6000, * which is the answer to (255+255n)*n/2 > 2^32 * so if we have a length of over 5000 we will return zero (for now) */ #define FIXED_CODE u_int16_t iso_csum_create (u_char *buffer, int len, u_int16_t n) { u_int8_t *p; int x; int y; u_int32_t mul; u_int32_t c0; u_int32_t c1; u_int16_t checksum; u_int16_t *csum; int i; checksum = 0; /* * Zero the csum in the packet. */ csum = (u_int16_t*)(buffer + n); *(csum) = checksum; /* for the limitation of our implementation */ if (len > 5000) { return 0; } p = buffer; c0 = 0; c1 = 0; for (i = 0; i < len; i++) { c0 = c0 + *(p++); c1 += c0; } c0 = c0 % 255; c1 = c1 % 255; mul = (len - n)*(c0); #ifdef FIXED_CODE x = mul - c0 - c1; y = c1 - mul - 1; if ( y >= 0 ) y++; if ( x < 0 ) x--; x %= 255; y %= 255; if (x == 0) x = 255; if (y == 0) y = 255; x &= 0x00FF; checksum = ((y << 8) | x); #else x = mul - c0 - c1; x %= 255; y = c1 - mul - 1; y %= 255; if (x == 0) x = 255; if (y == 0) y = 255; checksum = ((y << 8) | x); #endif /* * Now we write this to the packet */ *(csum) = checksum; /* return the checksum for user usage */ return checksum; } int iso_csum_modify (u_char *buffer, int len, uint16_t *csum) { return 0; } --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --1yeeQ81UyVL57Vl7-- From isis-wg-bounces@ietf.org Thu Jun 24 13:47:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04838 for ; Thu, 24 Jun 2004 13:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXLD-0002Em-Bt; Thu, 24 Jun 2004 12:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd9dp-0005py-5N for isis-wg@megatron.ietf.org; Wed, 23 Jun 2004 11:26:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07976 for ; Wed, 23 Jun 2004 11:26:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd9do-0002z7-1N for isis-wg@ietf.org; Wed, 23 Jun 2004 11:26:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd95q-0005Xh-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 10:51:19 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1Bd8i5-0002BF-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 10:26:45 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 23 Jun 2004 10:26:33 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5NEQDGs010428; Wed, 23 Jun 2004 10:26:13 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-206-66.cisco.com [64.102.206.66]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAD26360; Wed, 23 Jun 2004 07:26:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20040623095446.0251d420@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jun 2004 10:10:48 -0400 To: Ethan Burns , isis-wg@ietf.org From: Jeff Learman Subject: Re: [Isis-wg] Checksum In-Reply-To: <200406221729.i5MHTqeH025754@io.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 01:29 PM 6/22/2004, Ethan Burns wrote: >Hello, > I was wondering if someone could help me. I am trying to implement the >checksum algorithem in the LSP packets of IS-IS. I am very confused >as to what values to use in the initialization of C0 and C1. Any help on this >would be greatly appreciated. My interpretation of what 10589 says: At system init, initialize C0 & C1 to zero, run the algorithm on your System ID, and save these values for subsequent use. Of course, repeat this whenever your System ID changes. Your system ID is typically your MAC address. For received packets, initialize C0 and C1 to zero and checksum the packet starting at offset 12 (beginning of LSP ID field). For generated packets, initialize C0 and C1 to the saved values. Then run the checksum algorithm starting at offset 12 + IdLength (IdLength is typically 6). No warranty. I did not look at Cisco code to verify this, and I have not worked on ISIS at Cisco. Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 24 15:32:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18547 for ; Thu, 24 Jun 2004 15:32:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPk-0003ZY-M7; Thu, 24 Jun 2004 12:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdFKm-0006nk-WB for isis-wg@megatron.ietf.org; Wed, 23 Jun 2004 17:31:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20096 for ; Wed, 23 Jun 2004 17:31:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdFKl-0003a4-7A for isis-wg@ietf.org; Wed, 23 Jun 2004 17:31:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdFJk-0003Ch-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 17:30:07 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1BdFJM-0002pT-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 17:29:40 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Date: Wed, 23 Jun 2004 17:29:03 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C45969.1AE4D8E0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Isis-wg] Version 16 of the mib 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: , 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. ------_=_NextPart_000_01C45969.1AE4D8E0 Content-Type: text/plain; charset="iso-8859-1" I have just shipped off version 16 of the mib. The principle changes were -- Changes in version 16 -- -- Restored range for isisSysMaxLSPGenInt -- Replaced DisplayString with SnmpAdminString, from RFC 2571 -- Move NextCircIndex out of System Table -- Note that this changes the OID for circuit table -- Removed traces in comments of sysInstance I have included the diffs.txt from version 15. While the list is quite long, many of these are cosmetic. I have produced an edited version, called realdiffs.txt below for those interested in reviewing the wheat rather than the chaff. - jeff parker - axiowave networks - As scarce as truth is, the supply has always been in excess of the demand - Josh Billings ------_=_NextPart_000_01C45969.1AE4D8E0 Content-Type: text/plain; name="diffs.txt" Content-Disposition: attachment; filename="diffs.txt" Content-Transfer-Encoding: quoted-printable 1c1 < -- Changes in version 15 --- > -- Changes in version 16 3c3,7 < -- Remove sysInstance --- > -- Restored range for isisSysMaxLSPGenInt=20 > -- Replaced DisplayString with SnmpAdminString, from RFC 2571 > -- Move NextCircIndex out of System Table > -- Note that this changes the OID for circuit table > -- Removed traces in comments of sysInstance 8,9c12 < TEXTUAL-CONVENTION, DisplayString, RowStatus, TruthValue, < TestAndIncr --- > TEXTUAL-CONVENTION, RowStatus, TruthValue 11,12c14,15 < MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, = NOTIFICATION-TYPE, < Integer32, Unsigned32, Counter32, experimental, TimeTicks --- > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32,=20 > Counter32, experimental, TimeTicks, NOTIFICATION-TYPE 15a19,24 > SnmpAdminString > FROM SNMP-FRAMEWORK-MIB > IndexIntegerNextFree > FROM DIFFSERV-MIB > InterfaceIndex=20 > FROM IF-MIB 20c29 < LAST-UPDATED "200404011200Z" --- > LAST-UPDATED "200406231200Z" 55,59c64,65 < isisSystem OBJECT-IDENTITY < STATUS current < DESCRIPTION < "The object describes system wide attributes." < ::=3D { isisObjects 1 } --- > -- System wide attributes. > isisSystem OBJECT IDENTIFIER ::=3D { isisObjects 1 } 61,66c67,68 < isisSysLevel OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < the domain or with the area." < ::=3D { isisObjects 2 } --- > -- Attributes associated with the domain or with the area. > isisSysLevel OBJECT IDENTIFIER ::=3D { isisObjects 2 } 68,73c70,71 < isisCirc OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < one Circuit" < ::=3D { isisObjects 3 } --- > -- Attributes associated with one Circuit > isisCirc OBJECT IDENTIFIER ::=3D { isisObjects 3 } 75,80c73,74 < isisCircLevelValues OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < area or domain relevant within a Circuit." < ::=3D { isisObjects 4 } --- > -- Attributes associated with area or domain relevant within a = Circuit. > isisCircLevelValues OBJECT IDENTIFIER ::=3D { isisObjects 4 } 82,86c76,77 < isisCounters OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object collects system and circuit counters" < ::=3D { isisObjects 5 } --- > -- System and circuit counters. > isisCounters OBJECT IDENTIFIER ::=3D { isisObjects 5 } 88,93c79,80 < isisISAdj OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with an < adjacent Protocol Peer." < ::=3D { isisObjects 6 } --- > -- Attributes associated with an adjacent Protocol Peer. > isisISAdj OBJECT IDENTIFIER ::=3D { isisObjects 6 } 95,100d81 < isisReachAddr OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < a configured address" < ::=3D { isisObjects 7 } 102,108c83,84 < isisIPReachAddr OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes attributes associated with < IP routes learned by configuration or through another < protocol." < ::=3D { isisObjects 8 } --- > -- Attributes associated with a configured address. > isisReachAddr OBJECT IDENTIFIER ::=3D { isisObjects 7 } 110,115c86,88 < isisLSPDataBase OBJECT-IDENTITY < STATUS current < DESCRIPTION < "This object describes the collection of Link State PDUs < known to the system." < ::=3D { isisObjects 9 } --- > -- Attributes associated with IP routes learned by=20 > -- configuration or through another protocol. > isisIPReachAddr OBJECT IDENTIFIER ::=3D { isisObjects 8 } 117,121c90,94 < isisNotification OBJECT-IDENTITY < STATUS current < DESCRIPTION < "Objects included in Notifications." < ::=3D { isisObjects 10 } --- > -- The collection of Link State PDUs known to the Intermediate System > isisLSPDataBase OBJECT IDENTIFIER ::=3D { isisObjects 9 } >=20 > -- Objects included in Notifications. > isisNotification OBJECT IDENTIFIER ::=3D { isisObjects 10 } 197,198c170,172 < "Wide Metric for IS Neighbors. ISO 10589 provides a 6 = bit metric. < Traffic Engineering extensions provide 24 bit metrics." --- > "Wide Metric for IS Neighbors. ISO 10589 provides a=20 > 6 bit metric. Traffic Engineering extensions provide=20 > 24 bit metrics." 298c272 < isisSysEntry OBJECT IDENTIFIER ::=3D { isisSystem 1 } --- > isisSysObject OBJECT IDENTIFIER ::=3D { isisSystem 1 } 301c275,279 < SYNTAX DisplayString --- > SYNTAX INTEGER > { > unknown(0), > one(1) > } 305,306c283,284 < "The version number of the IS-IS protocol which this < instance implements." --- > "The version number of the IS-IS protocol that > is implemented." 308,309c286,287 < DEFVAL { "1" } < ::=3D { isisSysEntry 1 } --- > DEFVAL { one } > ::=3D { isisSysObject 1 } 321,322c299,300 < "The type of this instance of the Integrated < IS-IS protocol. This object follows the --- > "At which levels is the Intermediate System > running? This object follows the 326c304 < ::=3D { isisSysEntry 2 } --- > ::=3D { isisSysObject 2 } 333,334c311,312 < "The ID for this instance of the Integrated IS-IS < protocol. This value is appended to each of the --- > "The ID for this Intermediate System. > This value is appended to each of the 342c320 < ::=3D { isisSysEntry 3 } --- > ::=3D { isisSysObject 3 } 354c332 < ::=3D { isisSysEntry 4 } --- > ::=3D { isisSysObject 4 } 357c335 < SYNTAX Integer32 (1..65535) --- > SYNTAX Integer32 (1..65235) 363c341 < by this instance of the protocol. This object follows --- > by this Intermediate System. This object follows 370c348 < ::=3D { isisSysEntry 5 } --- > ::=3D { isisSysObject 5 } 383c361 < ::=3D { isisSysEntry 6 } --- > ::=3D { isisSysObject 6 } 396c374 < ::=3D { isisSysEntry 7 } --- > ::=3D { isisSysObject 7 } 403,406c381,384 < "The administrative state of this instance of the < Integrated IS-IS protocol. Setting this object to the < value 'on' when its current value is 'off' enables = operation < of this instance of the Integrated IS-IS protocol." --- > "The administrative state of this Intermediate=20 > System. Setting this object to the value 'on'=20 > when its current value is 'off' enables=20 > the Intermediate System." 408,436c386 < ::=3D { isisSysEntry 8 } <=20 < isisSysLogAdjacencyChanges OBJECT-TYPE < SYNTAX TruthValue < MAX-ACCESS read-write < STATUS current < DESCRIPTION < "If true, causes IS-IS to generate a log message when an < IS-IS adjacency changes state (up or down)." < DEFVAL { false } < ::=3D { isisSysEntry 9 } <=20 < isisSysNextCircIndex OBJECT-TYPE < SYNTAX TestAndIncr < MAX-ACCESS read-only < STATUS current < DESCRIPTION < "This object is used to assign values to < isisCircIndex as described in 'Textual < Conventions for SNMPv2'. The network manager < reads this object, and then writes the value < back as the isisCircIndex in a SET that creates < a new instance of isisCircEntry. If the SET < fails with the code 'inconsistentValue', then < the process must be repeated; If the SET succeeds, < then the object is incremented, and the new < isisCircuit is created according to the manager's < directions." < ::=3D { isisSysEntry 10 } --- > ::=3D { isisSysObject 8 } 445c395 < ::=3D { isisSysEntry 11 } --- > ::=3D { isisSysObject 9 } 458c408 < ::=3D { isisSysEntry 12 } --- > ::=3D { isisSysObject 10 } 476,488c426 < ::=3D { isisSysEntry 13 } <=20 < isisSysExistState OBJECT-TYPE < SYNTAX RowStatus < MAX-ACCESS read-write < STATUS current < DESCRIPTION < "The state of the IS-IS router. Turning this to < state 'destroy' forces the router to forget all < the current configuration. Setting the state to < 'notInService' stops protocol processing, but < retains the configuration." < ::=3D { isisSysEntry 14 } --- > ::=3D { isisSysObject 11 } 492c430 < -- for each instance of the Integrated IS-IS protocol. --- > -- for this Intermediate System. 494,497c432,434 < -- is active must be present for each active instance of < -- the protocol The maximum number of rows in this table for < -- each instance of the protocol for which the object < -- isisManAreaAddrExistState has the value active is 3 --- > -- is active must be present. The maximum number of rows=20 > -- in this table for for which the object > -- isisManAreaAddrExistState has the value active is 3. 552c489 < for this instance of the IS-IS protocol is 'on', and an --- > for this Intermediate System is 'on', and an 554,556c491,493 < or 'notInService' when this is the only = isisManAreaAddrEntry < in state 'active' for this instance of the IS-IS = protocol < should return inconsistentValue." --- > or 'notInService' when this is the only=20 > isisManAreaAddrEntry in state 'active' for this=20 > Intermediate System should return inconsistentValue." 572,573c509,510 < instance of the protocol from Intermediate Systems which < are reachable via Level 1 routing." --- > Intermediate System from other Intermediate Systems=20 > which are reachable via Level 1 routing." 583,584c520 < Level 1 LSP received by this instance of the IS-IS < protocol." --- > Level 1 LSP received by this Intermediate System."=20 600c536 < this instance of the IS-IS protocol." --- > this Intermediate System."=20 607,608c543,544 < -- configured set of protocols supported by each < -- instance of the Integrated IS-IS protocol. --- > -- configured set of protocols supported by this > -- Intermediate System. 616,617c552 < protocols supported by each instance of the Integrated < IS-IS protocol." --- > protocols supported by this Intermediate System." 625,626c560,561 < "Each entry contains one protocol supported by an < instance of the Integrated IS-IS protocol." --- > "Each entry contains one protocol supported by=20 > this Intermediate System." 662,663c597 < -- addresses manually configured for each instance of < -- IP Integrated IS-IS on the system. --- > -- addresses manually configured for the Intermediate System. 765,766c699,700 < -- The Redistribution table defines addresses that should be leaked = from < -- L2 to L1 if isisSysL2toL1Leaking is enabled. --- > -- The Redistribution table defines addresses that should be=20 > -- leaked from L2 to L1 if isisSysL2toL1Leaking is enabled. 859c793,794 < "Each entry tracks information about one peer at one = level." --- > "Each entry tracks information about one peer at=20 > one level." 871c806 < DisplayString, --- > SnmpAdminString, 893c828 < SYNTAX DisplayString --- > SYNTAX SnmpAdminString 968c903 < this instance of the protocol at this level. --- > this Intermediate System at this level. 981,984c916,919 < "Minimum interval, in seconds, between successive = generation < of LSPs with the same LSPID at this level by this = instance < of the protocol. This object follows the resettingTimer < behavior." --- > "Minimum interval, in seconds, between successive=20 > generation of LSPs with the same LSPID at this level > by this Intermediate System. This object > follows the resettingTimer behavior." 1057a993,1013 >=20 > -- Static to provide next CircIndex >=20 > isisNextCircIndex OBJECT-TYPE > SYNTAX TestAndIncr > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object is used to assign values to > isisCircIndex as described in 'Textual > Conventions for SNMPv2'. The network manager > reads this object, and then writes the value > back as the isisCircIndex in a SET that creates > a new instance of isisCircEntry. If the SET > fails with the code 'inconsistentValue', then > the process must be repeated; If the SET succeeds, > then the object is incremented, and the new > isisCircuit is created according to the manager's > directions." > ::=3D { isisCirc 1 } >=20 1069,1071c1025,1027 < "The table of circuits used by each instance of < Integrated IS-IS on this system." < ::=3D { isisCirc 1 } --- > "The table of circuits used by this=20 > Intermediate System." > ::=3D { isisCirc 2 } 1088c1044 < Integer32, --- > InterfaceIndex, 1118c1074 < SYNTAX Integer32 --- > SYNTAX Integer32 (1..2147483647) 1123c1079 < instance of the IS-IS protocol. This object follows --- > Intermediate System. This object follows 1130c1086 < SYNTAX Integer32 --- > SYNTAX InterfaceIndex=20 1165,1168c1121,1125 < the Row Status behavior. Setting the state to = 'notInService' < halts the generation and processing of IS-IS protocol = PDUs < on this circuit. Setting the state to destroy will also < erase any configuration associated with the circuit." --- > the Row Status behavior. Setting the state to=20 > 'notInService' halts the generation and processing of=20 > IS-IS protocol PDUs on this circuit. Setting the state=20 > to destroy will also erase any configuration associated=20 > with the circuit." 1411,1413c1368,1370 < do not need to be unique. They are only required to = differ < on LANs where the Intermediate System is the Designated < Intermediate System." --- > do not need to be unique. They are only required to=20 > differ on LANs where the Intermediate System is the=20 > Designated Intermediate System." 1454,1455c1411,1412 < holding time in transmitted hellos, to be used by = receivers < of hello packets from this IS" --- > holding time in transmitted hellos, to be used by=20 > receivers of hello packets from this IS" 1500c1457,1458 < REFERENCE "{ISIS.aoi minimumBroadcastLSPTransmissionInterval = (5)}" --- > REFERENCE=20 > "{ISIS.aoi minimumBroadcastLSPTransmissionInterval (5)}" 1511,1512c1469,1470 < an LSP at this level. This object follows the = resettingTimer < behavior. --- > an LSP at this level. This object follows the=20 > resettingTimer behavior. 1542,1544c1500,1502 < "Minimum interval in seconds between sending Partial = Sequence < Number PDUs at this level. This object follows the < resettingTimer behavior." --- > "Minimum interval in seconds between sending Partial=20 > Sequence Number PDUs at this level. This object=20 > follows the resettingTimer behavior." 1556,1557c1514 < "System wide counters for one instance of the IS-IS < protocol on the system." --- > "System wide counters for this Intermediate System." 1634c1591 < by this instance of the protocol." --- > by this Intermediate System." 1644c1601 < instance of the protocol." --- > Intermediate System." 1674c1631,1632 < REFERENCE "{ISIS.aoi attemptsToExceedmaximumSequenceNumber = (22)}" --- > REFERENCE=20 > "{ISIS.aoi attemptsToExceedmaximumSequenceNumber (22)}" 1740,1741c1698,1699 < "Circuit specific counters for one instance of the IS-IS < protocol on the system." --- > "Circuit specific counters for this=20 > Intermediate System." 1823c1781,1782 < Failures to form an adjaceny are counted by = isisCircRejAdjs." --- > Failures to form an adjacency are counted by=20 > isisCircRejAdjs." 2660c2619 < isisIPRANextHopIndex } --- > isisIPRANextHopIndex } 2671,2672c2630,2631 < isisIPRANextHopIndex < Integer32, --- > isisIPRANextHopIndex > Integer32, 2731c2690 < Cost Multipath alternatives for the same destination." --- > Cost Multipath alternatives for the same destination." 2870c2829,2830 < "Each entry describes an LSP currently stored in the = system." --- > "Each entry provides a summary describing an=20 > LSP currently stored in the system." 2982c2942,2943 < "Each entry describes an LSP current stored in the = system." --- > "Each entry describes an LSP current stored in the=20 > system." 3059c3020,3021 < isisNotificationEntry OBJECT IDENTIFIER ::=3D { isisNotification = 1 } --- > isisNotificationEntry OBJECT IDENTIFIER=20 > ::=3D { isisNotification 1 } 3092c3054,3055 < "Holds the Max Area Addresses reported in a PDU we = received." --- > "Holds the Max Area Addresses reported in a PDU=20 > we received." 3258,3261c3221 < PDUs received from what seem to be the same source. < This decision is up to the agent to make, and may < be based on the circuit or on some MAC level < information." --- > PDUs received on the same circuit." 3283c3243 < PDUs received from what seem to be the same source." --- > PDUs received from the same circuit." 3339c3299 < PDUs received from what seem to be the same source." --- > PDUs received from the same circuit." 3359c3319 < PDUs received from what seem to be the same source." --- > PDUs received from the same circuit." 3381,3384c3341 < PDUs received from what seem to be the same source. < This decision is up to the agent to make, and may < be based on the circuit or on some MAC level < information." --- > PDUs received from the same circuit." 3404,3407c3361 < PDUs received from what seem to be the same source. < This decision is up to the agent to make, and may < be based on the circuit or on some MAC level < information." --- > PDUs received from the same circuit." 3425c3379 < PDUs received from the same source." --- > PDUs received from the circuit." 3443c3397 < PDUs received from the same source." --- > PDUs received from the same circuit." 3467c3421 < PDUs received from the same source." --- > PDUs received from the same circuit." 3492c3446 < PDUs received from the same source." --- > PDUs received from the same circuit." 3530c3484 < If the problem is a mal-formed TLV, isisErrorOffset=20 --- > If the problem is a mal-formed TLV, isisErrorOffset=20 3534,3535c3488,3489 < If the problem is with the LSP header, isisErrorOffset < points to the suspicious byte. --- > If the problem is with the LSP header, isisErrorOffset > points to the suspicious byte. 3597,3599c3551 < isisSysLogAdjacencyChanges, < isisSysNextCircIndex, < isisSysExistState, --- > isisNextCircIndex, 3636c3588,3589 < "The collections of objects used to manage an IS-IS = router." --- > "The collections of objects used to manage an=20 > IS-IS router." 3680c3633,3634 < "The collection of objects used to describe in IS-IS = Circuit." --- > "The collection of objects used to describe in=20 > IS-IS Circuit." 3703c3657,3658 < "The collections of objects used to manage an IS-IS = Adjacency." --- > "The collections of objects used to manage an=20 > IS-IS Adjacency." ------_=_NextPart_000_01C45969.1AE4D8E0 Content-Type: text/plain; name="realdiffs.txt" Content-Disposition: attachment; filename="realdiffs.txt" Content-Transfer-Encoding: quoted-printable 8,9c12 < TEXTUAL-CONVENTION, DisplayString, RowStatus, TruthValue, < TestAndIncr --- > TEXTUAL-CONVENTION, RowStatus, TruthValue 11,12c14,15 < MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, = NOTIFICATION-TYPE, < Integer32, Unsigned32, Counter32, experimental, TimeTicks --- > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32,=20 > Counter32, experimental, TimeTicks, NOTIFICATION-TYPE 15a19,24 > SnmpAdminString > FROM SNMP-FRAMEWORK-MIB > IndexIntegerNextFree > FROM DIFFSERV-MIB > InterfaceIndex=20 > FROM IF-MIB 301c275,279 < SYNTAX DisplayString --- > SYNTAX INTEGER > { > unknown(0), > one(1) > } 308,309c286,287 < DEFVAL { "1" } < ::=3D { isisSysEntry 1 } --- > DEFVAL { one } > ::=3D { isisSysObject 1 } 357c335 < SYNTAX Integer32 (1..65535) --- > SYNTAX Integer32 (1..65235) 408,436c386 < ::=3D { isisSysEntry 8 } <=20 < isisSysLogAdjacencyChanges OBJECT-TYPE < SYNTAX TruthValue < MAX-ACCESS read-write < STATUS current < DESCRIPTION < "If true, causes IS-IS to generate a log message when an < IS-IS adjacency changes state (up or down)." < DEFVAL { false } < ::=3D { isisSysEntry 9 } <=20 < isisSysNextCircIndex OBJECT-TYPE < SYNTAX TestAndIncr < MAX-ACCESS read-only < STATUS current < DESCRIPTION < "This object is used to assign values to < isisCircIndex as described in 'Textual < Conventions for SNMPv2'. The network manager < reads this object, and then writes the value < back as the isisCircIndex in a SET that creates < a new instance of isisCircEntry. If the SET < fails with the code 'inconsistentValue', then < the process must be repeated; If the SET succeeds, < then the object is incremented, and the new < isisCircuit is created according to the manager's < directions." < ::=3D { isisSysEntry 10 } --- > ::=3D { isisSysObject 8 } 476,488c426 < ::=3D { isisSysEntry 13 } <=20 < isisSysExistState OBJECT-TYPE < SYNTAX RowStatus < MAX-ACCESS read-write < STATUS current < DESCRIPTION < "The state of the IS-IS router. Turning this to < state 'destroy' forces the router to forget all < the current configuration. Setting the state to < 'notInService' stops protocol processing, but < retains the configuration." < ::=3D { isisSysEntry 14 } --- > ::=3D { isisSysObject 11 } 871c806 < DisplayString, --- > SnmpAdminString, 893c828 < SYNTAX DisplayString --- > SYNTAX SnmpAdminString 1057a993,1013 >=20 > -- Static to provide next CircIndex >=20 > isisNextCircIndex OBJECT-TYPE > SYNTAX TestAndIncr > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object is used to assign values to > isisCircIndex as described in 'Textual > Conventions for SNMPv2'. The network manager > reads this object, and then writes the value > back as the isisCircIndex in a SET that creates > a new instance of isisCircEntry. If the SET > fails with the code 'inconsistentValue', then > the process must be repeated; If the SET succeeds, > then the object is incremented, and the new > isisCircuit is created according to the manager's > directions." > ::=3D { isisCirc 1 } >=20 1069,1071c1025,1027 < "The table of circuits used by each instance of < Integrated IS-IS on this system." < ::=3D { isisCirc 1 } --- > "The table of circuits used by this=20 > Intermediate System." > ::=3D { isisCirc 2 } 1088c1044 < Integer32, --- > InterfaceIndex, 1118c1074 < SYNTAX Integer32 --- > SYNTAX Integer32 (1..2147483647) 1130c1086 < SYNTAX Integer32 --- > SYNTAX InterfaceIndex=20 3597,3599c3551 < isisSysLogAdjacencyChanges, < isisSysNextCircIndex, < isisSysExistState, --- > isisNextCircIndex, ------_=_NextPart_000_01C45969.1AE4D8E0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_000_01C45969.1AE4D8E0-- From isis-wg-bounces@ietf.org Thu Jun 24 15:38:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19285 for ; Thu, 24 Jun 2004 15:38:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPt-0003cY-AB; Thu, 24 Jun 2004 12:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdFqi-0007oh-Ob for isis-wg@megatron.ietf.org; Wed, 23 Jun 2004 18:04:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21881 for ; Wed, 23 Jun 2004 18:04:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdFqg-0000Uz-Rh for isis-wg@ietf.org; Wed, 23 Jun 2004 18:04:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdFpk-00007q-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 18:03:09 -0400 Received: from web20606.mail.yahoo.com ([216.136.226.164]) by ietf-mx with smtp (Exim 4.12) id 1BdFoq-0007XM-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 18:02:12 -0400 Message-ID: <20040623220212.14321.qmail@web20606.mail.yahoo.com> Received: from [66.17.149.13] by web20606.mail.yahoo.com via HTTP; Wed, 23 Jun 2004 15:02:12 PDT Date: Wed, 23 Jun 2004 15:02:12 -0700 (PDT) From: Satish Dattatri Subject: Re: [Isis-wg] Checksum To: Ethan Burns , isis-wg@ietf.org In-Reply-To: <200406221729.i5MHTqeH025754@io.iol.unh.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --- Ethan Burns wrote: > Hello, > I was wondering if someone could help me. I am trying to implement the > checksum algorithem in the LSP packets of IS-IS. I am very confused > as to what values to use in the initialization of C0 and C1. Any help on > this > would be greatly appreciated. > > > --Ethan Burns-- Lookup 8473 Annex C for some detail explanation. The algorithm itself requires c0 and c1 to be initialized to 'zero'. However, 7.3.11 of ISO10589 mentions to keep c0 and c1 to be initialized to the values after calculating the algorithm upto the end of system-id. The reasoning is that if the system id gets corrupted and the IS generates LSP with bogus system-id the receiving IS will drop the pdu becoz of checksum mismatch. This kind of logic is flawed IMO becoz what if the system-id is not corrupted but the cached c0 and c1 values are .... I would just have the c0 and c1 initialized to zero and do the checksum. Satish _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 24 15:40:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19661 for ; Thu, 24 Jun 2004 15:40:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPv-0003dd-Tu; Thu, 24 Jun 2004 12:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdGTI-0001Pt-It for isis-wg@megatron.ietf.org; Wed, 23 Jun 2004 18:44:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25269 for ; Wed, 23 Jun 2004 18:43:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdGTG-00006K-U7 for isis-wg@ietf.org; Wed, 23 Jun 2004 18:43:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdGSV-0007Wg-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 18:43:11 -0400 Received: from mail.axiowave.com ([64.115.125.242] helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 1BdGRJ-0006o3-00 for isis-wg@ietf.org; Wed, 23 Jun 2004 18:41:57 -0400 Message-ID: From: Jeff Parker To: "ISIS-WG (E-mail)" Date: Wed, 23 Jun 2004 18:41:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Isis-wg] Version 16 of the MIB 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I have posted version 16 to the IETF, and send mail with the diffs to this list. I suspect that my mail message is waiting in a queue for a human to study the entrails, but should emerge soon. -- Changes in version 16 -- -- Restored range for isisSysMaxLSPGenInt -- Replaced DisplayString with SnmpAdminString, from RFC 2571 -- Move NextCircIndex out of System Table -- Note that this changes the OID for circuit table -- Removed traces in comments of sysInstance - jeff parker - axiowave networks - As scarce as truth is, the supply has always been in excess of the demand - Josh Billings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 24 19:24:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29505 for ; Thu, 24 Jun 2004 19:24:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddP6-0005SN-Fc; Thu, 24 Jun 2004 19:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdd9W-0007Bg-Vv for isis-wg@megatron.ietf.org; Thu, 24 Jun 2004 18:57:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25291 for ; Thu, 24 Jun 2004 18:57:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdd7Z-0005Wv-Vl for isis-wg@ietf.org; Thu, 24 Jun 2004 18:55:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdcTk-0004G2-00 for isis-wg@ietf.org; Thu, 24 Jun 2004 18:13:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx with esmtp (Exim 4.12) id 1Bdbj4-0002uy-00 for isis-wg@ietf.org; Thu, 24 Jun 2004 17:25:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 24 Jun 2004 17:32:03 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5OLPBGs009810; Thu, 24 Jun 2004 17:25:11 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-122.cisco.com [64.102.83.122]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAE41051; Thu, 24 Jun 2004 14:25:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20040624172052.025989a0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jun 2004 17:25:54 -0400 To: Satish Dattatri , Ethan Burns , isis-wg@ietf.org From: Jeff Learman Subject: Re: [Isis-wg] Checksum In-Reply-To: <20040623220212.14321.qmail@web20606.mail.yahoo.com> References: <200406221729.i5MHTqeH025754@io.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 06:02 PM 6/23/2004, Satish Dattatri wrote: >Lookup 8473 Annex C for some detail explanation. The algorithm itself requires >c0 and c1 to be initialized to 'zero'. > >However, 7.3.11 of ISO10589 mentions to keep c0 and c1 to be initialized to >the values after calculating the algorithm upto the end of system-id. >The reasoning is that if the system id gets corrupted and the IS generates >LSP with bogus system-id the receiving IS will drop the pdu becoz of >checksum mismatch. > >This kind of logic is flawed IMO becoz what if the system-id is not corrupted >but the cached c0 and c1 values are .... In that case all transmitted LSPs will be rejected. That's not a big problem. The problem is when one system sends LSPs that appear to be sent by another system, with a valid checksum. This has to be avoided at all costs, and the suggested method helps dramatically. Many of the "strange" features of ISIS are solutions to actual problems discovered in the Arpanet. Things are nasty when a flooding mechanism goes wild. I don't know whether this is one of those cases. The ugly sequence number system definitely is, and you can read about that in Radia Perlman's book, "Interconnections". Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 24 19:44:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02102 for ; Thu, 24 Jun 2004 19:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddmC-0005O8-Aq; Thu, 24 Jun 2004 19:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BddQI-0007Z6-Bj for isis-wg@megatron.ietf.org; Thu, 24 Jun 2004 19:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27612 for ; Thu, 24 Jun 2004 19:14:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BddOS-0002HC-Py for isis-wg@ietf.org; Thu, 24 Jun 2004 19:12:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdcx5-0003DA-00 for isis-wg@ietf.org; Thu, 24 Jun 2004 18:44:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BdcD8-00012R-00 for isis-wg@ietf.org; Thu, 24 Jun 2004 17:56:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2004 15:00:09 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5OLuEgI011053; Thu, 24 Jun 2004 14:56:15 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-38.cisco.com [128.107.163.38]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id ARU23271; Thu, 24 Jun 2004 14:55:45 -0700 (PDT) Message-Id: <4.3.2.7.2.20040624145017.01c9cb70@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jun 2004 14:57:10 -0700 To: Satish Dattatri From: Les Ginsberg Subject: Re: [Isis-wg] Checksum In-Reply-To: <20040623220212.14321.qmail@web20606.mail.yahoo.com> References: <200406221729.i5MHTqeH025754@io.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 03:02 PM 6/23/2004 -0700, Satish Dattatri wrote: >--- Ethan Burns wrote: > > Hello, > > I was wondering if someone could help me. I am trying to > implement the > > checksum algorithem in the LSP packets of IS-IS. I am very confused > > as to what values to use in the initialization of C0 and C1. Any help on > > this > > would be greatly appreciated. > > > > > > --Ethan Burns-- > >Lookup 8473 Annex C for some detail explanation. The algorithm itself requires >c0 and c1 to be initialized to 'zero'. > >However, 7.3.11 of ISO10589 mentions to keep c0 and c1 to be initialized to >the values after calculating the algorithm upto the end of system-id. >The reasoning is that if the system id gets corrupted and the IS generates >LSP with bogus system-id the receiving IS will drop the pdu becoz of >checksum mismatch. > >This kind of logic is flawed IMO becoz what if the system-id is not corrupted >but the cached c0 and c1 values are .... Satish - What happens is exactly what should happen when there is memory corruption. The checksum sent with the locally generated LSP will not be correct when validated at the receiving end - which means that receiver will not accept updates received from a corrupted box. Doesn't matter whether the corruption was in the stored system ID or on the precalculated checksum - either way the originator is not to be trusted. A prudent implementation would periodically validate that the stored precalculated checkum matches the stored system ID so that it would not continue operating indefinitely in a corrupted state. There are, of course, a number of ways to do this. :-) Les >I would just have the c0 and c1 initialized to zero and do the checksum. > >Satish > > >_______________________________________________ >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 Fri Jun 25 02:30:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10167 for ; Fri, 25 Jun 2004 02:30:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdk2e-00026A-C4; Fri, 25 Jun 2004 02:18:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdjxM-0007Jx-Q7 for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 02:13:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07811 for ; Fri, 25 Jun 2004 02:12:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdjxK-0003Gq-LE for isis-wg@ietf.org; Fri, 25 Jun 2004 02:12:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdjwX-0002x4-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 02:12:10 -0400 Received: from web20607.mail.yahoo.com ([216.136.226.165]) by ietf-mx with smtp (Exim 4.12) id 1Bdjw0-0002cF-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 02:11:36 -0400 Message-ID: <20040625061137.96897.qmail@web20607.mail.yahoo.com> Received: from [24.7.122.163] by web20607.mail.yahoo.com via HTTP; Thu, 24 Jun 2004 23:11:37 PDT Date: Thu, 24 Jun 2004 23:11:37 -0700 (PDT) From: Satish Dattatri Subject: Re: [Isis-wg] Checksum To: isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20040624172052.025989a0@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I have combined the last mails. --- Jeff Learman wrote: [my old mail] > >However, 7.3.11 of ISO10589 mentions to keep c0 and c1 to be initialized to > >the values after calculating the algorithm upto the end of system-id. > >The reasoning is that if the system id gets corrupted and the IS generates > >LSP with bogus system-id the receiving IS will drop the pdu becoz of > >checksum mismatch. [Jeff] > In that case all transmitted LSPs will be rejected. That's not a > big problem. The problem is when one system sends LSPs that appear > to be sent by another system, with a valid checksum. This has to > be avoided at all costs, and the suggested method helps dramatically. > [Les] > > What happens is exactly what should happen when there is memory corruption. > The checksum sent with the locally generated LSP will not be correct when > validated at the receiving end - which means that receiver will not accept > updates received from a corrupted box. Doesn't matter whether the > corruption was in the stored system ID or on the precalculated checksum - > either way the originator is not to be trusted. We all agree that the steps in the spec makes the IS generate packets with bad checksum as designed. The receiving IS will *drop* the pdu. If an implementation can detect that it's system-id is corrupted then it can take corrective actions rather than send these *bad* pdu's in the network. I am not comfortable with flooding bad packets and what is the guarantee that only system-id is corrupted ??? This is what is flawed, the spec assumes that there are situations where only system-id is corrupted. My example of c0 and c1 was not good. > > > >This kind of logic is flawed IMO becoz what if the system-id is not > corrupted > >but the cached c0 and c1 values are .... > [Jeff] > Many of the "strange" features of ISIS are solutions to actual problems > discovered in the Arpanet. Things are nasty when a flooding mechanism > goes wild. I don't know whether this is one of those cases. The ugly > sequence number system definitely is, and you can read about that in > Radia Perlman's book, "Interconnections". Nothing like a lesson from the actual network outage ;-) [Les] > > A prudent implementation would periodically validate that the stored > precalculated checkum matches the stored system ID so that it would not > continue operating indefinitely in a corrupted state. There are, of course, > a number of ways to do this. :-) > That is good, however I would prefer the implementation to take serious corrective action ;-) All in all if the spec said that system-id corruption is a serious issue and implementations should handle it. Further it could have mentioned the caching of c0 and c1 or protocol shutdown. Rather the spec mentions a solution as MUST be done this way. That is what I do not agree with. Satish _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 03:26:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13523 for ; Fri, 25 Jun 2004 03:26:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdkvG-0003GH-U4; Fri, 25 Jun 2004 03:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdkho-00078E-HL for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 03:01:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12494 for ; Fri, 25 Jun 2004 03:00:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdkhm-000502-D5 for isis-wg@ietf.org; Fri, 25 Jun 2004 03:00:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdkgm-0004eV-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 02:59:57 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1Bdkfn-0003xs-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 02:58:56 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5P6wQ920445; Thu, 24 Jun 2004 23:58:26 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5P6wKJ85947; Thu, 24 Jun 2004 23:58:20 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <20040625061137.96897.qmail@web20607.mail.yahoo.com> References: <20040625061137.96897.qmail@web20607.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0AEC9D2E-C675-11D8-9ED4-000A95A55D88@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] Checksum Date: Thu, 24 Jun 2004 23:58:20 -0700 To: Satish Dattatri X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 24, 2004, at 11:11 PM, Satish Dattatri wrote: > Rather the spec mentions a solution as MUST be done this way. That > is > what I do not agree with. > Regardless of what the spec says, you can implement it any way you want so long as what goes out on the wire is correct. You can precalculate the system ID into C0/C1, or leave it zero, or do whatever else you want to, so long as the proper checksum ends up in the outgoing packets. There are no implementation police to come audit your code; all that counts is interoperability and what shows up on the wire. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 04:12:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15609 for ; Fri, 25 Jun 2004 04:12:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdlbN-0007Au-JY; Fri, 25 Jun 2004 03:58:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdlHH-0001J4-HX for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 03:37:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14114 for ; Fri, 25 Jun 2004 03:37:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdlH3-0002Qc-I3 for isis-wg@ietf.org; Fri, 25 Jun 2004 03:37:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdlGO-00023e-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 03:36:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BdlFK-0001dY-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 03:35:38 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Jun 2004 00:38:58 +0000 X-BrightmailFiltered: true Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5P7Z6gI009336; Fri, 25 Jun 2004 00:35:06 -0700 (PDT) Received: from jharper-w2k.cisco.com (stealth-10-32-245-25.cisco.com [10.32.245.25]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id IAA24743; Fri, 25 Jun 2004 08:35:03 +0100 (BST) Message-Id: <4.3.2.7.2.20040625003132.0418f260@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Jun 2004 00:35:58 -0700 To: Dave Katz From: John Harper Subject: Re: [Isis-wg] Checksum In-Reply-To: <0AEC9D2E-C675-11D8-9ED4-000A95A55D88@juniper.net> References: <20040625061137.96897.qmail@web20607.mail.yahoo.com> <20040625061137.96897.qmail@web20607.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: Satish Dattatri , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Well, yes and no. Of course Dave is absolutely right from the point of view that there is no way that "they" can come and get you if you do it some different way. Otoh there was a reason behind the way it is specified, as previous posters have identified. Back when the protocol was defined, there was a lot of thought given to all the possible failure modes and how to limit their impact. So really the "must" should be interpreted as strong advice for how to build a sound implementation, given that it is not verifiable by black-box methods (well, we could expose your implementation to high density gamma rays and see what happened I suppose). Or it could be read as "if you really, really, really understand the thinking behind what is specified here, and you can figure out another way to achieve the same thing, that's fine. But if not, just do what the spec says and stop complaining". John At 11:58 PM 6/24/2004 -0700, Dave Katz wrote: >On Jun 24, 2004, at 11:11 PM, Satish Dattatri wrote: >>Rather the spec mentions a solution as MUST be done this way. That is >>what I do not agree with. > >Regardless of what the spec says, you can implement it any way you want so >long as what goes out on the wire is correct. You can precalculate the >system ID into C0/C1, or leave it zero, or do whatever else you want to, >so long as the proper checksum ends up in the outgoing packets. There are >no implementation police to come audit your code; >all that counts is interoperability and what shows up on the wire. > > >_______________________________________________ >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 Fri Jun 25 04:14:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15740 for ; Fri, 25 Jun 2004 04:14:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdlby-0007fC-UW; Fri, 25 Jun 2004 03:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdlSY-0003Pi-JT for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 03:49:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14834 for ; Fri, 25 Jun 2004 03:49:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdlSH-0006bp-AV for isis-wg@ietf.org; Fri, 25 Jun 2004 03:49:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdlRS-0006IC-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 03:48:11 -0400 Received: from web20626.mail.yahoo.com ([216.136.227.90]) by ietf-mx with smtp (Exim 4.12) id 1BdlQN-0005yH-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 03:47:03 -0400 Message-ID: <20040625074704.92403.qmail@web20626.mail.yahoo.com> Received: from [24.7.122.163] by web20626.mail.yahoo.com via HTTP; Fri, 25 Jun 2004 00:47:04 PDT Date: Fri, 25 Jun 2004 00:47:04 -0700 (PDT) From: Satish Dattatri Subject: Re: [Isis-wg] Checksum To: Dave Katz In-Reply-To: <0AEC9D2E-C675-11D8-9ED4-000A95A55D88@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --- Dave Katz wrote: > > On Jun 24, 2004, at 11:11 PM, Satish Dattatri wrote: > > Rather the spec mentions a solution as MUST be done this way. That > > is > > what I do not agree with. > > > > Regardless of what the spec says, you can implement it any way you want > so long as what goes out on the wire is correct. You can precalculate > the system ID into C0/C1, or leave it zero, or do whatever else you > want to, so long as the proper checksum ends up in the outgoing > packets. There are no implementation police to come audit your code; > all that counts is interoperability and what shows up on the wire. > Agree 100%. Still, is it not little odd that the specification says we will be extra careful about sytem-id corruption, however if it occurs let us flood bad packet. While writing the email, I did think about specification ("on the wire") and implementation separation, and your position on the same wrt OSPF and ISIS ;-) _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 04:36:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17006 for ; Fri, 25 Jun 2004 04:36:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdm6g-0006Dh-FG; Fri, 25 Jun 2004 04:30:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdlrf-0003Cp-GD for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 04:15:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15855 for ; Fri, 25 Jun 2004 04:15:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdlrd-0007DY-9f for isis-wg@ietf.org; Fri, 25 Jun 2004 04:15:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdlqe-0006or-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 04:14:13 -0400 Received: from web20628.mail.yahoo.com ([216.136.227.92]) by ietf-mx with smtp (Exim 4.12) id 1Bdlpp-0006RQ-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 04:13:21 -0400 Message-ID: <20040625081322.97978.qmail@web20628.mail.yahoo.com> Received: from [24.7.122.163] by web20628.mail.yahoo.com via HTTP; Fri, 25 Jun 2004 01:13:22 PDT Date: Fri, 25 Jun 2004 01:13:22 -0700 (PDT) From: Satish Dattatri Subject: Re: [Isis-wg] Checksum To: John Harper In-Reply-To: <4.3.2.7.2.20040625003132.0418f260@jaws.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --- John Harper wrote: > Well, yes and no. Of course Dave is absolutely right from the point of view > that > there is no way that "they" can come and get you if you do it some different > way. Otoh there was a reason behind the way it is specified, as previous > posters have identified. Back when the protocol was defined, there was a lot > of thought given to all the possible failure modes and how to limit their > impact. So really the "must" should be interpreted as strong advice for Exactly, isn't the impact much lower if the IS just gives up becoz of system-id corruption ... (I know I have repeated this, sorry) > how to build a sound implementation, given that it is not verifiable by > black-box methods (well, we could expose your implementation to > high density gamma rays and see what happened I suppose). > Or it could be read as "if you really, really, really understand the > thinking behind what is specified here, and you can figure out another > way to achieve the same thing, that's fine. But if not, just do what the > spec says and stop complaining". > I am not complaining ;-) But would be better if the spec said something along the lines of: - keep a cache of c0 and c1 based on the system-id. - later when generating checksum, do cksum until the system-id and verify the cached values of c0 and c1 with the newly computed ones. - if they are different then take corrective actions. (in summary: Find out if system-id is corrupted and if so take action) My concern being, what is specified in ISO10589 would lead a verbatim implementation to keep sending bad pdu's in this scenario. Limited impact would be if such a system gracefully shutdowns. How a system knows that it is insane, if at all it can come to that conclusion in various other corruption scenarios is beyond me. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 04:44:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17559 for ; Fri, 25 Jun 2004 04:44:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdmCr-0000xH-K6; Fri, 25 Jun 2004 04:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdm7E-0006Ib-Mo for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 04:31:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16754 for ; Fri, 25 Jun 2004 04:31:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdm7C-0004jQ-F3 for isis-wg@ietf.org; Fri, 25 Jun 2004 04:31:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdm6D-0004OT-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 04:30:18 -0400 Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bdm5U-0003vj-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 04:29:32 -0400 Received: from [192.168.1.3] (c-24-5-4-40.client.comcast.net[24.5.4.40]) by comcast.net (rwcrmhc13) with SMTP id <2004062508285601500cquuqe>; Fri, 25 Jun 2004 08:28:56 +0000 In-Reply-To: <4.3.2.7.2.20040625003132.0418f260@jaws.cisco.com> References: <20040625061137.96897.qmail@web20607.mail.yahoo.com> <20040625061137.96897.qmail@web20607.mail.yahoo.com> <4.3.2.7.2.20040625003132.0418f260@jaws.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Isis-wg] Checksum Date: Fri, 25 Jun 2004 01:30:23 -0700 To: John Harper X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Satish Dattatri , Dave Katz , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit The other exception is when Dave is the one doing your code review. ;-) Tony On Jun 25, 2004, at 12:35 AM, John Harper wrote: > Well, yes and no. Of course Dave is absolutely right from the point of > view that > there is no way that "they" can come and get you if you do it some > different > way. Otoh there was a reason behind the way it is specified, as > previous > posters have identified. Back when the protocol was defined, there was > a lot > of thought given to all the possible failure modes and how to limit > their > impact. So really the "must" should be interpreted as strong advice for > how to build a sound implementation, given that it is not verifiable by > black-box methods (well, we could expose your implementation to > high density gamma rays and see what happened I suppose). > Or it could be read as "if you really, really, really understand the > thinking behind what is specified here, and you can figure out another > way to achieve the same thing, that's fine. But if not, just do what > the > spec says and stop complaining". > > John > > At 11:58 PM 6/24/2004 -0700, Dave Katz wrote: > >> On Jun 24, 2004, at 11:11 PM, Satish Dattatri wrote: >>> Rather the spec mentions a solution as MUST be done this way. >>> That is >>> what I do not agree with. >> >> Regardless of what the spec says, you can implement it any way you >> want so long as what goes out on the wire is correct. You can >> precalculate the system ID into C0/C1, or leave it zero, or do >> whatever else you want to, so long as the proper checksum ends up in >> the outgoing packets. There are no implementation police to come >> audit your code; >> all that counts is interoperability and what shows up on the wire. >> >> >> _______________________________________________ >> 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 Fri Jun 25 12:34:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20329 for ; Fri, 25 Jun 2004 12:34:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdt7j-0003wZ-Je; Fri, 25 Jun 2004 12:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdt1B-0001HA-9d for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 11:53:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14409 for ; Fri, 25 Jun 2004 11:53:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdt1A-0007jf-EJ for isis-wg@ietf.org; Fri, 25 Jun 2004 11:53:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdsuK-0006C9-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 11:46:28 -0400 Received: from smtp2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 1Bdso8-0004dK-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 11:40:04 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp2.procket.com (8.12.8p1/8.12.1) with ESMTP id i5PHl5XS038710; Fri, 25 Jun 2004 10:47:05 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5PFcQd1028934; Fri, 25 Jun 2004 08:38:26 -0700 (PDT) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 25 Jun 2004 08:38:25 -0700 In-Reply-To: <20040617185155.T29575@kummer.juniper.net> References: <20040614170235.H11354@kummer.juniper.net><200405121412.KAA06827@ietf.org> <200405121412.KAA06827@ietf.org><5.2.1.1.1.20040617100610.00a8e430@customermail.easily.co.uk> <20040617185155.T29575@kummer.juniper.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt Date: Fri, 25 Jun 2004 08:38:01 -0700 To: "Kireeti Kompella" X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 25 Jun 2004 15:38:25.0996 (UTC) FILETIME=[74A328C0:01C45ACA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Jeff Learman , isis-wg@ietf.org, Philip Christian 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: > A poll of how many have implemented the 250 TLV as currently defined > may help sort out how to proceed .... > > Juniper hasn't (would you have guessed???) Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) and skip the compatibility octet, if at all possible. Rather than have everyone announce who hasn't implemented this draft, I would prefer that anyone who has and is against changing the TLV speak up. We can take a poll in San Diego as well. If no-one speaks up we should change the draft, put it in LC and get it published. Chris. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 14:15:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29727 for ; Fri, 25 Jun 2004 14:15:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdv60-0001Pd-TZ; Fri, 25 Jun 2004 14:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bduv9-0006NJ-7N for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 13:55:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28088 for ; Fri, 25 Jun 2004 13:55:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bduv8-0005VW-5w for isis-wg@ietf.org; Fri, 25 Jun 2004 13:55:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BduuA-0005By-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 13:54:27 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1Bdut8-0004Xr-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 13:53:22 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5PHqL922913; Fri, 25 Jun 2004 10:52:21 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5PHqGJ98004; Fri, 25 Jun 2004 10:52:16 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <4.3.2.7.2.20040625003132.0418f260@jaws.cisco.com> References: <20040625061137.96897.qmail@web20607.mail.yahoo.com> <20040625061137.96897.qmail@web20607.mail.yahoo.com> <4.3.2.7.2.20040625003132.0418f260@jaws.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65C4B124-C6D0-11D8-9ED4-000A95A55D88@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] Checksum Date: Fri, 25 Jun 2004 10:52:17 -0700 To: John Harper X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Satish Dattatri , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 25, 2004, at 12:35 AM, John Harper wrote: > Well, yes and no. Of course Dave is absolutely right from the point of > view that > there is no way that "they" can come and get you if you do it some > different > way. Otoh there was a reason behind the way it is specified, as > previous > posters have identified. Back when the protocol was defined, there was > a lot > of thought given to all the possible failure modes and how to limit > their > impact. So really the "must" should be interpreted as strong advice for > how to build a sound implementation, given that it is not verifiable by > black-box methods (well, we could expose your implementation to > high density gamma rays and see what happened I suppose). > Or it could be read as "if you really, really, really understand the > thinking behind what is specified here, and you can figure out another > way to achieve the same thing, that's fine. But if not, just do what > the > spec says and stop complaining". It's worth noting that at least one of these clever mechanisms led to disaster. The original (1992) 10589 said that if you received an LSP with a bad checksum, you were to purge it. The theory was that bad LSP checksums could only occur due to memory corruption in some machine in the network, so by purging the LSP the originator would be motivated to regenerate it and thus cause the corrupted copy to be flushed. Of course, sometime back in about 1996 a line card in UUnet had a rather bad problem--it would corrupt data while delivering the packets with valid datalink checksums. The neighbor started purging LSPs. Since, by definition, all LSPs must traverse all links, this led to a rather poorly behaved network (with all LSPs being continuously purged and regenerated.) Quite spectacular, for train wreck afficionados. This led to a widespread "violation" of the spec (though a fully interoperable one) to ignore LSPs with bad checksums, and I believe that this got changed in a defect report. Having said all that, this particular clever hack is, well, clever, and doesn't hurt anything (though it would hurt a lot more if the above change hadn't been made.) There are no magic bullets to fix all possible implementation problems; at best a protocol can try to protect the network in the face of a misbehaving system, but there is an assumption that everyone is playing by the rules. (ISIS makes this assumption a bit less than OSPF does, FWIW.) I'm pretty militant about what is normative and what is an implementation choice, and have been heard more than once snarling "it doesn't matter if what I send is out of spec, so long as you are required to do the right thing when you receive it!" (which is an ill-tempered way of saying "this is overspecified.") I don't recommend this attitude for everyone, however. ;-) _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 14:22:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00307 for ; Fri, 25 Jun 2004 14:22:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdvCI-00049s-FF; Fri, 25 Jun 2004 14:13:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdv3B-0000Wp-U5 for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 14:03:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28947 for ; Fri, 25 Jun 2004 14:03:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdv3A-0000lV-Nl for isis-wg@ietf.org; Fri, 25 Jun 2004 14:03:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdv1c-00005I-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 14:02:08 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx with esmtp (Exim 4.12) id 1Bdv0H-00077e-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 14:00:45 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i5PI0FBm037478; Fri, 25 Jun 2004 11:00:15 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5PI0FJ99438; Fri, 25 Jun 2004 11:00:15 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <20040625074704.92403.qmail@web20626.mail.yahoo.com> References: <20040625074704.92403.qmail@web20626.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8364844B-C6D1-11D8-9ED4-000A95A55D88@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] Checksum Date: Fri, 25 Jun 2004 11:00:16 -0700 To: Satish Dattatri X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 25, 2004, at 12:47 AM, Satish Dattatri wrote: > Agree 100%. Still, is it not little odd that the specification says > we will be extra careful about sytem-id corruption, however if it > occurs let us flood bad packet. Think of it as a distributed algorithm. ;-) There is nothing to stop you from periodically checksumming any or all of your internal state information if you want to be a better network citizen, but the sysid hack is a nice way to avoid filling the collective memory of the network with a bunch of bogus link state information that can't be traced to its originator (it's better to send bad LSPs and have them dropped by the immediate neighbors than it is to send bad LSPs and have them survive in everyone's databases.) I've seen situations with other protocols where identity got confused, and it's tough to debug (and difficult to find the perpetrator.) It was especially cool when a certain DV protocol with a large metric space had a bunch of routes counting to infinity (for weeks on end.) > > While writing the email, I did think about specification ("on the > wire") > and implementation separation, and your position on the same wrt > OSPF and ISIS ;-) Old habits die hard. ;-) --Dave _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 16:14:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07887 for ; Fri, 25 Jun 2004 16:14:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdx2t-0004h7-Pe; Fri, 25 Jun 2004 16:11:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdwv5-00014K-Bi for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 16:03:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07376 for ; Fri, 25 Jun 2004 16:03:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdwv4-0005Bt-1l for isis-wg@ietf.org; Fri, 25 Jun 2004 16:03:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdwu9-0004v5-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 16:02:33 -0400 Received: from web20625.mail.yahoo.com ([216.136.227.84]) by ietf-mx with smtp (Exim 4.12) id 1Bdwta-0004f4-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 16:01:58 -0400 Message-ID: <20040625200157.95532.qmail@web20625.mail.yahoo.com> Received: from [24.7.122.163] by web20625.mail.yahoo.com via HTTP; Fri, 25 Jun 2004 13:01:57 PDT Date: Fri, 25 Jun 2004 13:01:57 -0700 (PDT) From: Satish Dattatri Subject: Re: [Isis-wg] Checksum To: Dave Katz In-Reply-To: <8364844B-C6D1-11D8-9ED4-000A95A55D88@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --- Dave Katz wrote: > There is nothing to stop you from periodically checksumming any or all > of your internal state information if you want to be a better network > citizen, but the sysid hack is a nice way to avoid filling the > collective memory of the network with a bunch of bogus link state > information that can't be traced to its originator (it's better to send > bad LSPs and have them dropped by the immediate neighbors than it is to > send bad LSPs and have them survive in everyone's databases.) > Much better is for the box to not send bad LSPs, if it can avoid. And thanks for referring to it as "sysid hack". While calculating the checksum, it is straightforward for the box to compare the cached values of c0 and c1 with current value generated based on system-id and hence take corrective action. My nit here is, once there is corruption, unless it is temporary ;-) there is no reason to continue operating ... Maybe the dominant implementations already detect and take corrective action. Thanks Dave for sharing couple of history lessons. It always helps to learn from them. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jun 25 17:22:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14396 for ; Fri, 25 Jun 2004 17:22:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdxre-0007hB-0o; Fri, 25 Jun 2004 17:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdxcp-0001RW-Qf for isis-wg@megatron.ietf.org; Fri, 25 Jun 2004 16:48:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12629 for ; Fri, 25 Jun 2004 16:48:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdxco-00030V-El for isis-wg@ietf.org; Fri, 25 Jun 2004 16:48:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdxc1-0002hT-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 16:47:53 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1Bdxb3-00029B-00 for isis-wg@ietf.org; Fri, 25 Jun 2004 16:46:53 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i5PKkN923752; Fri, 25 Jun 2004 13:46:23 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.201] (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i5PKkHJ33574; Fri, 25 Jun 2004 13:46:18 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <20040625200157.95532.qmail@web20625.mail.yahoo.com> References: <20040625200157.95532.qmail@web20625.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [Isis-wg] Checksum Date: Fri, 25 Jun 2004 13:46:17 -0700 To: Satish Dattatri X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 25, 2004, at 1:01 PM, Satish Dattatri wrote: > --- Dave Katz wrote: >> There is nothing to stop you from periodically checksumming any or all >> of your internal state information if you want to be a better network >> citizen, but the sysid hack is a nice way to avoid filling the >> collective memory of the network with a bunch of bogus link state >> information that can't be traced to its originator (it's better to >> send >> bad LSPs and have them dropped by the immediate neighbors than it is >> to >> send bad LSPs and have them survive in everyone's databases.) >> > > Much better is for the box to not send bad LSPs, if it can avoid. Sure, but of course if there's a bad enough bug to cause bad LSPs, there's no telling if the code is sane enough to not send them. > And thanks for referring to it as "sysid hack". I meant it in the most affectionate way. ;-) > > While calculating the checksum, it is straightforward for the box to > compare the cached values of c0 and c1 with current value generated > based on system-id and hence take corrective action. I'm sure there are better ideas. The one listed in the spec is pretty much a zero-overhead way of helping protect the network, which is a useful thing. Implementors are free to be arbitrarily clever in their own ways. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Sat Jun 26 10:38:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11162 for ; Sat, 26 Jun 2004 10:38:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeEFw-0000iM-St; Sat, 26 Jun 2004 10:34:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeED0-0008PC-84 for isis-wg@megatron.ietf.org; Sat, 26 Jun 2004 10:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10746 for ; Sat, 26 Jun 2004 10:31:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeECz-0006iJ-1j for isis-wg@ietf.org; Sat, 26 Jun 2004 10:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeEC5-0006UR-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 10:30:13 -0400 Received: from dobropan.easily.co.uk ([217.206.220.18] helo=customermail2.easily.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BeEBK-0006FZ-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 10:29:26 -0400 Received: from [217.206.220.11] (HELO www.easilymail.co.uk) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with SMTP id 2745100; Sat, 26 Jun 2004 15:29:20 +0100 Received: from 82.44.189.18 (SquirrelMail authenticated user ee7a30ha8ykg) by www.easilymail.co.uk with HTTP; Sat, 26 Jun 2004 15:29:20 +0100 (BST) Message-ID: <1065.82.44.189.18.1088260160.squirrel@www.easilymail.co.uk> In-Reply-To: References: <20040614170235.H11354@kummer.juniper.net><200405121412.KAA06827@ietf. org><200405121412.KAA06827@ietf.org><5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk><20040617185155.T29575@kummer.juniper.net> Date: Sat, 26 Jun 2004 15:29:20 +0100 (BST) Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt From: "Philip Christian" To: "Christian Hopps" User-Agent: SquirrelMail/1.4.0-1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Cc: Kireeti Kompella , Jeff Learman , isis-wg@ietf.org, Philip Christian X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: philip.christian@christiantena.co.uk List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org what is the problem with 1 byte extra ? i wish that i had put it in from the start it makes us totally future proof it is no problem for an implementor because the software will be looking for a specific pattern of bytes, anything else it just ignores the pattern is just one byte longer now Philip > On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >> A poll of how many have implemented the 250 TLV as currently defined >> may help sort out how to proceed .... >> >> Juniper hasn't (would you have guessed???) > > Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) > and skip the compatibility octet, if at all possible. > > Rather than have everyone announce who hasn't implemented this draft, I > would prefer that anyone who has and is against changing the TLV speak > up. We can take a poll in San Diego as well. If no-one speaks up we > should change the draft, put it in LC and get it published. > > Chris. > > > _______________________________________________ > 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 26 11:34:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13823 for ; Sat, 26 Jun 2004 11:34:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFA6-0005dG-UD; Sat, 26 Jun 2004 11:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeF94-0005Q4-Gm for isis-wg@megatron.ietf.org; Sat, 26 Jun 2004 11:31:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13755 for ; Sat, 26 Jun 2004 11:31:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeF93-0005wL-Ls for isis-wg@ietf.org; Sat, 26 Jun 2004 11:31:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeF89-0005iS-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:30:13 -0400 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1BeF7c-0005Te-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:29:40 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i5QHefuH090511; Sat, 26 Jun 2004 10:40:41 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5QFSEd1001146; Sat, 26 Jun 2004 08:28:14 -0700 (PDT) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 26 Jun 2004 08:28:14 -0700 In-Reply-To: <1065.82.44.189.18.1088260160.squirrel@www.easilymail.co.uk> References: <20040614170235.H11354@kummer.juniper.net><200405121412.KAA06827@ietf. org><200405121412.KAA06827@ietf.org><5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk><20040617185155.T29575@kummer.juniper.net> <1065.82.44.189.18.1088260160.squirrel@www.easilymail.co.uk> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6FF741B6-C785-11D8-8570-00039303E9E2@procket.com> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt Date: Sat, 26 Jun 2004 08:28:13 -0700 To: X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 26 Jun 2004 15:28:14.0163 (UTC) FILETIME=[325E9A30:01C45B92] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,SUBJ_HAS_SPACES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , Jeff Learman , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 26, 2004, at 7:29 AM, Philip Christian wrote: > what is the problem with 1 byte extra ? > > i wish that i had put it in from the start > > it makes us totally future proof TLV code points handle this level of future proofing just fine. > it is no problem for an implementor because the software will be > looking > for a specific pattern of bytes, anything else it just ignores > > the pattern is just one byte longer now It's not about TLV space, it's about the design. I (and others who should feel free to speak up) don't see any reason to have multiple types of differentiators. The problem being solved is simple why not keep the solution simple as well? Chris. > Philip > > >> On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >>> A poll of how many have implemented the 250 TLV as currently defined >>> may help sort out how to proceed .... >>> >>> Juniper hasn't (would you have guessed???) >> >> Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) >> and skip the compatibility octet, if at all possible. >> >> Rather than have everyone announce who hasn't implemented this draft, >> I >> would prefer that anyone who has and is against changing the TLV speak >> up. We can take a poll in San Diego as well. If no-one speaks up we >> should change the draft, put it in LC and get it published. >> >> Chris. >> >> >> _______________________________________________ >> 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 26 11:43:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14100 for ; Sat, 26 Jun 2004 11:43:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFJF-0007hY-5h; Sat, 26 Jun 2004 11:41:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFHm-0007FI-3Q for isis-wg@megatron.ietf.org; Sat, 26 Jun 2004 11:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14021 for ; Sat, 26 Jun 2004 11:40:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeFHl-0000Kc-B1 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:40:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeFGt-000060-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:39:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BeFG6-0007QI-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:38:26 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2004 11:37:32 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5QFbq6k027724; Sat, 26 Jun 2004 11:37:52 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn2-258.cisco.com [10.82.241.2]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAF37952; Sat, 26 Jun 2004 08:37:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20040626113635.0249b6b8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jun 2004 11:38:47 -0400 To: philip.christian@christiantena.co.uk, "Christian Hopps" From: Jeff Learman Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <1065.82.44.189.18.1088260160.squirrel@www.easilymail.co.uk > References: <20040614170235.H11354@kummer.juniper.net> <200405121412.KAA06827@ietf. org> <200405121412.KAA06827@ietf.org> <5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk> <20040617185155.T29575@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: Kireeti Kompella , isis-wg@ietf.org, Philip Christian 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org I agree that there should be a byte code to identify the kind of number that follows. Whether it needs to be backwards compatible with OUIs is another matter and I have no strong opinion about that. Note that I don't speak for Cisco here, just my $0.02. Jeff At 10:29 AM 6/26/2004, Philip Christian wrote: >what is the problem with 1 byte extra ? > >i wish that i had put it in from the start > >it makes us totally future proof > >it is no problem for an implementor because the software will be looking >for a specific pattern of bytes, anything else it just ignores > >the pattern is just one byte longer now > >Philip > > >> On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >>> A poll of how many have implemented the 250 TLV as currently defined >>> may help sort out how to proceed .... >>> >>> Juniper hasn't (would you have guessed???) >> >> Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) >> and skip the compatibility octet, if at all possible. >> >> Rather than have everyone announce who hasn't implemented this draft, I >> would prefer that anyone who has and is against changing the TLV speak >> up. We can take a poll in San Diego as well. If no-one speaks up we >> should change the draft, put it in LC and get it published. >> >> Chris. >> >> >> _______________________________________________ >> 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 26 11:51:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14398 for ; Sat, 26 Jun 2004 11:51:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFNq-0000Wm-Tz; Sat, 26 Jun 2004 11:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFJu-00081z-AI for isis-wg@megatron.ietf.org; Sat, 26 Jun 2004 11:42:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14076 for ; Sat, 26 Jun 2004 11:42:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeFJt-0000oZ-Ha for isis-wg@ietf.org; Sat, 26 Jun 2004 11:42:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeFIr-0000aG-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:41:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx with esmtp (Exim 4.12) id 1BeFII-0000LD-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:40:42 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Jun 2004 11:39:48 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i5QFeAGs022791; Sat, 26 Jun 2004 11:40:11 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn2-258.cisco.com [10.82.241.2]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BAF37986; Sat, 26 Jun 2004 08:40:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20040626113906.0255fab0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 26 Jun 2004 11:40:59 -0400 To: Christian Hopps , From: Jeff Learman Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <6FF741B6-C785-11D8-8570-00039303E9E2@procket.com> References: <1065.82.44.189.18.1088260160.squirrel@www.easilymail.co.uk> <20040614170235.H11354@kummer.juniper.net> <200405121412.KAA06827@ietf. org> <200405121412.KAA06827@ietf.org> <5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk> <20040617185155.T29575@kummer.juniper.net> <1065.82.44.189.18.1088260160.squirrel@www.easilymail.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: Kireeti Kompella , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org At 11:28 AM 6/26/2004, Christian Hopps wrote: >On Jun 26, 2004, at 7:29 AM, Philip Christian wrote: > >>what is the problem with 1 byte extra ? >> >>i wish that i had put it in from the start >> >>it makes us totally future proof > >TLV code points handle this level of future proofing just fine. If that's the case, then we should assign another TLV code for SNMP IDs. Jeff >>it is no problem for an implementor because the software will be looking >>for a specific pattern of bytes, anything else it just ignores >> >>the pattern is just one byte longer now > >It's not about TLV space, it's about the design. I (and others who should feel free to speak up) don't see any reason to have multiple types of differentiators. The problem being solved is simple why not keep the solution simple as well? > >Chris. > >>Philip >> >> >>>On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >>>>A poll of how many have implemented the 250 TLV as currently defined >>>>may help sort out how to proceed .... >>>> >>>>Juniper hasn't (would you have guessed???) >>> >>>Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) >>>and skip the compatibility octet, if at all possible. >>> >>>Rather than have everyone announce who hasn't implemented this draft, I >>>would prefer that anyone who has and is against changing the TLV speak >>>up. We can take a poll in San Diego as well. If no-one speaks up we >>>should change the draft, put it in LC and get it published. >>> >>>Chris. >>> >>> >>>_______________________________________________ >>>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 26 11:55:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14562 for ; Sat, 26 Jun 2004 11:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFVL-0002Fj-OV; Sat, 26 Jun 2004 11:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeFTR-0001Z8-Fm for isis-wg@megatron.ietf.org; Sat, 26 Jun 2004 11:52:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14433 for ; Sat, 26 Jun 2004 11:52:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeFTQ-0003GS-MY for isis-wg@ietf.org; Sat, 26 Jun 2004 11:52:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeFSW-00032F-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:51:16 -0400 Received: from smtp1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 1BeFRs-0002Zd-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 11:50:36 -0400 Received: from miata.procket.com (mil0-fw00-d-1.procket.com [65.174.124.60]) by smtp1.procket.com (8.12.8p1/8.12.1) with ESMTP id i5QI1JuH090650; Sat, 26 Jun 2004 11:01:19 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id i5QFmqd1001421; Sat, 26 Jun 2004 08:48:52 -0700 (PDT) Received: from [127.0.0.1] ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 26 Jun 2004 08:48:52 -0700 In-Reply-To: <4.3.2.7.2.20040626113635.0249b6b8@dingdong.cisco.com> References: <20040614170235.H11354@kummer.juniper.net> <200405121412.KAA06827@ietf. org> <200405121412.KAA06827@ietf.org> <5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk> <20040617185155.T29575@kummer.juniper.net> <4.3.2.7.2.20040626113635.0249b6b8@dingdong.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51C522C3-C788-11D8-8570-00039303E9E2@procket.com> Content-Transfer-Encoding: 7bit From: Christian Hopps Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt Date: Sat, 26 Jun 2004 08:48:50 -0700 To: "Jeff Learman" X-Mailer: Apple Mail (2.618) X-OriginalArrivalTime: 26 Jun 2004 15:48:52.0359 (UTC) FILETIME=[14645170:01C45B95] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , isis-wg@ietf.org, philip.christian@christiantena.co.uk 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Jun 26, 2004, at 8:38 AM, Jeff Learman wrote: > > I agree that there should be a byte code to identify the kind > of number that follows. Whether it needs to be backwards compatible > with OUIs is another matter and I have no strong opinion about > that. Why? Chris. > > Note that I don't speak for Cisco here, just my $0.02. > > Jeff > > At 10:29 AM 6/26/2004, Philip Christian wrote: >> what is the problem with 1 byte extra ? >> >> i wish that i had put it in from the start >> >> it makes us totally future proof >> >> it is no problem for an implementor because the software will be >> looking >> for a specific pattern of bytes, anything else it just ignores >> >> the pattern is just one byte longer now >> >> Philip >> >> >>> On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >>>> A poll of how many have implemented the 250 TLV as currently defined >>>> may help sort out how to proceed .... >>>> >>>> Juniper hasn't (would you have guessed???) >>> >>> Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) >>> and skip the compatibility octet, if at all possible. >>> >>> Rather than have everyone announce who hasn't implemented this >>> draft, I >>> would prefer that anyone who has and is against changing the TLV >>> speak >>> up. We can take a poll in San Diego as well. If no-one speaks up we >>> should change the draft, put it in LC and get it published. >>> >>> Chris. >>> >>> >>> _______________________________________________ >>> 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 26 14:57:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22987 for ; Sat, 26 Jun 2004 14:57:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeIJC-0000ug-Bg; Sat, 26 Jun 2004 14:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BeIFn-0008Nj-SN for isis-wg@megatron.ietf.org; Sat, 26 Jun 2004 14:50:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22796 for ; Sat, 26 Jun 2004 14:50:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BeIFm-0007Ru-HB for isis-wg@ietf.org; Sat, 26 Jun 2004 14:50:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeIEr-0007ER-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 14:49:21 -0400 Received: from dobropan.easily.co.uk ([217.206.220.18] helo=customermail2.easily.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BeIE8-00070y-00 for isis-wg@ietf.org; Sat, 26 Jun 2004 14:48:36 -0400 Received: from [217.206.220.11] (HELO www.easilymail.co.uk) by customermail2.easily.co.uk (CommuniGate Pro SMTP 4.1.8) with SMTP id 2747995; Sat, 26 Jun 2004 19:48:32 +0100 Received: from 82.44.189.18 (SquirrelMail authenticated user ee7a30ha8ykg) by www.easilymail.co.uk with HTTP; Sat, 26 Jun 2004 19:48:32 +0100 (BST) Message-ID: <1208.82.44.189.18.1088275712.squirrel@www.easilymail.co.uk> In-Reply-To: <6FF741B6-C785-11D8-8570-00039303E9E2@procket.com> References: <20040614170235.H11354@kummer.juniper.net><200405121412.KAA06827@ietf. org><200405121412.KAA06827@ietf.org><5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk><20040617185155.T29575@kummer.juniper.net>< A4668A06-C6BD-11D8-B948-00039303E9E2@procket.com><1065.82.44.189.18.10 88260160.squirrel@www.easilymail.co.uk> <6FF741B6-C785-11D8-8570-00039303E9E2@procket.com> Date: Sat, 26 Jun 2004 19:48:32 +0100 (BST) Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt From: "Philip Christian" To: "Christian Hopps" , truskows@cisco.com User-Agent: SquirrelMail/1.4.0-1.7.x MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 Cc: Kireeti Kompella , Jeff Learman , isis-wg@ietf.org, philip.christian@christiantena.co.uk X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: philip.christian@christiantena.co.uk List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Under my proposal an implementor can put 193+OUI or 194+SNMP EC that is a simple solution I don't understand why anyone would object I don't think that there is any lack of simplicity I am including Mike because he was the one originally who asked for OUIs. If Mike want OUIs and Juniper want SNMP ECs then it seems to me the simplest way to please both. Regards, Philip > > On Jun 26, 2004, at 7:29 AM, Philip Christian wrote: > >> what is the problem with 1 byte extra ? >> >> i wish that i had put it in from the start >> >> it makes us totally future proof > > TLV code points handle this level of future proofing just fine. > >> it is no problem for an implementor because the software will be >> looking >> for a specific pattern of bytes, anything else it just ignores >> >> the pattern is just one byte longer now > > It's not about TLV space, it's about the design. I (and others who > should feel free to speak up) don't see any reason to have multiple > types of differentiators. The problem being solved is simple why not > keep the solution simple as well? > > Chris. > >> Philip >> >> >>> On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >>>> A poll of how many have implemented the 250 TLV as currently defined >>>> may help sort out how to proceed .... >>>> >>>> Juniper hasn't (would you have guessed???) >>> >>> Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) >>> and skip the compatibility octet, if at all possible. >>> >>> Rather than have everyone announce who hasn't implemented this draft, >>> I >>> would prefer that anyone who has and is against changing the TLV speak >>> up. We can take a poll in San Diego as well. If no-one speaks up we >>> should change the draft, put it in LC and get it published. >>> >>> Chris. >>> >>> >>> _______________________________________________ >>> 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 Mon Jun 28 16:48:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02997 for ; Mon, 28 Jun 2004 16:48:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1xs-0000xd-9t; Mon, 28 Jun 2004 15:38:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf1rV-0000AF-6r; Mon, 28 Jun 2004 15:32:17 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25604; Mon, 28 Jun 2004 15:32:14 -0400 (EDT) Message-Id: <200406281932.PAA25604@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 28 Jun 2004 15:32:14 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-07.txt 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: , 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 : M-ISIS: Multi Topology (MT)Routing in IS-IS Author(s) : T. Przygienda, et al. Filename : draft-ietf-isis-wg-multi-topology-07.txt Pages : 12 Date : 2004-6-25 This draft describes an optional mechanism within ISIS used today by many ISPs for IGP routing within their clouds. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for variety of purposes such as an in-band management network ``on top'' of the original IGP topology, maintain separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or force a subset of an address space to follow a different topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-07.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-multi-topology-07.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-multi-topology-07.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: <2004-6-28151232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151232.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Mon Jun 28 19:37:02 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23828 for ; Mon, 28 Jun 2004 19:37:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf5T9-00009v-0M; Mon, 28 Jun 2004 19:23:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf5G8-0004Fx-PV for isis-wg@megatron.ietf.org; Mon, 28 Jun 2004 19:09:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21419 for ; Mon, 28 Jun 2004 19:09:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf5G7-0007fB-BZ for isis-wg@ietf.org; Mon, 28 Jun 2004 19:09:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf5DC-0006lz-00 for isis-wg@ietf.org; Mon, 28 Jun 2004 19:06:55 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Bf58Z-0005aZ-00 for isis-wg@ietf.org; Mon, 28 Jun 2004 19:02:07 -0400 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bf58O-000Oxd-Sp; Mon, 28 Jun 2004 23:01:56 +0000 Date: Mon, 28 Jun 2004 16:01:54 -0700 From: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1416796790.20040628160154@psg.com> To: "Philip Christian" Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <1208.82.44.189.18.1088275712.squirrel@www.easilymail.co.uk> References: <20040614170235.H11354@kummer.juniper.net><200405121412.KAA06827@ietf. org><200405121412.KAA06827@ietf.org><5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk><20040617185155.T29575@kummer.juniper.net>< A4668A06-C6BD-11D8-B948-00039303E9E2@procket.com><1065.82.44.189.18.10 88260160.squirrel@www.easilymail.co.uk> <6FF741B6-C785-11D8-8570-00039303E9E2@procket.com> <1208.82.44.189.18.1088275712.squirrel@www.easilymail.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: truskows@cisco.com, Kireeti Kompella , Christian Hopps , isis-wg@ietf.org, Jeff Learman X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Zinin List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Content-Transfer-Encoding: 7bit Philip, guys- Could someone please explain the _technical_ reason for two numbering schemes, while only one is both required and sufficient for interoperability? -- Alex http://www.psg.com/~zinin Saturday, June 26, 2004, 11:48:32 AM, Philip Christian wrote: > Under my proposal an implementor can put > 193+OUI > or > 194+SNMP EC > that is a simple solution > I don't understand why anyone would object > I don't think that there is any lack of simplicity > I am including Mike because he was the one originally who asked for OUIs. > If Mike want OUIs and Juniper want SNMP ECs then it seems to me the > simplest way to please both. > Regards, Philip >> >> On Jun 26, 2004, at 7:29 AM, Philip Christian wrote: >> >>> what is the problem with 1 byte extra ? >>> >>> i wish that i had put it in from the start >>> >>> it makes us totally future proof >> >> TLV code points handle this level of future proofing just fine. >> >>> it is no problem for an implementor because the software will be >>> looking >>> for a specific pattern of bytes, anything else it just ignores >>> >>> the pattern is just one byte longer now >> >> It's not about TLV space, it's about the design. I (and others who >> should feel free to speak up) don't see any reason to have multiple >> types of differentiators. The problem being solved is simple why not >> keep the solution simple as well? >> >> Chris. >> >>> Philip >>> >>> >>>> On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: >>>>> A poll of how many have implemented the 250 TLV as currently defined >>>>> may help sort out how to proceed .... >>>>> >>>>> Juniper hasn't (would you have guessed???) >>>> >>>> Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) >>>> and skip the compatibility octet, if at all possible. >>>> >>>> Rather than have everyone announce who hasn't implemented this draft, >>>> I >>>> would prefer that anyone who has and is against changing the TLV speak >>>> up. We can take a poll in San Diego as well. If no-one speaks up we >>>> should change the draft, put it in LC and get it published. >>>> >>>> Chris. >>>> >>>> >>>> _______________________________________________ >>>> 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 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Jun 29 06:37:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09889 for ; Tue, 29 Jun 2004 06:37:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfFqr-0006Zf-La; Tue, 29 Jun 2004 06:28:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfFnd-0006Gd-RB for isis-wg@megatron.ietf.org; Tue, 29 Jun 2004 06:25:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09155 for ; Tue, 29 Jun 2004 06:25:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfFnb-0005Gt-2D for isis-wg@ietf.org; Tue, 29 Jun 2004 06:25:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfFmX-0004vh-00 for isis-wg@ietf.org; Tue, 29 Jun 2004 06:24:06 -0400 Received: from mercury0.easily.co.uk ([213.161.76.90] helo=easily.co.uk) by ietf-mx with esmtp (Exim 4.12) id 1BfFlW-0004bd-00 for isis-wg@ietf.org; Tue, 29 Jun 2004 06:23:03 -0400 Received: from [149.254.200.215] (account ee7a30ha8ykg HELO pchristi.christiantena.co.uk) by easily.co.uk (CommuniGate Pro SMTP 4.1.3) with ESMTP id 73915862; Tue, 29 Jun 2004 11:22:57 +0100 Message-Id: <5.2.1.1.1.20040629111851.00aa6a28@customermail.easily.co.uk> X-Sender: ee7a30ha8ykg@customermail.easily.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 29 Jun 2004 11:32:51 +0100 To: Alex Zinin From: Philip Christian Subject: Re: [Isis-wg] Re: I-D ACTION:draft-ietf-isis-experimental-tlv-03.txt In-Reply-To: <1416796790.20040628160154@psg.com> References: <1208.82.44.189.18.1088275712.squirrel@www.easilymail.co.uk> <20040614170235.H11354@kummer.juniper.net> <200405121412.KAA06827@ietf. org> <200405121412.KAA06827@ietf.org> <5.2.1.1.1.20040617100610.00a8e430 @customermail.easily.co.uk> <20040617185155.T29575@kummer.juniper.net> < A4668A06-C6BD-11D8-B948-00039303E9E2@procket.com> <1065.82.44.189.18.10 88260160.squirrel@www.easilymail.co.uk> <6FF741B6-C785-11D8-8570-00039303E9E2@procket.com> <1208.82.44.189.18.1088275712.squirrel@www.easilymail.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-675539BD; boundary="=======412551A1=======" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: truskows@cisco.com, Kireeti Kompella , Christian Hopps , isis-wg@ietf.org, Jeff Learman 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: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --=======412551A1======= Content-Type: text/plain; x-avg-checked=avg-ok-675539BD; charset=us-ascii; format=flowed Content-Transfer-Encoding: 8bit There isn't one. It pragmatic / procedural decision. I don't know enough about SNMP IDs to know how easy they are to get, how much they cost, if they will ever run out, and if they will always be four bytes. I guess four bytes is a lot of numbers.... The next question is whether anyone has used the OUI scheme, and therefore whether there can be an interop problem if an SNMP ID could be used in the future the first three bytes of which look like an OUI. If no-one has implemented then I guess that there is no problem there. If someone has implemented then we would have to put a byte in front of the SNMP ID anyway to avoid confusion. Maybe if someone has implemented the OUI scheme, or is about to then they could let me know in confidence and then at least I could state that someone has done it without saying who. Personally I don't really care what the solution is. I suggested the extra byte and allow both because I thought that it would be acceptable to both parties. There seems no technical reason NOT to allow both either, so why not? I can't see what harm it would do. And who knows what vendor identication scheme might become fashionable in the future? An extra byte will make life very easy to cope with it. Extensibility is a good thing, isn't it? maybe that is a technical argument after all.... Regards, Philip At 16:01 28/06/2004 -0700, Alex Zinin wrote: >Philip, guys- > > Could someone please explain the _technical_ reason for two numbering > schemes, > while only one is both required and sufficient for interoperability? > >-- >Alex >http://www.psg.com/~zinin > >Saturday, June 26, 2004, 11:48:32 AM, Philip Christian wrote: > > Under my proposal an implementor can put > > 193+OUI > > or > > 194+SNMP EC > > > that is a simple solution > > > I don't understand why anyone would object > > > I don't think that there is any lack of simplicity > > > I am including Mike because he was the one originally who asked for OUIs. > > If Mike want OUIs and Juniper want SNMP ECs then it seems to me the > > simplest way to please both. > > > Regards, Philip > > > > > >> > >> On Jun 26, 2004, at 7:29 AM, Philip Christian wrote: > >> > >>> what is the problem with 1 byte extra ? > >>> > >>> i wish that i had put it in from the start > >>> > >>> it makes us totally future proof > >> > >> TLV code points handle this level of future proofing just fine. > >> > >>> it is no problem for an implementor because the software will be > >>> looking > >>> for a specific pattern of bytes, anything else it just ignores > >>> > >>> the pattern is just one byte longer now > >> > >> It's not about TLV space, it's about the design. I (and others who > >> should feel free to speak up) don't see any reason to have multiple > >> types of differentiators. The problem being solved is simple why not > >> keep the solution simple as well? > >> > >> Chris. > >> > >>> Philip > >>> > >>> > >>>> On Jun 17, 2004, at 7:03 PM, Kireeti Kompella wrote: > >>>>> A poll of how many have implemented the 250 TLV as currently defined > >>>>> may help sort out how to proceed .... > >>>>> > >>>>> Juniper hasn't (would you have guessed???) > >>>> > >>>> Indeed, I would prefer we just switch to SNMP ECs (and not use OUIs) > >>>> and skip the compatibility octet, if at all possible. > >>>> > >>>> Rather than have everyone announce who hasn't implemented this draft, > >>>> I > >>>> would prefer that anyone who has and is against changing the TLV speak > >>>> up. We can take a poll in San Diego as well. If no-one speaks up we > >>>> should change the draft, put it in LC and get it published. > >>>> > >>>> Chris. > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004 --=======412551A1======= Content-Type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-675539BD Content-Disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004 --=======412551A1======= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --=======412551A1=======--