From isis-wg-bounces@ietf.org Sun Apr 3 00:47:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26049 for ; Sun, 3 Apr 2005 00:47:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHxwS-00087x-K4; Sun, 03 Apr 2005 00:46:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHxwJ-00087k-TC for isis-wg@megatron.ietf.org; Sun, 03 Apr 2005 00:46:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25959 for ; Sun, 3 Apr 2005 00:46:24 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHy3z-0008CN-Kw for isis-wg@ietf.org; Sun, 03 Apr 2005 00:54:24 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2005 21:46:18 -0800 Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j335k83S003570; Sat, 2 Apr 2005 21:46:09 -0800 (PST) Message-ID: <424F8321.9040103@cisco.com> Date: Sat, 02 Apr 2005 21:46:09 -0800 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Ward , christian Hopps Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-09.txt References: <200503232112.QAA05278@ietf.org> <4241E39A.5010906@cisco.com> In-Reply-To: <4241E39A.5010906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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 Dave & Chris, Can you issue a LC on the draft? Just want to add here the reasons of the change in the latest version I mentioned below: on a LAN, if an interface is configured of running ISIS level-1-2, there is a possibility that the MT set in L1 IIH is different from the MT set in L2 IIH, thus it's possible to have two routers on the LAN form different MT set of adjacency between the L1 and L2. For example, R1 advertises MT a and MT b in both L1 and L2 IIHs, but R2 advertises MT a in L1 IIHs, MT a and MT b in L2 IIHs. It forms a L1/L2 boundary for MT b, but not for MT a. From spec point of view, this is nothing wrong. Since each MT carries it's own ATT bit and each MT calculates it's own routes, there is no need to make the L1/L2 alignment for all the MTs. Thus we removed the sentence "boundaries between levels will be the same for all MTs." in the latest version of the draft. Thanks to Les who raised this issue. Although I don't see any reason to make the boundaries differently for the MTs, as far as I know of, none of the current implementations allows users configuring MT set differently for the two levels. But it's an implementation and configuration choice. thanks. - Naiming Naiming Shen wrote: > Hi working-group, > > We have updated the M-ISIS draft, the main change is to remove > the wording of aligning isis L1/L2 boundary for all topologies. > A diff is attached, please send comments if you have any. > > thanks. > - Naiming > > 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 : M-ISIS: Multi Topology (MT)Routing in IS-IS >> Author(s) : T. Przygienda, et al. >> Filename : draft-ietf-isis-wg-multi-topology-09.txt >> Pages : 12 >> Date : 2005-3-23 >> >> 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-09.txt >> >> > > ------------------------------------------------------------------------ > > *** draft-ietf-isis-wg-multi-topology-08.txt Wed Mar 16 19:15:21 2005 > --- draft-ietf-isis-wg-multi-topology-09.txt Fri Mar 18 11:36:38 2005 > *************** > *** 1,9 **** > > Network Working Group Tony Przygienda (Xebeo) > Internet Draft Naiming Shen (Cisco) > ! Nischal Sheth (Juniper) > March 2005 > Expires: September 2005 > > > M-ISIS: Multi Topology (MT) Routing in IS-IS > --- 1,9 ---- > > Network Working Group Tony Przygienda (Xebeo) > Internet Draft Naiming Shen (Cisco) > ! Nischal Sheth (Juniper) > March 2005 > Expires: September 2005 > > > M-ISIS: Multi Topology (MT) Routing in IS-IS > *************** Internet Draft M-ISIS > *** 82,94 **** > advertise it in the new TLV. Thus not including such a TLV in the > IIH implies MT ID #0 capability only. Through this exchange of MT > capabilities, a router is able to advertise the IS TLVs in LSPs > with common MT set over those adjacencies. > > - As a simplifying side-effect, boundaries between levels will be the > - same for all MTs. > - > In the case of adjacency contains multiple MTs on an interface, and > if there exists overlapping IP address space among the topologies, > additional mechanism MAY be used to resolve the topology identity of > the incoming IP packets on the interface. > > --- 82,91 ---- > *************** Internet Draft M-ISIS > *** 96,110 **** > > Adjacencies on point-to-point interfaces are formed as usual with > ISIS routers not implementing MT extensions. If local router does > not participate in certain MTs, it will not advertise those MTIDs > in it's IIHs and thus will not include that neighbor within it's > ! topology based LSPs. On the other hand, if a MTID is not > ! detected in remote side's IIHs, the local router MUST NOT include > ! that neighbor within it's MT LSPs. The local router SHOULD NOT form > ! adjacency if they don't have at least one common MT set over the > ! interface. > > 5.2. Forming Adjacencies on Broadcast Interfaces > > On a LAN, all the routers on the LAN which implement the MT > extension MAY advertise their MT capability TLV in their IIHs. > --- 93,106 ---- > > Adjacencies on point-to-point interfaces are formed as usual with > ISIS routers not implementing MT extensions. If local router does > not participate in certain MTs, it will not advertise those MTIDs > in it's IIHs and thus will not include that neighbor within it's > ! LSPs. On the other hand, if a MTID is not detected in remote > ! side's IIHs, the local router MUST NOT include that neighbor > ! within it's LSPs. The local router SHOULD NOT form adjacency if > ! they don't have at least one common MT set over the interface. > > 5.2. Forming Adjacencies on Broadcast Interfaces > > On a LAN, all the routers on the LAN which implement the MT > extension MAY advertise their MT capability TLV in their IIHs. > *************** Internet Draft M-ISIS > *** 153,166 **** > pseudo-node LSP construction. > > > 7. MTs and Overload, Partition and Attached Bits > > ! As stated earlier, all MTs share the same set of L1-L2 boundaries > ! and NETs. However, a router could for each of the MTs become > ! potentially partitioned, overloaded and attached independently. > ! To prevent unnecessary complexity, MT extensions does not support > partition repair. The overload, partition and attached bits in LSP > header only reflect the status of the default topology. > > Attached bit and overload bit are part of the MT TLV being > distributed within a node's LSP fragment zero. Since each adjacency > --- 149,161 ---- > pseudo-node LSP construction. > > > 7. MTs and Overload, Partition and Attached Bits > > ! A router could for each of the MTs become potentially > ! partitioned, overloaded and attached independently. To prevent > ! unnecessary complexity, MT extensions does not support > partition repair. The overload, partition and attached bits in LSP > header only reflect the status of the default topology. > > Attached bit and overload bit are part of the MT TLV being > distributed within a node's LSP fragment zero. Since each adjacency > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Apr 5 11:57:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03313 for ; Tue, 5 Apr 2005 11: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 1DIqMo-0001uK-IY; Tue, 05 Apr 2005 11:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIa0G-0002Yg-Kc for isis-wg@megatron.ietf.org; Mon, 04 Apr 2005 18:25:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19526 for ; Mon, 4 Apr 2005 18:25:00 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIa8F-0003zu-1C for isis-wg@ietf.org; Mon, 04 Apr 2005 18:33:20 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 04 Apr 2005 15:24:50 -0700 Received: from cisco.com (cfcentral.cisco.com [64.101.210.32]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j34MOegE001519; Mon, 4 Apr 2005 15:24:41 -0700 (PDT) Received: (from wardd@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA10637; Mon, 4 Apr 2005 17:24:46 -0500 (CDT) Date: Mon, 4 Apr 2005 17:24:46 -0500 From: David Ward To: isis-wg@ietf.org, prz@xebeo.com, Naiming Shen , nsheth@juniper.net Message-ID: <20050404172446.V2111@cfcentral.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Tue, 05 Apr 2005 11:53:25 -0400 Cc: chopps@rawdofmt.org, dward@cisco.com Subject: [Isis-wg] Last Call announcement 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 All - We are announcing Last Call for: M-ISIS: Multi Topology (MT) Routing in IS-IS http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt Please submit final comments before April 25th, 2005. Thanks Dave and Chris _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Apr 11 16:35:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22534 for ; Mon, 11 Apr 2005 16:35:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4r2-0008TJ-HI; Mon, 11 Apr 2005 15:45:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4r0-0008T1-JZ for isis-wg@megatron.ietf.org; Mon, 11 Apr 2005 15:45:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13756 for ; Mon, 11 Apr 2005 15:45:40 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL50J-0002cK-RO for isis-wg@ietf.org; Mon, 11 Apr 2005 15:55:28 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Mon, 11 Apr 2005 15:45:32 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Apr 2005 15:45:32 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.180 140.233.20.180 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 11 Apr 2005 15:45:32 -0400 From: "Parker, Jeff" To: ISIS WG Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Apr 2005 19:45:32.0656 (UTC) FILETIME=[05CF6F00:01C53ECF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Version 19 of 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 Content-Transfer-Encoding: 7bit I have just posted version 19 of the MIB to the IETF after our recent MIB Dr Review. Change list below. The largest change was adding a read-only compliance section, which should not impose an implementation burden. I'd be happy to unicast a copy of the mib to those who can't wait for it to appear. - jeff parker -- Changes in version 19 -- -- Removed restrictions on InetAddress and -- InetPrefixLength. -- Removed restriction on which flavors of IP -- we need to support. -- Added mib-2 to list of imports. -- Changed description of isisNextCircIndex -- Removed comment that Reachable Address Group -- was optional. -- Added text about matching IP address to Type, and -- prefix length to address -- Added and updated references -- Added ReadOnly Compliance section -- Replaced edge-triggered notifications with time-based throttling -- Added new TC called IsisAdjLevel -- Revised isisISAdjUsage to use the new TC _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Apr 12 16:15:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04121 for ; Tue, 12 Apr 2005 16:15:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRE0-0003ls-DY; Tue, 12 Apr 2005 15:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRDx-0003lM-3m; Tue, 12 Apr 2005 15:39:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29429; Tue, 12 Apr 2005 15:38:58 -0400 (EDT) Message-Id: <200504121938.PAA29429@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Apr 2005 15:38:58 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-19.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-19.txt Pages : 99 Date : 2005-4-12 This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-19.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-19.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-19.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-12161216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-12161216.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 Wed Apr 13 06:48:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13922 for ; Wed, 13 Apr 2005 06:48: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 1DLfHf-000548-HF; Wed, 13 Apr 2005 06:39:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfHd-00053H-IA for isis-wg@megatron.ietf.org; Wed, 13 Apr 2005 06:39:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13306 for ; Wed, 13 Apr 2005 06:39:35 -0400 (EDT) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLfRH-0002hE-6O for isis-wg@ietf.org; Wed, 13 Apr 2005 06:49:43 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 13 Apr 2005 11:39:24 +0100 Message-ID: <37701240971DD31193970000F6CCB9F706704BDD@duke.datcon.co.uk> Thread-Topic: [Isis-wg] Last Call announcement Thread-Index: AcU5+CtuaMW82JxZTSmlGdXPZoN6GgGGfnAg From: "Mike Bartlett" To: "Cisco - David Ward" , , , "Naiming Shen" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: chopps@rawdofmt.org Subject: [Isis-wg] Comments on draft-ietf-isis-wg-multi-topology-09 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: quoted-printable Hello all, I have just read this draft for the first time and have some comments on = it. Firstly there are two specific areas where I'm unsure how a router = should behave when supporting this draft. Secondly I have raised some = editorial-type issues including typos. I'd be grateful for your feedback on the points I have raised. Many thanks, Mike Bartlett ------------------------------------------- Mike Bartlett Network Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 =20 Fax: +44 20 8363 1039 Email: mb@dataconnection.com =20 Web: http://www.dataconnection.com Specific issues --------------- 1. Suppose that two routers R1 and R2 are exchanging IIHs over a = point-to-point interface. R1 supports the MT extensions and only uses = MT ID#1 on this interface. R2 is not including the MT capability TLV at = all on its IIHs. Should R1 attempt to form an adjacency? In section = 5.1 the specification of what to do seems contradictory to me. =20 There are two conflicting possibilities. In one case R1 should form an = adjacency and in one case it shouldn't, but it has no way of telling = which case applies. a) It is possible that R2 does not support the MT extensions. In this = case the first sentence "Adjacencies on point-to-point interfaces are = formed as usual with ISIS routers not implementing MT extensions" should = apply - i.e. R1 should form an adjacency. b) It is possible that R2 does support the MT extensions, but only uses = MT ID#0 on this interface (in which case it does not have to advertize = this MT ID). In this case the last sentence "The local router SHOULD = NOT form adjacency if they don't have at least one common MT set over = the interface" should apply - i.e. R1 should NOT form an adjacency.=20 2. Is it legal for a router R1 to advertize reachability to one IPv6 = prefix P1 using MT ID #0 and to another IPv6 prefix P2 using a non-zero = MT ID (for example MT ID #1)? If this is legal, the specification of = how to do this seems contradictory to me (section 11.4 this time). a) In the corresponding IPv4 case (section 11.3) it seems clear that R1 = should include TLV 135 for P1 and TLV 235 for P2 (because TLV 235 cannot = be used for MT ID #0). Section 11.4 also allows for this possibility in = the IPv6 case - for the new TLV 237 it says "The TLV MUST be ignored if = the ID is zero", which implies that TLV 236 must be used for P1 (MT ID = #0) and TLV 237 for P2 (MT ID #1). b) However, section 11.4 also says "No attempt is made in this draft to = let the M-ISIS IPv6 topology to understand the normal IPv6 prefix with = TLV type 236. A network SHOULD only run IS-IS either with IPv6 using = type 236 or with M-ISIS IPv6 using type 237." This would imply that it = is illegal for R1 to generate both TLV types 236 and 237. =20 Editorial comments ------------------ General: a) Reading the draft for the first time, I found the layout difficult to = follow. For example I struggled with the following sentence in section = 5 because some of the terminology has not yet been introduced - "Through = this exchange of MT capabilities, a router is able to advertise the IS = TLVs in LSPs with common MT set over those adjacencies." I think it = would be easier to read this document if the introduction section = introduced the new TLVs and briefly explained their purpose. Then the = discussion in sections 5.1 and 5.2 about advertizing neighbors in LSPs = would also be more understandable. b) The various new TLVs are referred to by various different names, = which is confusing. - TLV 229 is variously referred to as "Multi-Topology TLV", "MT TLV", = "MT capability TLV" - TLV 222 is variously referred to as "MT IS TLV", "MT IS Reachable = TLV", "MT Reachable Intermediate Systems TLV", "MT Intermediate Systems = TLV" Section 5.1:=20 a) "it's" should read "its" in 2 places b) "form adjacency" should read "form an adjacency" c) "common MT set" should read "common MT" (or "overlapping MT sets") Section 5.2:=20 a) "it's" should read "its" b) "common MT set" should read "a common MT" (or "overlapping MT sets") c) "according" should read "the corresponding" (corresponding seems a = better word to me than according) d) the text should clarify that the MT IS Reachable TLV on the LAN = contains the pseudonode's DIS ID as the neighbor ID. The rule about "at = least one adjacency" could be incorrectly taken to mean that the TLV = should instead refer to the actual neighbor on that adjacency. Section 6: a) "according" should read "corresponding" in 2 places Section 9:=20 a) "it's" should read "its" b) "according" should read "corresponding" Section 10: a) "common MT set" should read "common MT" (or "common MT capability", = as per the next sentence) b) "an point-to-point" should read "a point-to-point" -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Cisco - David Ward Sent: 04 April 2005 23:25 To: isis-wg@ietf.org; prz@xebeo.com; Naiming Shen; nsheth@juniper.net Cc: chopps@rawdofmt.org; Cisco - David Ward Subject: [Isis-wg] Last Call announcement All - We are announcing Last Call for: M-ISIS: Multi Topology (MT) Routing in IS-IS http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-09.= txt Please submit final comments before April 25th, 2005. Thanks Dave and 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 Thu Apr 14 03:48:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12056 for ; Thu, 14 Apr 2005 03:48: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 1DLyts-0004Ht-RL; Thu, 14 Apr 2005 03:36:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLytd-0004CN-Lw for isis-wg@megatron.ietf.org; Thu, 14 Apr 2005 03:36:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11237 for ; Thu, 14 Apr 2005 03:36:08 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLz3R-0003Vb-7i for isis-wg@ietf.org; Thu, 14 Apr 2005 03:46:26 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2005 00:35:59 -0700 Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3E7ZrUC027100; Thu, 14 Apr 2005 00:35:54 -0700 (PDT) Message-ID: <425E1D5B.9060100@cisco.com> Date: Thu, 14 Apr 2005 00:35:55 -0700 From: Naiming Shen User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Bartlett References: <37701240971DD31193970000F6CCB9F706704BDD@duke.datcon.co.uk> In-Reply-To: <37701240971DD31193970000F6CCB9F706704BDD@duke.datcon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Cc: chopps@rawdofmt.org, nsheth@juniper.net, prz@xebeo.com, isis-wg@ietf.org Subject: [Isis-wg] Re: Comments on draft-ietf-isis-wg-multi-topology-09 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 Mike, See some replies inline. Mike Bartlett said the following on 04/13/2005 03:39 AM: ] Hello all, ] ] I have just read this draft for the first time and have some comments ] on it. Firstly there are two specific areas where I'm unsure how a ] router should behave when supporting this draft. Secondly I have ] raised some editorial-type issues including typos. ] ] I'd be grateful for your feedback on the points I have raised. ] ] Many thanks, ] ] Mike Bartlett ] ] ------------------------------------------- Mike Bartlett Network ] Protocols Group Data Connection Ltd Tel: +44 20 8366 1177 ] Fax: +44 20 8363 1039 Email: mb@dataconnection.com Web: ] http://www.dataconnection.com ] ] ] Specific issues --------------- ] ] 1. Suppose that two routers R1 and R2 are exchanging IIHs over a ] point-to-point interface. R1 supports the MT extensions and only ] uses MT ID#1 on this interface. R2 is not including the MT ] capability TLV at all on its IIHs. Should R1 attempt to form an ] adjacency? R1 should attempt, and should fail to form adjacency in this case. ] In section 5.1 the specification of what to do seems ] contradictory to me. ] ] There are two conflicting possibilities. In one case R1 should form ] an adjacency and in one case it shouldn't, but it has no way of ] telling which case applies. ] ] a) It is possible that R2 does not support the MT extensions. In ] this case the first sentence "Adjacencies on point-to-point ] interfaces are formed as usual with ISIS routers not implementing MT ] extensions" should apply - i.e. R1 should form an adjacency. ] The first sentense just means there is no special procedure to form an adjacency with a non-MT neighbor. But it does not mean they MUST form adjacency. The later sentenses add more condition on what cases they SHOULD NOT form adjacency over a p2p link. ] b) It is possible that R2 does support the MT extensions, but only ] uses MT ID#0 on this interface (in which case it does not have to ] advertize this MT ID). In this case the last sentence "The local ] router SHOULD NOT form adjacency if they don't have at least one ] common MT set over the interface" should apply - i.e. R1 should NOT ] form an adjacency. Correct. This is the condition they should not form adjacency. ] ] 2. Is it legal for a router R1 to advertize reachability to one IPv6 ] prefix P1 using MT ID #0 and to another IPv6 prefix P2 using a ] non-zero MT ID (for example MT ID #1)? Well, the MT ID #1 is defined as ipv4 mgmt topology, so you should not put ipv6 routes there usually. But if you insist that MT ID#1 in your netowrk is for IPv6 usage, I think it's fine too;-) Lets assume you meant putting in non-zero MT ID #x for example here. Yes, it should be legal. ] If this is legal, the ] specification of how to do this seems contradictory to me (section ] 11.4 this time). ] ] a) In the corresponding IPv4 case (section 11.3) it seems clear that ] R1 should include TLV 135 for P1 and TLV 235 for P2 (because TLV 235 ] cannot be used for MT ID #0). Section 11.4 also allows for this ] possibility in the IPv6 case - for the new TLV 237 it says "The TLV ] MUST be ignored if the ID is zero", which implies that TLV 236 must ] be used for P1 (MT ID #0) and TLV 237 for P2 (MT ID #1). Ok. ] ] b) However, section 11.4 also says "No attempt is made in this draft ] to let the M-ISIS IPv6 topology to understand the normal IPv6 prefix ] with TLV type 236. A network SHOULD only run IS-IS either with IPv6 ] using type 236 or with M-ISIS IPv6 using type 237." This would imply ] that it is illegal for R1 to generate both TLV types 236 and 237. Hmm? does this imply it illegal? This sentense is meant for an operator of a network should not try to mix those two topologies in one network, since they don't understand each other. Operators can obviously do that, it's just that the result is not well defined or understood. that's all. This does not imply router R1 can NOT advertise both TLV types. If they are used properly for different purpose, for example during topology transition, they actually may want to advertise both. ] ] Editorial comments ------------------ ] ] General: a) Reading the draft for the first time, I found the layout ] difficult to follow. For example I struggled with the following ] sentence in section 5 because some of the terminology has not yet ] been introduced - "Through this exchange of MT capabilities, a router ] is able to advertise the IS TLVs in LSPs with common MT set over ] those adjacencies." I think it would be easier to read this document ] if the introduction section introduced the new TLVs and briefly ] explained their purpose. Then the discussion in sections 5.1 and 5.2 ] about advertizing neighbors in LSPs would also be more ] understandable. ] It helps reading it multiple times;-) or try the PIM spec instead... But seriously, at this stage, we are not going to change the structure or layout of this document. sorry about that. I'll fix the rest of the syntax related comments. many thanks for spending time on this draft. Cheers. - Naiming ] b) The various new TLVs are referred to by various different names, ] which is confusing. - TLV 229 is variously referred to as ] "Multi-Topology TLV", "MT TLV", "MT capability TLV" - TLV 222 is ] variously referred to as "MT IS TLV", "MT IS Reachable TLV", "MT ] Reachable Intermediate Systems TLV", "MT Intermediate Systems TLV" ] ] Section 5.1: a) "it's" should read "its" in 2 places b) "form ] adjacency" should read "form an adjacency" c) "common MT set" should ] read "common MT" (or "overlapping MT sets") ] ] Section 5.2: a) "it's" should read "its" b) "common MT set" should ] read "a common MT" (or "overlapping MT sets") c) "according" should ] read "the corresponding" (corresponding seems a better word to me ] than according) d) the text should clarify that the MT IS Reachable ] TLV on the LAN contains the pseudonode's DIS ID as the neighbor ID. ] The rule about "at least one adjacency" could be incorrectly taken to ] mean that the TLV should instead refer to the actual neighbor on that ] adjacency. ] ] Section 6: a) "according" should read "corresponding" in 2 places ] ] Section 9: a) "it's" should read "its" b) "according" should read ] "corresponding" ] ] Section 10: a) "common MT set" should read "common MT" (or "common MT ] capability", as per the next sentence) b) "an point-to-point" should ] read "a point-to-point" ] _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Apr 15 05:19:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10700 for ; Fri, 15 Apr 2005 05:19: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 1DMMq1-0004tB-4Y; Fri, 15 Apr 2005 05:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMMpn-0004f3-0C for isis-wg@megatron.ietf.org; Fri, 15 Apr 2005 05:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10162 for ; Fri, 15 Apr 2005 05:08:54 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMMz0-0004vn-6n for isis-wg@ietf.org; Fri, 15 Apr 2005 05:19:27 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j3F98isC020410; Fri, 15 Apr 2005 02:08:44 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j3F98hD4009730; Fri, 15 Apr 2005 02:08:43 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j3F98fch009720; Fri, 15 Apr 2005 02:08:41 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 15 Apr 2005 02:08:41 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG , Jeff Parker In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5df1f98f3253c63b673ea560243aa58f Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder Subject: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-19.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 Sun, 6 Mar 2005, C. M. Heard wrote: > I have done a somewhat cursory review of the most recent version > which was . In general, it appears > to be technically sound to the extent that I am able to judge (which > is limited because I know little about IS-IS). However, there are a > number of small things that probably should be corrected before the > document goes to the IESG. The details follow below (organized > according to the checklist in Appendix A of > draft-ietf-ops-mib-review-guidelines-04.txt). The things most > likely to elicit DISCUSS comments from the IESG are probably 6, > 10(c), and 10(d). Note: please address replies to the WG mailing > list with copies to Bert Wijnen, Juergen Schoenwaelder, and myself. I have looked over the latest update which was posted on 11 April. Owing to time constraints I have had to focus exclusively on how previous review comments were addresses. My findings are as follows. > 1.) I-D Boilerplate -- OK No new issues. > 2.) Abstract -- some citations are present, which is not allowed (see > http://www.ietf.org/ID-Checklist.html Section 3(1)C). In addition, > since this document is intended for the standards track, please change > the phrase "an experimental portion" to "a portion" in the 2nd > paragraph. Fixed. > 3.) MIB Boilerplate -- present and correct, however, it is customary > (and in my opinion preferable) to put it before the narrative that > describes the MIB module. So I would suggest reversing the order of > Sections 1 and 2 in the draft. Fixed. > 4.) IPR Notice -- OK No new issues. > 5.) References -- there are several problems. > > (a) the following item > > [1] "Integrated IS-IS Management Information Base", IETF Draft, > March 1994, Chris Gunner. > > should be removed from the list of normative references since it is > not essential to read it in order to implement the MIB module. I > suppose it could be moved to the informative references section, but > the best thing would probably be to remove it entirely, since it > is difficult (at best) to find a copy of draft-ietf-isis-mib-03.txt > (http://www.potaroo.net/ietf/old-ids/draft-ietf-isis-mib-02.txt exists > but the -03 version does not show up there). The original author's > efforts are explicitly acknowledged, and that is probably sufficient. > > (b) for the following > > [2] ISO 10589, "Intermediate System to Intermediate System Intra- > Domain Routeing Exchange Protocol for use in Conjunction with > the Protocol for Providing the Connectionless-mode Network > Service (ISO 8473)", 1992. > > please change the citation tag from the numeric form to a symbolic > one (e.g., [ISO10589]) to match the style of all the other references. > You will need to add a citation somewhere in the main body of the > text (NOT in the abstract) or else the RFC Editor will complain of a > dangling reference. Perhaps the first line of the abstract can be > copied (with citations left intact) into the Overview section. > > (c) [RFC1195] needs to be cited in the text (NOT in the abstract). > The remedy suggested above in (b) (copying the first line of the > abstract into the Overview section with citations left intact) > will fix this. > > (d) the following reference > > [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > "Introduction to Community-based SNMPv2", RFC 1901, January > 1996. > > is obsolete and uncited. Please remove it. > > (e) the following documents > > [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An > Architecture for Describing SNMP Management Frameworks", RFC > 2571, April 1999. > > [RFC3291] Daniele, M.,Haberman, B., Routhier, S., and J. > Schoenwaelder, "Textual Conventions for Internet Network > Addresses", RFC 3291. > > have been obsoleted by RFC 3411 and RFC 4001 respectively. Please > update these references (and all citations in the text) accordingly. > > (f) I see that normative references do exist for all MIB modules > from which things are imported and that appropriate citations exist. > I also see that the references required by the boilerplate are > present and accounted for. That is good. However, the REFERENCE > clauses in the MIB module point to RFC 2973 and to RFC 3373, neither > of which is present in the reference list. I think that these > should be among the normative references and that they need to be > mentioned in the discussion in the overview section. Also, there > are numerous REFERENCE clauses that point to GDMO objects, and it > would be good to have some text in the Overview saying where those > objects are defined, with references to the appropriate documents. > In http://www.potaroo.net/ietf/old-ids/draft-ietf-isis-mib-02.txt > I see the following text: > > The objects are mainly derived from the GDMO definitions in > ISO 10589 and from the GDMO definitions in ISO 10733 [5]. > > with this reference: > > [5]"Information Technology - Telocommunications and information > exchange between systems - Elements of Management > Information Related to OSI Network Layer Standards", > International Standard 10733 (ISO submission copy), > September 1992. > > and I wonder if something along those lines would be appropriate here. A couple of minor errors remain: On the third line of Section 2, first paragraph: s/ISO 10589 [2]/ISO 10589 [ISO10589]/ In Section 7, Normative References, [RFC3289] is listed twice. Both listings have minor typos. > 6.) Security Considerations Section -- I see that the part on writeable > objects states that "there are very few writable attributes that do not > have negative side effects on network operations." It might be better > to say "all writeable attributes have the potential to disrupt network > operations if improperly modified and may require protection against > unauthorized write access." > > Also, are there readable objects (objects with an access of greater > than not-accessible) that could reveal sensitive information if read > by unauthorized parties? If so, that needs to be discussed. If not, > that needs to be explicitly stated. See Section 3.4 of the MIB review > guidelines (draft-ietf-ops-mib-review-guidelines-04.txt) for discussion. These issues have been addressed. > 7.) IANA Considerations Section -- content is correct, although it is > customary for this section to appear after the MIB module. Fixed. > 8.) Copyright Notices -- OK No new issues. > 9.) Other issues (e.g., from http://www.ietf.org/ID-Checklist.html) > that are not covered elsewhere: > > (a) missing punctuation in Overview section: > OLD > The IS-IS MIB defines the following objects > NEW > The IS-IS MIB defines the following objects: Fixed. > 10.) Technical content -- review of actual technical content for > compliance with : > > (a) MIB compilation using smilint -- > > The program smilint 0.4.3, as of Mon Jan 17 19:25:32 2005 > has been used to process your request as follows: > > smilint -m -s -e -l 6 mailbody > > mailbody:59: [1] {object-identifier-unknown} unknown object > identifier label `mib-2' > mailbody:6: [5] {import-unused} warning: identifier `experimental' > imported from module `SNMPv2-SMI' is never used > > The problem is that the draft still IMPORTS 'experimental' instead > of 'mib-2'. Proposed remedy: > > OLD: > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, > Counter32, experimental, NOTIFICATION-TYPE > NEW: > MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, > Integer32, Unsigned32, Counter32, mib-2 > > Note: the same results issue from SMICng. Fixed. > (b) In the MODULE-IDENTITY DESCRIPTION clause I think that > jparker at world dot std dot edu needs to be changed to > jparker at world dot std dot com. (I am not sure if the > RFC Editor will let it remain in this form, but I guess > it's worth a try :) Fixed. > (c) As noted in Section 4.6.4 of the MIB review guidelines, it is > REQUIRED that each read-create table specify what happens to > dynamically-created rows after an agent restart, and when a > RowStatus column is present, it is necessary to specify whether > modifications are allowed when the status column is 'active'. I > don't thin[k] that these requirements have been met. These issues do not appear to have been addressed. That is likely to elicit unfavorable AD review comments. I suggest that this be fixed before submission to the IESG. > (d) I see that every InetAddress object has a SYNTAX value of > InetAddress (SIZE(4|16)) and that every InetAddressPrefixLength > object has a SYNTAX value of InetAddressPrefixLength (0..128), > but the corresponding InetAddressType objects have a SYNTAX > value of InetAddressType with no constraint but with a proviso > in the DESCRIPTION clause that "[a]n implementation is only > required to support IPv4 and IPv6 addresses." If the intent is > to forever limit support to IPv4 and IPv6, which is the effect > that the present SYNTAX refinements on the InetAddress and > InetAddressPrefixLength objects have, then then it would > be better to use a SYNTAX refinement in the InetAddressType > objects to express that, rather than using text in the > DESCRIPTION clause that is more appropriate in a compliance > statement. Please note, however, that it is strongly preferred > (at least in the MIB Doctor community) to have _no_ constraints > in the definitions of objects of this type, and instead to put > OBJECT clauses in the relevant compliance statements or, for > inaccessible INDEX objects, text in the compliance statements' > DESCRIPTION clauses. For a usage example in a similar application > see draft-ietf-ipv6-rfc2096-update-07.txt, which defines the > inetCidrRouteTable. Note that the lack of constraints on INDEX > objects of type InetAddress leads to definitions that could, in > principle, exceed the 128 sub-ID length on SNMP object names; > as recommended in the MIB review guidelines Section 4.6.6, > draft-ietf-ipv6-rfc2096-update-07.txt includes text in the > inetCidrRouteEntry DESCRIPTION clause that spells out the > limitations. Fixed. Results from smilint are now as follows: The program smilint 0.4.3, as of Fri Apr 01 10:26:14 2005 has been used to process your request as follows: smilint -m -s -e -l 9 -i namelength-32 ISIS-MIB ISIS-MIB:602: [5] {index-exceeds-too-large} warning: index of row `isisSummAddrEntry' can exceed OID size limit by 142 subidentifier(s) ISIS-MIB:728: [5] {index-exceeds-too-large} warning: index of row `isisRedistributeAddrEntry' can exceed OID size limit by 142 subidentifier(s) ISIS-MIB:2644: [5] {index-exceeds-too-large} warning: index of row `isisIPRAEntry' can exceed OID size limit by 144 subidentifier(s) The DESCRIPTION clauses of isisSummAddrTable, isisRedistributeAddrTable, and isisIPRATable take note of these potential issues. > Note that the DESCRIPTION clause of every object of type > InetAddress or InetAddressPrefixLength is REQUIRED to specify > which InetAddressType object that provides the context in which > is it interpreted, and none of the definitions in the module > follow that rule. That needs to be corrected even if it is > decided not to remove the constraints on the objects. Fixed. > (e) The DESCRIPTION clauses of isisSummAddressType, > isisRedistributeAddrType, isisISAdjIPAddrType, isisIPRADestType, > and isisIPRANextHopType include the sentence "[a]n implementation > is only required to support IPv4 and IPv6 addresses." Similarly, > the DESCRIPTION clauses of isisSummAddrExistState, > isisRedistributeAddrExistState, isisCircExistState, > isisRAExistState, and isisIPRAExistState include the sentence > "[s]upport for createAndWait and notInService is not required." > Since it is describing what an agent is required to do, rather > than what makes "protocol sense" for the object to support, that > type of language belongs in an OBJECT clause in a compliance > statement, not in the object definition itself. Removing the IP version-specific syntactic constraints in the OBJECT-TYPE definitions was a good thing, since it allows the MIB module to support other address types in the future. However, one needs to be aware that in the absence of OBJECT clauses or text in the DESCRIPTION clause saying otherwise, this causes the compliance statements to require that implementations support all InetAddressType values. If this is not wanted, then at a minimum it is necessary to add language in the DESCRIPTION clauses of the compliance statements to the effect that an implementation is only required to support global IPv4 and IPv6 addresses. For a more elegant alternative, see the compliance statements in RFC 3289. I see that the DESCRIPTION clauses of the RowStatus objects mentioned above are unchanged. This is acceptable since RFC 2579 explicitly permits an agent not to support createAndWait and notInService. > (f) The DESCRIPTION clauses of isisManAreaAddr, > isisSummAddressType, isisSummAddress, isisRedistributeAddrType, > isisRedistributeAddrAddress, isisCircIndex, and isisRAIndex > contain the sentence "[t]his object follows the index behavior" > or an equivalent phrase. Similarly, the DESCRIPTION clauses of > isisManAreaAddrExistState, isisSummAddrExistState, > isisRedistributeAddrExistState, and isisCircExistState include > the sentence "[t]his object follows the Row Status behavior." > Finally, the DESCRIPTION clauses of isisCircAdminState and > isisRAAdminState include the sentence "[t]his object follows > the AdminState behavior" or an equivalent phrase. I'm not quite > sure what these sentences are supposed to mean. If the intent is > to say (respectively) "this is an INDEX object" or "this is a > RowStatus object" or "this is an AdminState object" then there is > no value in having them, since the INDEX clause of the enclosing > table or the SYNTAX clause of the object already tells me what I > need to know. If the intent is something else then it needs to > be defined (as are the behaviors ResettingTimer, > ReplaceOnlyWhileDisabled, and ManualOrAutomatic). Mostly fixed. The DESCRIPTION clause for isisRAIndex still contains the sentence "This object follows the index behaviors." That sentence should be removed. The DESCRIPTION clause for isisRAAdminState still contains the sentence This object follows the AdminState and ManualOrAutomatic behaviors." That should be changed to read "This object follows the ManualOrAutomatic behaviors." > (g) I infer from the DESCRIPTION of the following object that > it is set by a manager and then decremented each second by the > agent until it becomes zero: > > isisSysLevelSetOverloadUntil OBJECT-TYPE > SYNTAX Unsigned32(1..4294967295) > UNITS "Seconds until clearing manually set Overload Bit" > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "If this object is non-zero, the overload bit is set at > this level when the isisSysAdminState variable goes to > state 'on' for this Intermediate System. The overload bit > remains set for isisSysLevelSetOverloadUntil seconds. > When isisSysLevelSetOverloadUntil seconds have elapsed, > the overload flag remains set if the implementation has > run out of memory, or if it is set manually using the > isisSysLevelSetOverload object." > ::= { isisSysLevelEntry 6 } > > If that is the case, the SYNTAX value needs to be changed to > include zero (e.g., Unsigned32 with no range constraint). Fixed. > (h) The DESCRIPTION clause of isisNextCircIndex does not seem > to be entirely consistent with the DESCRIPTION clause of the > IndexIntegerNextFree TC in RFC 3289. Here is a suggestion: > > OLD: > isisNextCircIndex OBJECT-TYPE > SYNTAX IndexIntegerNextFree > 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." > NEW: > isisNextCircIndex OBJECT-TYPE > SYNTAX IndexIntegerNextFree > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object is used to assist a management > application in creating new rows in the > isisCircTable. If it is possible to create > a new instance of isisCircEntry, then this > object will contain a non-zero value that > is not in use as the index of any row in the > isisCircTable. The network manager reads the > value of this object and then (if the value > value read is non-zero) attempts to create > the corresponding instance of isisCircEntry. > If the set request fails ith the code > 'inconsistentValue', the the process must be > repeated; if the set request succeeds, then > the agent will change value of this object > according to an implementation-specific > algorithm." Fixed. > (i) From the fact that isisCircIfIndex has a SYNTAX value of > InterfaceIndex (not InterfaceIndexOrZero) I infer that there > there is always an ifTable entry associated with a circuit. > That being the case, neither isisCircIndex nor isisCircIfIndex > is strictly necessary -- one could use ifIndex as itself as > the index, thereby eliminating the need for both of these > objects. However, the existing design is acceptable. No change required. > (j) It seems to me that for at least some interface types > the object isisCircIfSubSelector will be irrelevant. If > that is true, then it would be good to specify that the > object gets some distinguished value (e.g., 0 or -1) if > it is not used. Fixed. > (k) The commentary just prior to the definition of isisRATable > contains the following line: > > -- The Reachable Address Group is optional. > > I would recommend that this statement be removed. As a general > rule, any statements on what is optional to implement and what > is required should be in the compliance statements alone and > should not be included in object descriptions or in the ASN.1 > comments that surround them. Fixed. > (l) The DESCRIPTION clauses of isisRAIndex, isisIPRADestType, > isisIPRADest, and isisIPRADestPrefixLen say that they follow he > ManualOrAutomatic behavior. However, that behavior says the object > is read-write or read-only, and so cannot apply to inaccessible > index objects such as these (it can apply to the corresponding > RowStatus object, which allows the row to be created or destroyed if > appropriate). Fixed. > (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: > "The 8 byte LSP ID, consisting of the SystemID, > Circuit ID, and Fragment Number." > Maybe this is a stupid question, but shouldn't the > isisLSPSummaryTable be concerning itself with entire reassembled > link state PDUs and not individual fragments thereof? If so, > perhaps the DESCRIPTION clause should be revised. (If this were > IPv4, and I were describing a complete, reassembled IP PDU, I > would specify that Fragment Offset=0 and MF=0, and I would also > stipulate that the checksum is what would have been computed for > the complete datagram prior to fragmentation. But perhaps those > considerations don't apply here.) Review comment was based on a misconception. No change required. > (n) In the isisLSPTLVTable, the checksum and sequence number are > provided for each TLV, but are properties of the LSP than contains > them, or so I infer. If that is so, it might be good to change > the DESCRIPTION clause of isisLSPTLVSeq as from: > "The 16 bit Fletcher Checksum." > to: > "The 16 bit Fletcher Checksum for this LSP." > Note that isisLSPTLVSeq already has similar language. Fixed. > (o) It would be less confusing to readers like me if the ASN.1 > comment before the start of the notification definitions > were changed from: > -- Type definitions > to: > -- Notification definitions Fixed. > (p) I see the following language in several of the notification > definitions: > This should be an edge-triggered notification. > We should not send a second notification about > PDUs received from the same circuit. > This seems to imply that no more than one such notification per > circuit per agent reboot will be generated. What if the > condition is persistent? Shouldn't there be additional > notifications? One possible alternative that might be worth > considering is allowing no more than one notification per circuit > per interval of duration T (where T may be a design parameter that > is fixed or the value of some read/write object). This is > suggested in Sec. 4.7 of the MIB review guidelines. Fixed. > (q) In a related vein: are all of the notifications that lack > explicit throttling by their nature generated at a sufficiently > low rate that they will not cause an excess of notifications? A > cursory reading suggests that this is so, but the author should > verify that this is the case. No change required. > (r) Be aware that as written the compliance statements > isisCompliance and isisAdvancedCompliance do not provide for > read-only implementations of the MIB module. No changes need > to be made if that is the intent, but the author should verify > that this is the case. Fixed, except for one small omission: isisReadOnlyCompliance does not have an OBJECT clause specifying a MIN-ACCESS of 'read-only' for the writeable object isisCirc3WayEnabled. That will need to be added. This concludes my review of . On the whole, this looks like a very good MIB document, provided that items 10(c), 10(e), 10(f), and 10(r) and the minor issues with the references are addressed. Regards, Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Apr 15 10:10:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03011 for ; Fri, 15 Apr 2005 10:10: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 1DMRPn-0003Uu-5T; Fri, 15 Apr 2005 10:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMRPl-0003UK-G7 for isis-wg@megatron.ietf.org; Fri, 15 Apr 2005 10:03:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02108 for ; Fri, 15 Apr 2005 10:03:11 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMRZp-0007cO-7W for isis-wg@ietf.org; Fri, 15 Apr 2005 10:13:46 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Fri, 15 Apr 2005 10:03:01 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Apr 2005 10:03:00 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.181 140.233.20.181 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 15 Apr 2005 10:03:00 -0400 Subject: Re: [Isis-wg] Mib Doctor review of: draft-ietf-isis-wg-mib-19.txt From: "Parker, Jeff" To: "C. M. Heard" , ISIS WG , Jeff Parker Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 14:03:00.0974 (UTC) FILETIME=[D5B4A0E0:01C541C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder 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 Thanks for the gimlet-eyed review. I will revise, circulate a draft privately, and resubmit a new ID shortly. - jeff parker On 4/15/05 5:08 AM, "C. M. Heard" wrote: > I have looked over the latest update > which was posted on 11 April. Owing to time constraints I have had > to focus exclusively on how previous review comments were addresses. > My findings are as follows. > ... - and - On 4/15/05 8:36 AM, "Wijnen, Bert (Bert)" wrote: > Thanks again Mike for your re-review. > > So Jeff, I assume we can expect a quick respind to address > the remaining (quite containable) remarks/concerns? > > Bert _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Apr 18 09:50:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWeI-0007uD-K2; Mon, 18 Apr 2005 09:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMQ4F-0006r7-88 for isis-wg@megatron.ietf.org; Fri, 15 Apr 2005 08:37:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25946 for ; Fri, 15 Apr 2005 08:37:01 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMQEQ-0004Pt-A6 for isis-wg@ietf.org; Fri, 15 Apr 2005 08:47:35 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j3FCaoHj018301 for ; Fri, 15 Apr 2005 07:36:50 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <26JFM6LG>; Fri, 15 Apr 2005 14:36:49 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15506AD76AC@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'C. M. Heard'" , ISIS WG , Jeff Parker Date: Fri, 15 Apr 2005 14:36:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 09f2eafe5f7c426554d5f494540a89cd X-Mailman-Approved-At: Mon, 18 Apr 2005 09:50:48 -0400 Cc: "Wijnen, Bert \(Bert\)" , Juergen Schoenwaelder Subject: [Isis-wg] RE: Mib Doctor review of: draft-ietf-isis-wg-mib-19.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 again Mike for your re-review. So Jeff, I assume we can expect a quick respind to address the remaining (quite containable) remarks/concerns? Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Friday, April 15, 2005 11:09 > To: ISIS WG; Jeff Parker > Cc: Wijnen, Bert (Bert); Juergen Schoenwaelder > Subject: Mib Doctor review of: draft-ietf-isis-wg-mib-19.txt > > > On Sun, 6 Mar 2005, C. M. Heard wrote: > > I have done a somewhat cursory review of the most recent version > > which was . In general, it appears > > to be technically sound to the extent that I am able to judge (which > > is limited because I know little about IS-IS). However, there are a > > number of small things that probably should be corrected before the > > document goes to the IESG. The details follow below (organized > > according to the checklist in Appendix A of > > draft-ietf-ops-mib-review-guidelines-04.txt). The things most > > likely to elicit DISCUSS comments from the IESG are probably 6, > > 10(c), and 10(d). Note: please address replies to the WG mailing > > list with copies to Bert Wijnen, Juergen Schoenwaelder, and myself. > > I have looked over the latest update > which was posted on 11 April. Owing to time constraints I have had > to focus exclusively on how previous review comments were addresses. > My findings are as follows. > > > 1.) I-D Boilerplate -- OK > > No new issues. > > > 2.) Abstract -- some citations are present, which is not > allowed (see > > http://www.ietf.org/ID-Checklist.html Section 3(1)C). In addition, > > since this document is intended for the standards track, > please change > > the phrase "an experimental portion" to "a portion" in the 2nd > > paragraph. > > Fixed. > > > 3.) MIB Boilerplate -- present and correct, however, it is customary > > (and in my opinion preferable) to put it before the narrative that > > describes the MIB module. So I would suggest reversing the order of > > Sections 1 and 2 in the draft. > > Fixed. > > > 4.) IPR Notice -- OK > > No new issues. > > > 5.) References -- there are several problems. > > > > (a) the following item > > > > [1] "Integrated IS-IS Management Information Base", IETF Draft, > > March 1994, Chris Gunner. > > > > should be removed from the list of normative references since it is > > not essential to read it in order to implement the MIB module. I > > suppose it could be moved to the informative references section, but > > the best thing would probably be to remove it entirely, since it > > is difficult (at best) to find a copy of draft-ietf-isis-mib-03.txt > > > (http://www.potaroo.net/ietf/old-ids/draft-ietf-isis-mib-02.txt exists > > but the -03 version does not show up there). The original author's > > efforts are explicitly acknowledged, and that is probably > sufficient. > > > > (b) for the following > > > > [2] ISO 10589, "Intermediate System to Intermediate > System Intra- > > Domain Routeing Exchange Protocol for use in > Conjunction with > > the Protocol for Providing the Connectionless-mode Network > > Service (ISO 8473)", 1992. > > > > please change the citation tag from the numeric form to a symbolic > > one (e.g., [ISO10589]) to match the style of all the other > references. > > You will need to add a citation somewhere in the main body of the > > text (NOT in the abstract) or else the RFC Editor will complain of a > > dangling reference. Perhaps the first line of the abstract can be > > copied (with citations left intact) into the Overview section. > > > > (c) [RFC1195] needs to be cited in the text (NOT in the abstract). > > The remedy suggested above in (b) (copying the first line of the > > abstract into the Overview section with citations left intact) > > will fix this. > > > > (d) the following reference > > > > [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, > > "Introduction to Community-based SNMPv2", RFC 1901, January > > 1996. > > > > is obsolete and uncited. Please remove it. > > > > (e) the following documents > > > > [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An > > Architecture for Describing SNMP Management Frameworks", RFC > > 2571, April 1999. > > > > [RFC3291] Daniele, M.,Haberman, B., Routhier, S., and J. > > Schoenwaelder, "Textual Conventions for Internet Network > > Addresses", RFC 3291. > > > > have been obsoleted by RFC 3411 and RFC 4001 respectively. Please > > update these references (and all citations in the text) accordingly. > > > > (f) I see that normative references do exist for all MIB modules > > from which things are imported and that appropriate citations exist. > > I also see that the references required by the boilerplate are > > present and accounted for. That is good. However, the REFERENCE > > clauses in the MIB module point to RFC 2973 and to RFC 3373, neither > > of which is present in the reference list. I think that these > > should be among the normative references and that they need to be > > mentioned in the discussion in the overview section. Also, there > > are numerous REFERENCE clauses that point to GDMO objects, and it > > would be good to have some text in the Overview saying where those > > objects are defined, with references to the appropriate documents. > > In http://www.potaroo.net/ietf/old-ids/draft-ietf-isis-mib-02.txt > > I see the following text: > > > > The objects are mainly derived from the GDMO definitions in > > ISO 10589 and from the GDMO definitions in ISO 10733 [5]. > > > > with this reference: > > > > [5]"Information Technology - Telocommunications and > information > > exchange between systems - Elements of Management > > Information Related to OSI Network Layer Standards", > > International Standard 10733 (ISO submission copy), > > September 1992. > > > > and I wonder if something along those lines would be > appropriate here. > > A couple of minor errors remain: > > On the third line of Section 2, first paragraph: > s/ISO 10589 [2]/ISO 10589 [ISO10589]/ > > In Section 7, Normative References, [RFC3289] is listed twice. Both > listings have minor typos. > > > 6.) Security Considerations Section -- I see that the part > on writeable > > objects states that "there are very few writable attributes > that do not > > have negative side effects on network operations." It > might be better > > to say "all writeable attributes have the potential to > disrupt network > > operations if improperly modified and may require protection against > > unauthorized write access." > > > > Also, are there readable objects (objects with an access of greater > > than not-accessible) that could reveal sensitive information if read > > by unauthorized parties? If so, that needs to be > discussed. If not, > > that needs to be explicitly stated. See Section 3.4 of the > MIB review > > guidelines (draft-ietf-ops-mib-review-guidelines-04.txt) > for discussion. > > These issues have been addressed. > > > 7.) IANA Considerations Section -- content is correct, > although it is > > customary for this section to appear after the MIB module. > > Fixed. > > > 8.) Copyright Notices -- OK > > No new issues. > > > 9.) Other issues (e.g., from http://www.ietf.org/ID-Checklist.html) > > that are not covered elsewhere: > > > > (a) missing punctuation in Overview section: > > OLD > > The IS-IS MIB defines the following objects > > NEW > > The IS-IS MIB defines the following objects: > > Fixed. > > > 10.) Technical content -- review of actual technical content for > > compliance with : > > > > (a) MIB compilation using smilint -- > > > > The program smilint 0.4.3, as of Mon Jan 17 19:25:32 2005 > > has been used to process your request as follows: > > > > smilint -m -s -e -l 6 mailbody > > > > mailbody:59: [1] {object-identifier-unknown} unknown object > > identifier label `mib-2' > > mailbody:6: [5] {import-unused} warning: identifier `experimental' > > imported from module `SNMPv2-SMI' is never used > > > > The problem is that the draft still IMPORTS 'experimental' instead > > of 'mib-2'. Proposed remedy: > > > > OLD: > > MODULE-IDENTITY, OBJECT-TYPE, Integer32, Unsigned32, > > Counter32, experimental, NOTIFICATION-TYPE > > NEW: > > MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, > > Integer32, Unsigned32, Counter32, mib-2 > > > > Note: the same results issue from SMICng. > > Fixed. > > > (b) In the MODULE-IDENTITY DESCRIPTION clause I think that > > jparker at world dot std dot edu needs to be changed to > > jparker at world dot std dot com. (I am not sure if the > > RFC Editor will let it remain in this form, but I guess > > it's worth a try :) > > Fixed. > > > (c) As noted in Section 4.6.4 of the MIB review guidelines, it is > > REQUIRED that each read-create table specify what happens to > > dynamically-created rows after an agent restart, and when a > > RowStatus column is present, it is necessary to specify whether > > modifications are allowed when the status column is 'active'. I > > don't thin[k] that these requirements have been met. > > These issues do not appear to have been addressed. That is likely > to elicit unfavorable AD review comments. I suggest that this be > fixed before submission to the IESG. > > > (d) I see that every InetAddress object has a SYNTAX value of > > InetAddress (SIZE(4|16)) and that every InetAddressPrefixLength > > object has a SYNTAX value of InetAddressPrefixLength (0..128), > > but the corresponding InetAddressType objects have a SYNTAX > > value of InetAddressType with no constraint but with a proviso > > in the DESCRIPTION clause that "[a]n implementation is only > > required to support IPv4 and IPv6 addresses." If the intent is > > to forever limit support to IPv4 and IPv6, which is the effect > > that the present SYNTAX refinements on the InetAddress and > > InetAddressPrefixLength objects have, then then it would > > be better to use a SYNTAX refinement in the InetAddressType > > objects to express that, rather than using text in the > > DESCRIPTION clause that is more appropriate in a compliance > > statement. Please note, however, that it is strongly preferred > > (at least in the MIB Doctor community) to have _no_ constraints > > in the definitions of objects of this type, and instead to put > > OBJECT clauses in the relevant compliance statements or, for > > inaccessible INDEX objects, text in the compliance statements' > > DESCRIPTION clauses. For a usage example in a similar application > > see draft-ietf-ipv6-rfc2096-update-07.txt, which defines the > > inetCidrRouteTable. Note that the lack of constraints on INDEX > > objects of type InetAddress leads to definitions that could, in > > principle, exceed the 128 sub-ID length on SNMP object names; > > as recommended in the MIB review guidelines Section 4.6.6, > > draft-ietf-ipv6-rfc2096-update-07.txt includes text in the > > inetCidrRouteEntry DESCRIPTION clause that spells out the > > limitations. > > Fixed. Results from smilint are now as follows: > > The program smilint 0.4.3, as of Fri Apr 01 10:26:14 2005 > has been used to process your request as follows: > > smilint -m -s -e -l 9 -i namelength-32 ISIS-MIB > > ISIS-MIB:602: [5] {index-exceeds-too-large} warning: index of row > `isisSummAddrEntry' can exceed OID size limit by 142 subidentifier(s) > ISIS-MIB:728: [5] {index-exceeds-too-large} warning: index of row > `isisRedistributeAddrEntry' can exceed OID size limit by 142 > subidentifier(s) > ISIS-MIB:2644: [5] {index-exceeds-too-large} warning: index of row > `isisIPRAEntry' can exceed OID size limit by 144 subidentifier(s) > > The DESCRIPTION clauses of isisSummAddrTable, > isisRedistributeAddrTable, > and isisIPRATable take note of these potential issues. > > > Note that the DESCRIPTION clause of every object of type > > InetAddress or InetAddressPrefixLength is REQUIRED to specify > > which InetAddressType object that provides the context in which > > is it interpreted, and none of the definitions in the module > > follow that rule. That needs to be corrected even if it is > > decided not to remove the constraints on the objects. > > Fixed. > > > (e) The DESCRIPTION clauses of isisSummAddressType, > > isisRedistributeAddrType, isisISAdjIPAddrType, isisIPRADestType, > > and isisIPRANextHopType include the sentence "[a]n implementation > > is only required to support IPv4 and IPv6 addresses." Similarly, > > the DESCRIPTION clauses of isisSummAddrExistState, > > isisRedistributeAddrExistState, isisCircExistState, > > isisRAExistState, and isisIPRAExistState include the sentence > > "[s]upport for createAndWait and notInService is not required." > > Since it is describing what an agent is required to do, rather > > than what makes "protocol sense" for the object to support, that > > type of language belongs in an OBJECT clause in a compliance > > statement, not in the object definition itself. > > Removing the IP version-specific syntactic constraints in the > OBJECT-TYPE definitions was a good thing, since it allows the > MIB module to support other address types in the future. However, > one needs to be aware that in the absence of OBJECT clauses or > text in the DESCRIPTION clause saying otherwise, this causes the > compliance statements to require that implementations support > all InetAddressType values. If this is not wanted, then at a > minimum it is necessary to add language in the DESCRIPTION clauses > of the compliance statements to the effect that an implementation > is only required to support global IPv4 and IPv6 addresses. For a > more elegant alternative, see the compliance statements in RFC 3289. > > I see that the DESCRIPTION clauses of the RowStatus objects mentioned > above are unchanged. This is acceptable since RFC 2579 explicitly > permits an agent not to support createAndWait and notInService. > > > (f) The DESCRIPTION clauses of isisManAreaAddr, > > isisSummAddressType, isisSummAddress, isisRedistributeAddrType, > > isisRedistributeAddrAddress, isisCircIndex, and isisRAIndex > > contain the sentence "[t]his object follows the index behavior" > > or an equivalent phrase. Similarly, the DESCRIPTION clauses of > > isisManAreaAddrExistState, isisSummAddrExistState, > > isisRedistributeAddrExistState, and isisCircExistState include > > the sentence "[t]his object follows the Row Status behavior." > > Finally, the DESCRIPTION clauses of isisCircAdminState and > > isisRAAdminState include the sentence "[t]his object follows > > the AdminState behavior" or an equivalent phrase. I'm not quite > > sure what these sentences are supposed to mean. If the intent is > > to say (respectively) "this is an INDEX object" or "this is a > > RowStatus object" or "this is an AdminState object" then there is > > no value in having them, since the INDEX clause of the enclosing > > table or the SYNTAX clause of the object already tells me what I > > need to know. If the intent is something else then it needs to > > be defined (as are the behaviors ResettingTimer, > > ReplaceOnlyWhileDisabled, and ManualOrAutomatic). > > Mostly fixed. The DESCRIPTION clause for isisRAIndex still contains > the sentence "This object follows the index behaviors." That sentence > should be removed. The DESCRIPTION clause for isisRAAdminState still > contains the sentence This object follows the AdminState and > ManualOrAutomatic behaviors." That should be changed to read > "This object follows the ManualOrAutomatic behaviors." > > > (g) I infer from the DESCRIPTION of the following object that > > it is set by a manager and then decremented each second by the > > agent until it becomes zero: > > > > isisSysLevelSetOverloadUntil OBJECT-TYPE > > SYNTAX Unsigned32(1..4294967295) > > UNITS "Seconds until clearing manually set Overload Bit" > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "If this object is non-zero, the overload bit is set at > > this level when the isisSysAdminState variable goes to > > state 'on' for this Intermediate System. The > overload bit > > remains set for isisSysLevelSetOverloadUntil seconds. > > When isisSysLevelSetOverloadUntil seconds have elapsed, > > the overload flag remains set if the implementation has > > run out of memory, or if it is set manually using the > > isisSysLevelSetOverload object." > > ::= { isisSysLevelEntry 6 } > > > > If that is the case, the SYNTAX value needs to be changed to > > include zero (e.g., Unsigned32 with no range constraint). > > Fixed. > > > (h) The DESCRIPTION clause of isisNextCircIndex does not seem > > to be entirely consistent with the DESCRIPTION clause of the > > IndexIntegerNextFree TC in RFC 3289. Here is a suggestion: > > > > OLD: > > isisNextCircIndex OBJECT-TYPE > > SYNTAX IndexIntegerNextFree > > 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." > > NEW: > > isisNextCircIndex OBJECT-TYPE > > SYNTAX IndexIntegerNextFree > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object is used to assist a management > > application in creating new rows in the > > isisCircTable. If it is possible to create > > a new instance of isisCircEntry, then this > > object will contain a non-zero value that > > is not in use as the index of any row in the > > isisCircTable. The network manager reads the > > value of this object and then (if the value > > value read is non-zero) attempts to create > > the corresponding instance of isisCircEntry. > > If the set request fails ith the code > > 'inconsistentValue', the the process must be > > repeated; if the set request succeeds, then > > the agent will change value of this object > > according to an implementation-specific > > algorithm." > > Fixed. > > > (i) From the fact that isisCircIfIndex has a SYNTAX value of > > InterfaceIndex (not InterfaceIndexOrZero) I infer that there > > there is always an ifTable entry associated with a circuit. > > That being the case, neither isisCircIndex nor isisCircIfIndex > > is strictly necessary -- one could use ifIndex as itself as > > the index, thereby eliminating the need for both of these > > objects. However, the existing design is acceptable. > > No change required. > > > (j) It seems to me that for at least some interface types > > the object isisCircIfSubSelector will be irrelevant. If > > that is true, then it would be good to specify that the > > object gets some distinguished value (e.g., 0 or -1) if > > it is not used. > > Fixed. > > > (k) The commentary just prior to the definition of isisRATable > > contains the following line: > > > > -- The Reachable Address Group is optional. > > > > I would recommend that this statement be removed. As a general > > rule, any statements on what is optional to implement and what > > is required should be in the compliance statements alone and > > should not be included in object descriptions or in the ASN.1 > > comments that surround them. > > Fixed. > > > (l) The DESCRIPTION clauses of isisRAIndex, isisIPRADestType, > > isisIPRADest, and isisIPRADestPrefixLen say that they follow he > > ManualOrAutomatic behavior. However, that behavior says the object > > is read-write or read-only, and so cannot apply to inaccessible > > index objects such as these (it can apply to the corresponding > > RowStatus object, which allows the row to be created or destroyed if > > appropriate). > > Fixed. > > > (m) The DESCRIPTION clause for the INDEX object isisLSPID reads: > > "The 8 byte LSP ID, consisting of the SystemID, > > Circuit ID, and Fragment Number." > > Maybe this is a stupid question, but shouldn't the > > isisLSPSummaryTable be concerning itself with entire reassembled > > link state PDUs and not individual fragments thereof? If so, > > perhaps the DESCRIPTION clause should be revised. (If this were > > IPv4, and I were describing a complete, reassembled IP PDU, I > > would specify that Fragment Offset=0 and MF=0, and I would also > > stipulate that the checksum is what would have been computed for > > the complete datagram prior to fragmentation. But perhaps those > > considerations don't apply here.) > > Review comment was based on a misconception. No change required. > > > (n) In the isisLSPTLVTable, the checksum and sequence number are > > provided for each TLV, but are properties of the LSP than contains > > them, or so I infer. If that is so, it might be good to change > > the DESCRIPTION clause of isisLSPTLVSeq as from: > > "The 16 bit Fletcher Checksum." > > to: > > "The 16 bit Fletcher Checksum for this LSP." > > Note that isisLSPTLVSeq already has similar language. > > Fixed. > > > (o) It would be less confusing to readers like me if the ASN.1 > > comment before the start of the notification definitions > > were changed from: > > -- Type definitions > > to: > > -- Notification definitions > > Fixed. > > > (p) I see the following language in several of the notification > > definitions: > > This should be an edge-triggered notification. > > We should not send a second notification about > > PDUs received from the same circuit. > > This seems to imply that no more than one such notification per > > circuit per agent reboot will be generated. What if the > > condition is persistent? Shouldn't there be additional > > notifications? One possible alternative that might be worth > > considering is allowing no more than one notification per circuit > > per interval of duration T (where T may be a design parameter that > > is fixed or the value of some read/write object). This is > > suggested in Sec. 4.7 of the MIB review guidelines. > > Fixed. > > > (q) In a related vein: are all of the notifications that lack > > explicit throttling by their nature generated at a sufficiently > > low rate that they will not cause an excess of notifications? A > > cursory reading suggests that this is so, but the author should > > verify that this is the case. > > No change required. > > > (r) Be aware that as written the compliance statements > > isisCompliance and isisAdvancedCompliance do not provide for > > read-only implementations of the MIB module. No changes need > > to be made if that is the intent, but the author should verify > > that this is the case. > > Fixed, except for one small omission: isisReadOnlyCompliance > does not have an OBJECT clause specifying a MIN-ACCESS of > 'read-only' for the writeable object isisCirc3WayEnabled. > That will need to be added. > > This concludes my review of . On > the whole, this looks like a very good MIB document, provided > that items 10(c), 10(e), 10(f), and 10(r) and the minor issues > with the references are addressed. > > Regards, > > Mike Heard > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Apr 18 15:52:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcIb-000053-Tk; Mon, 18 Apr 2005 15:52:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcIX-0008VR-7r; Mon, 18 Apr 2005 15:52:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24702; Mon, 18 Apr 2005 15:52:43 -0400 (EDT) Message-Id: <200504181952.PAA24702@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, 18 Apr 2005 15:52:43 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-caps-01.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 : IS-IS extensions for advertising router information Author(s) : J. Vasseur, et al. Filename : draft-ietf-isis-caps-01.txt Pages : 8 Date : 2005-4-18 This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-caps-01.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-caps-01.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-caps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-18162015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-caps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-caps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-18162015.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Apr 29 15:02:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRakc-0000bP-92; Fri, 29 Apr 2005 15:02:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRaka-0000bK-Od for isis-wg@megatron.ietf.org; Fri, 29 Apr 2005 15:02:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28639 for ; Fri, 29 Apr 2005 15:02:07 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRaxh-0004JE-4f for isis-wg@ietf.org; Fri, 29 Apr 2005 15:15:42 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Fri, 29 Apr 2005 15:01:57 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Apr 2005 15:01:56 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.181 140.233.20.181 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 29 Apr 2005 15:01:55 -0400 From: "Parker, Jeff" To: ISIS WG Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 29 Apr 2005 19:01:56.0832 (UTC) FILETIME=[EA17DE00:01C54CED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "C. M. Heard" , "Wijnen, Bert \(Bert\)" Subject: [Isis-wg] Draft 20 of 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 just posted a version of the IS-IS MIB to the IETF. The changes represent a couple of revisions supervised by Mike Heard, our MIB Doctor. The changes are listed below, and will not be found in the body of the MIB as they have in the past. I will be happy to send a copy of the MIB, Draft, and differences to interested parties off-line. - jeff parker -- Changes in version 20 -- Statement on the survivability of dynamic rows for each table. -- Statement about modifying rows with RowStatus field -- Modified descriptions for isisRAIndex and isisRAAdminState -- Added text to the read-only conformance -- Added Read-Compliance object block for isisCirc3WayEnabled -- Fixed references -- Added Objects describing InetAddressType for the uses -- OBJECT isisSummAddressType -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } -- -- DESCRIPTION -- The MIB requires support for IPv4 Summary -- Addresses, and anticipates the support of -- IPv6 addresses. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg