From isis-wg-bounces@ietf.org Mon May 02 15:52:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgyR-0007J7-Qg; Mon, 02 May 2005 15:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSgyN-0007GI-NF; Mon, 02 May 2005 15:52:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27013; Mon, 2 May 2005 15:52:54 -0400 (EDT) Message-Id: <200505021952.PAA27013@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, 02 May 2005 15:52:53 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-20.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-20.txt Pages : 101 Date : 2005-5-2 This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.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-20.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-20.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-5-2155014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-2155014.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 Mon May 02 18:08:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSj5O-0000Gd-BZ; Mon, 02 May 2005 18:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSj5M-0000GI-Cn for isis-wg@megatron.ietf.org; Mon, 02 May 2005 18:08:16 -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 SAA21057 for ; Mon, 2 May 2005 18:08:13 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSjJ6-0003kS-3z for isis-wg@ietf.org; Mon, 02 May 2005 18:22:29 -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 j42M7woF008865; Mon, 2 May 2005 15:07:58 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j42M7uqV031597; Mon, 2 May 2005 15:07:56 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j42M7tCN031591; Mon, 2 May 2005 15:07:56 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 2 May 2005 15:07:55 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Wijnen, Bert \(Bert\)" Subject: [Isis-wg] Re: 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 On Fri, 29 Apr 2005, Parker, Jeff wrote: > 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. I see that this version has now made its appearance in the repository. All of the issues that I raised in previous MIB Doctor reviews have been addressed. Thanks, Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue May 03 04:39:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSswd-0006xT-IH; Tue, 03 May 2005 04:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSswc-0006xO-4R for isis-wg@megatron.ietf.org; Tue, 03 May 2005 04:39:54 -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 EAA14418 for ; Tue, 3 May 2005 04:39:51 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DStAR-00021u-Pz for isis-wg@ietf.org; Tue, 03 May 2005 04:54:13 -0400 Received: by wproxy.gmail.com with SMTP id 71so1707937wri for ; Tue, 03 May 2005 01:39:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OcegB6wqA8S/rG5VpE9jJHXVdSB/iOWXJDD7JLobO5PJxl62UBfIT7nozwVe96XBYilO/3Z+ctQCt0BUn0XPUs9gi/pL7cPEAyT8ZZ9H7cq42YtA5mpS1UiTkrVCskJK8O3y0xAlzUktc4dKYMdVgXflJwRVtXQpzQIkHH5u+qA= Received: by 10.54.122.11 with SMTP id u11mr966761wrc; Tue, 03 May 2005 01:39:43 -0700 (PDT) Received: by 10.54.99.9 with HTTP; Tue, 3 May 2005 01:39:43 -0700 (PDT) Message-ID: Date: Tue, 3 May 2005 14:09:43 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Subject: [Isis-wg] Changing the System ID X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, When a user changes the system ID of an ISIS router isnt that equivalent of shutting down ISIS running on a router and creating a fresh ISIS instance there. I say this because with the new system ID, this ISIS router will now originate "new" LSPs which will not match with the earlier LSPs that other ISIS routers had recieved. I am concerned about some intermediate time till which other systems dont time out their adjacency with the earlier instance of this ISIS router. Let me explain my doubt: R1 -- R2 System ID of R1 is "A" and its changed to "B" at time t=3D0 Before t=3D0, R1 and R2 were ISIS peers and R2 had LSPs from R1 with the system ID as A. Now at t=3D0, R1 starts sending HELLOs and all with the system ID of B. R2 thinks that a new router has come up and starts initiating the adjecency with this router. Meanwhile, ISIS adjacency with "A" is also up on R2 as the Hold Time on R2 has not expired. So R2 maintains adjacencies with "A" and "B" till the Hold time expires on R2. Can this not create a problem? One good point that i see in this scheme is that it provides a seamless transition from system ID "A" and "B" because whatever routes R2 had installed and learnt from "A" are kept till the Hold Time expires. It then learns those same addresses from instance "B" and traffic is never dropped. Is my understanding of this correct? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed May 04 01:07:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTC6N-0000r2-Pc; Wed, 04 May 2005 01:07:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTC6J-0000qu-Qx for isis-wg@megatron.ietf.org; Wed, 04 May 2005 01:07:12 -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 BAA16335 for ; Wed, 4 May 2005 01:07:10 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTCKL-0001tw-EO for isis-wg@ietf.org; Wed, 04 May 2005 01:21:41 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 May 2005 22:06:23 -0700 X-IronPort-AV: i="3.92,152,1112598000"; d="scan'208"; a="258070896:sNHT3335415368" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4455UiW006863; Tue, 3 May 2005 22:06:21 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 May 2005 22:06:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Changing the System ID Date: Tue, 3 May 2005 22:06:12 -0700 Message-ID: Thread-Topic: [Isis-wg] Changing the System ID Thread-Index: AcVPvELKYj/ElgSiQLuwLnU5gMFl2gAqTR1Q From: "Les Ginsberg \(ginsberg\)" To: "Abhishek Verma" , "ISIS-WG \(E-mail\)" X-OriginalArrivalTime: 04 May 2005 05:06:13.0416 (UTC) FILETIME=[FE5A8A80:01C55066] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > -----Original Message----- > From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf > Of Abhishek Verma > Sent: Tuesday, May 03, 2005 1:40 AM > To: ISIS-WG (E-mail) > Subject: [Isis-wg] Changing the System ID >=20 > Hi, >=20 > When a user changes the system ID of an ISIS router isnt that > equivalent of shutting down ISIS running on a router and creating a > fresh ISIS instance there. >=20 > I say this because with the new system ID, this ISIS router will now > originate "new" LSPs which will not match with the earlier LSPs that > other ISIS routers had recieved. >=20 > I am concerned about some intermediate time till which other systems > dont time out their adjacency with the earlier instance of this ISIS > router. >=20 > Let me explain my doubt: >=20 > R1 -- R2 >=20 > System ID of R1 is "A" and its changed to "B" at time t=3D0 >=20 > Before t=3D0, R1 and R2 were ISIS peers and R2 had LSPs from R1 with = the > system ID as A. Now at t=3D0, R1 starts sending HELLOs and all with = the > system ID of B. R2 thinks that a new router has come up and starts > initiating the adjecency with this router. Meanwhile, ISIS adjacency > with "A" is also up on R2 as the Hold Time on R2 has not expired. >=20 > So R2 maintains adjacencies with "A" and "B" till the Hold time > expires on R2. Can this not create a problem? >=20 Abhishek - A good reference on this topic is RFC 3719 Section 9. In summary, implementations SHOULD delete the adjacency immediately upon noting a neighbor system ID change - the nuances of that are well discussed in RFC 3719. You can also consult ISO 10589:2002 Section 8.2.5.2d which, contrary to what is stated in RFC 3719, does actually specify that the adjacency SHOULD be deleted in cases of receiving a PDU with a new System ID (this was corrected from the 1992 version). A system which is going to change its system ID can insure that the adjacency goes down by sending an IIH using the old System ID and a zero hold time prior to beginning use of the new SystemID. Les > One good point that i see in this scheme is that it provides a > seamless transition from system ID "A" and "B" because whatever routes > R2 had installed and learnt from "A" are kept till the Hold Time > expires. It then learns those same addresses from instance "B" and > traffic is never dropped. >=20 > Is my understanding of this correct? >=20 > Thanks, > Abhishek >=20 > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed May 04 22:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTW8w-0003O5-QZ; Wed, 04 May 2005 22:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTW8v-0003Nr-9w for isis-wg@megatron.ietf.org; Wed, 04 May 2005 22:31:13 -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 WAA10919 for ; Wed, 4 May 2005 22:31:10 -0400 (EDT) Received: from web25403.mail.ukl.yahoo.com ([217.12.10.137]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DTWN3-0004Az-3y for isis-wg@ietf.org; Wed, 04 May 2005 22:45:54 -0400 Received: (qmail 60360 invoked by uid 60001); 5 May 2005 02:30:58 -0000 Message-ID: <20050505023058.60358.qmail@web25403.mail.ukl.yahoo.com> Received: from [66.17.149.13] by web25403.mail.ukl.yahoo.com via HTTP; Thu, 05 May 2005 03:30:58 BST Date: Thu, 5 May 2005 03:30:58 +0100 (BST) From: "Sugar, Sylvia" To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 8bit Subject: [Isis-wg] Route Leaking X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, Please correct me if my understanding of the protocol is not correct. A -- B ----- C ---- D L1 L1/L2 L2 L1 A and B are in the same area, say X. C and D are in a different area, say Y. A and B have a L1 adjacency B and C have an L2 adjacency and C and D have an L1 adjacency A has some routes with it, say 10/8 and 11/8. It advertises these routes to B in its L1 LSPs. B would now advertise 10/8 and 11/8 in its L2 LSPs to C. Is this correct? But only if route leaking from L2 to L1 is there will 10/8 and 11/8 figure in L1 LSPs issued by C for D. By default, this will not happen. Would appreciate if someone could confirm that my understanding of this matter is indeed correct. Thanks, Sylvia ___________________________________________________________ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed May 04 22:35:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTWDM-00044R-K2; Wed, 04 May 2005 22:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTWDK-00044M-PB for isis-wg@megatron.ietf.org; Wed, 04 May 2005 22:35: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 WAA11327 for ; Wed, 4 May 2005 22:35:44 -0400 (EDT) Received: from ish6.telecom.co.nz ([146.171.13.196] helo=smtp3.telecom.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTWRW-0004QU-B0 for isis-wg@ietf.org; Wed, 04 May 2005 22:50:28 -0400 Received: from aksmtpmdr1 (ish2-internal [146.171.1.20]) by smtp3.telecom.co.nz (Postfix) with ESMTP id 1FBA11C4D; Thu, 5 May 2005 14:31:02 +1200 (NZST) Received: from 146.171.227.24 by aksmtpmdr1 with ESMTP (Tumbleweed MMS SMTP Relay); Thu, 05 May 2005 14:34:51 +1200 X-Server-Uuid: 50880B64-500D-4147-A4F0-826C22747D83 Received: from AUNSWA003.au.tcnz.net ([10.136.168.51]) by akexsmtp01.telecom.tcnz.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 May 2005 14:34:40 +1200 Received: from aunswa002.au.tcnz.net ([10.136.168.50]) by AUNSWA003.au.tcnz.net with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 May 2005 12:34:38 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isis-wg] Route Leaking Date: Thu, 5 May 2005 12:34:38 +1000 Message-ID: <44CF9D8D25966C4DB1072958419273DB01294CD0@aunswa002.au.tcnz.net> Thread-Topic: [Isis-wg] Route Leaking thread-index: AcVRGp08mGwreWLQRVK4AE0Hgi4S9AAADHaw From: "Paresh Khatri" To: "Sugar, Sylvia" , isis-wg@ietf.org X-OriginalArrivalTime: 05 May 2005 02:34:38.0855 (UTC) FILETIME=[FBFC6970:01C5511A] X-WSS-ID: 6E6759C11JS2221162-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Sylvia, ISIS will not even run between L1 and L2 since there is no common = circuit-type between them. You would have to make at least one of those an= = L1/L2 router or no ISIS adjacency between them will ever form. Cheers, Paresh. -----Original Message----- =46rom: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Sugar, Sylvia Sent: Thursday, 05 May 2005 12:31 PM To: isis-wg@ietf.org Subject: [Isis-wg] Route Leaking Hi, Please correct me if my understanding of the protocol is not correct. A -- B ----- C ---- D L1 L1/L2 L2 L1 A and B are in the same area, say X. C and D are in a different area, say Y. A and B have a L1 adjacency B and C have an L2 adjacency and C and D have an L1 adjacency A has some routes with it, say 10/8 and 11/8. It advertises these routes to= = B in its L1 LSPs. B would now advertise 10/8 and 11/8 in its L2 LSPs to C. Is this correct=3F But only if route leaking from L2 to L1 is there will 10/8 and 11/8 figure = in L1 LSPs issued by C =66or D. By default, this will not happen. Would appreciate if someone could confirm that my understanding of this = matter is indeed correct. Thanks, Sylvia =09 =09 =09 ___________________________________________________________=20 Yahoo! Messenger - want a free and easy way to contact your friends = online=3F http://uk.messenger.yahoo.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg This communication, including any attachments, is confidential. If=20 you are not the intended recipient, you should not read it - please=20 contact me immediately, destroy it, and do not copy or use any part of=20 this communication or disclose anything about it. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu May 05 00:15:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTXlZ-0007GR-Vj; Thu, 05 May 2005 00:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTXlY-0007GL-Cq for isis-wg@megatron.ietf.org; Thu, 05 May 2005 00:15:12 -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 AAA21709 for ; Thu, 5 May 2005 00:15:09 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTXzl-0001R0-47 for isis-wg@ietf.org; Thu, 05 May 2005 00:29:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IG0005UI1BR4I@szxga02-in.huawei.com> for isis-wg@ietf.org; Thu, 05 May 2005 12:19:03 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IG000CPC1BRCM@szxga02-in.huawei.com> for isis-wg@ietf.org; Thu, 05 May 2005 12:19:03 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IG000DJB1BLQ0@szxml02-in.huawei.com>; Thu, 05 May 2005 12:18:59 +0800 (CST) Date: Thu, 05 May 2005 09:45:05 +0530 From: hemanthbs Subject: RE: [Isis-wg] Route Leaking In-reply-to: <20050505023058.60358.qmail@web25403.mail.ukl.yahoo.com> To: "'Sugar, Sylvia'" , isis-wg@ietf.org Message-id: <003501c55129$056a51d0$0a1110ac@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@huawei.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Sylvia, Presuming that C is an L1L2 router and it's a typing error that you have made in the below diagram, your understanding is perfectly right. bye S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Sugar, Sylvia Sent: Thursday, May 05, 2005 8:01 AM To: isis-wg@ietf.org Subject: [Isis-wg] Route Leaking Hi, Please correct me if my understanding of the protocol is not correct. A -- B ----- C ---- D L1 L1/L2 L2 L1 A and B are in the same area, say X. C and D are in a different area, say Y. A and B have a L1 adjacency B and C have an L2 adjacency and C and D have an L1 adjacency A has some routes with it, say 10/8 and 11/8. It advertises these routes to B in its L1 LSPs. B would now advertise 10/8 and 11/8 in its L2 LSPs to C. Is this correct? But only if route leaking from L2 to L1 is there will 10/8 and 11/8 figure in L1 LSPs issued by C for D. By default, this will not happen. Would appreciate if someone could confirm that my understanding of this matter is indeed correct. Thanks, Sylvia ___________________________________________________________ Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com _______________________________________________ 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 Sun May 08 03:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUgLJ-0002rB-UF; Sun, 08 May 2005 03:36:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUgLI-0002r3-Vs for isis-wg@megatron.ietf.org; Sun, 08 May 2005 03:36:49 -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 DAA21380 for ; Sun, 8 May 2005 03:36:47 -0400 (EDT) Received: from c-230.static.at.kpnqwest.net ([193.154.188.230] helo=ghostrider.gredler.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUga8-0003XO-JM for isis-wg@ietf.org; Sun, 08 May 2005 03:52:09 -0400 Received: from ghostrider.gredler.at (localhost [127.0.0.1]) by ghostrider.gredler.at (8.13.3/8.13.1) with ESMTP id j487cc86010982; Sun, 8 May 2005 09:38:38 +0200 Received: (from hannes@localhost) by ghostrider.gredler.at (8.13.3/8.13.3/Submit) id j487cbuq010981; Sun, 8 May 2005 09:38:37 +0200 Date: Sun, 8 May 2005 09:38:37 +0200 From: Hannes Gredler To: "'Sugar, Sylvia'" Subject: Re: [Isis-wg] Route Leaking Message-ID: <20050508073837.GA10935@juniper.net> References: <20050505023058.60358.qmail@web25403.mail.ukl.yahoo.com> <003501c55129$056a51d0$0a1110ac@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003501c55129$056a51d0$0a1110ac@china.huawei.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 in addition the length of prefixes that you would want to leak from L2 to L1 is unlikely to be /8 but rather /32; the whole point of route-leaking is to give the route-resolver in the L1 an idea of distance to specific BGP NEXT_HOPS. in order to give a _specific_ idea you also would advertise the most _specific_ prefix which is for IPv4 a /32; /hannes On Thu, May 05, 2005 at 09:45:05AM +0530, hemanthbs wrote: | Hi Sylvia, | | Presuming that C is an L1L2 router and it's a typing error that you have | made in the below diagram, your understanding is perfectly right. | | bye | | S.Hemanth Balaji. | Software Engineer. | Huawei Technologies India Pvt Ltd. | Bangalore, India. | | | -----Original Message----- | From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On | Behalf Of Sugar, Sylvia | Sent: Thursday, May 05, 2005 8:01 AM | To: isis-wg@ietf.org | Subject: [Isis-wg] Route Leaking | | Hi, | | Please correct me if my understanding of the protocol is not correct. | | A -- B ----- C ---- D | L1 L1/L2 L2 L1 | | A and B are in the same area, say X. | C and D are in a different area, say Y. | | A and B have a L1 adjacency | B and C have an L2 adjacency | and C and D have an L1 adjacency | | A has some routes with it, say 10/8 and 11/8. It advertises these routes | to B in its L1 LSPs. B | would now advertise 10/8 and 11/8 in its L2 LSPs to C. Is this correct? | | But only if route leaking from L2 to L1 is there will 10/8 and 11/8 | figure in L1 LSPs issued by C | for D. By default, this will not happen. | | Would appreciate if someone could confirm that my understanding of this | matter is indeed correct. | | Thanks, | Sylvia | | | | | | ___________________________________________________________ | Yahoo! Messenger - want a free and easy way to contact your friends | online? http://uk.messenger.yahoo.com | | _______________________________________________ | 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 | -- _____________________________________________________ hannes gredler mobile: +43 676 9380638 network support engineer email: hannes@juniper.net juniper networks inc., skype: hannesgredler9000 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon May 09 15:54:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVEKn-0003Ey-7W; Mon, 09 May 2005 15:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVEKj-0003EK-SF; Mon, 09 May 2005 15:54:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26200; Mon, 9 May 2005 15:54:28 -0400 (EDT) Message-Id: <200505091954.PAA26200@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, 09 May 2005 15:54:27 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-10.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : M-ISIS: Multi Topology (MT) Routing in IS-IS Author(s) : T. Przygienda, et al. Filename : draft-ietf-isis-wg-multi-topology-10.txt Pages : 12 Date : 2005-5-9 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-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-multi-topology-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-10.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-5-9160012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-9160012.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 Tue May 10 04:16:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVPun-0007bh-70; Tue, 10 May 2005 04:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVPul-0007bc-4y for isis-wg@megatron.ietf.org; Tue, 10 May 2005 04:16: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 EAA26859 for ; Tue, 10 May 2005 04:16:24 -0400 (EDT) Received: from 46.106-14-84.ripe.coltfrance.com ([84.14.106.46] helo=eagle.6wind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVQA0-0005XO-Vd for isis-wg@ietf.org; Tue, 10 May 2005 04:32:14 -0400 Received: from [127.0.0.1] (unknown [10.16.0.104]) by eagle.6wind.com (Postfix) with ESMTP id 2084D228 for ; Tue, 10 May 2005 10:16:23 +0200 (CEST) Message-ID: <42806D62.6090104@6WIND.com> Date: Tue, 10 May 2005 10:14:26 +0200 From: Mohit Thakur Organization: 6WIND User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Isis-wg] External route addition! X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, I have some basic doubts and would be helpful if anyone can clear them. Lets take a simple network: R1 ------ R2 Two routers R1 & R2 are connected and have IS-IS running on them (Level 1). The routers will build up adjancencies with the hello packets when they are turned on. The LSPDatabase for R1 will have two LSPs one of router R1 (itself) and the other for router R2. Now if any external route is added in the router R1 (lets say statically), R1 should add it in the LSPDB but in the R1's own LSP. Now: 1) When external routes are added in R1, do they have to be associated to any circuit, initially? After this, if i understand the protocol well (please correct me if i don't), when any external route is added, the LSP (non pseudonode, in this case LSP-L1) is generated and is sent to all the circuits. This LSP will have the tlv data field for external routes. So to understand it properly: 2) The LSP will be generated on the addition of external routes. Are the LSPs generated on the topological change and timer expiration itself? 3) Is the role of CSNP just to help maintain the same Database in all routers by sending the list of LSPs and we call it so called update? Thanks for your time and your help also. Mohit Thakur R&D Trainee, 6WIND, France _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue May 10 05:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVRQe-0005CS-Rg; Tue, 10 May 2005 05:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVRQc-0005CM-KR for isis-wg@megatron.ietf.org; Tue, 10 May 2005 05:53: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 FAA02923 for ; Tue, 10 May 2005 05:53:24 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVRfs-0001og-Sy for isis-wg@ietf.org; Tue, 10 May 2005 06:09:15 -0400 Received: by wproxy.gmail.com with SMTP id 71so2028703wri for ; Tue, 10 May 2005 02:53:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LrAeIairEYOfs93H0zRDDXm5NM43Vy64rCc0wjGlDiUaAAszA5Y5nQ1fCsDSGGn61UL1U2M8SHnVis4DPmtCmPS+xTeMfmSOMW/fAqfcSoZpB7zCTj39xTTUeaqU6CKYOy9bA8X3Mf4vhg7QPf9YkN5SzMZ2n27kP/BYi8s0i/s= Received: by 10.54.37.77 with SMTP id k77mr407833wrk; Tue, 10 May 2005 02:53:15 -0700 (PDT) Received: by 10.54.99.9 with HTTP; Tue, 10 May 2005 02:53:15 -0700 (PDT) Message-ID: Date: Tue, 10 May 2005 15:23:15 +0530 From: Abhishek Verma To: Mohit Thakur Subject: Re: [Isis-wg] External route addition! In-Reply-To: <42806D62.6090104@6WIND.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42806D62.6090104@6WIND.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi Mohit, Let me attempt to help you here. =20 > R1 ------ R2 >=20 > Two routers R1 & R2 are connected and have IS-IS running on them (Level 1= ). >=20 > The routers will build up adjancencies with the hello packets when they > are turned on. The LSPDatabase for R1 will have two LSPs one of router > R1 (itself) and the other for router R2. Yes, and a pseudonode LSP issued by whichever router is the DIS on this circuit (assuming this to be on a LAN) >=20 > Now if any external route is added in the router R1 (lets say > statically), R1 should add it in the LSPDB but in the R1's own LSP. You would add this static route in the LSDB only if you have redistributed static routes into ISIS. > Now: >=20 > 1) When external routes are added in R1, do they have to be associated > to any circuit, initially? No. I assume by 'circuit' you mean an interface over which ISIS is running. No, you could add a static route over an interface which may not be running ISIS. >=20 > After this, if i understand the protocol well (please correct me if i > don't), when any external route is added, the LSP (non pseudonode, in > this case LSP-L1) is generated and is sent to all the circuits. This LSP > will have the tlv data field for external routes. Yes. >=20 > So to understand it properly: > 2) The LSP will be generated on the addition of external routes.=20 Yes > Are the > LSPs generated on the topological change and timer expiration itself? Yes, LSPs are re-generated when topology changes/reachability changes/ and/or timer expirations. >=20 > 3) Is the role of CSNP just to help maintain the same Database in all > routers by sending the list of LSPs and we call it so called update? Yes. Thanks, Abhishek. >=20 > Thanks for your time and your help also. >=20 > Mohit Thakur >=20 > R&D Trainee, > 6WIND, France >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg >=20 --=20 -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed May 11 10:08:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVrsq-0000lT-UO; Wed, 11 May 2005 10:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV7vP-00011B-67 for isis-wg@megatron.ietf.org; Mon, 09 May 2005 09:03: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 JAA08709 for ; Mon, 9 May 2005 09:03:53 -0400 (EDT) Received: from 46.106-14-84.ripe.coltfrance.com ([84.14.106.46] helo=eagle.6wind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV8AV-0007U0-2h for isis-wg@ietf.org; Mon, 09 May 2005 09:19:32 -0400 Received: from [127.0.0.1] (unknown [10.16.0.104]) by eagle.6wind.com (Postfix) with ESMTP id 273D629C for ; Mon, 9 May 2005 15:03:51 +0200 (CEST) Message-ID: <427F5F43.6060705@6WIND.com> Date: Mon, 09 May 2005 15:01:55 +0200 From: Mohit Thakur Organization: 6WIND User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 May 2005 10:08:20 -0400 Subject: [Isis-wg] External route anouncement! X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, I have few basic doubts, please clear them if you can. Lets take the scenario of a simple network, having two routers: R1 ---------- R2 R1 directly connected to R2 and running IS-IS between them (Level 1). If an external route is added to R1 (lets say statically), then... 1) The router R1 will be reported of an event, reaction to which would be a generation of an LSP L1? 2) If yes, the L1 - LSP generated will have an external reachability field and this new route will be contained in that field, i think its correct? 3) After this the CSNP will be exchanged regularly, is that th correct order of event happening? 4) So ultimately the role of CSNP is to check (so called update) LSPDatabase of the CSNP originator router with all the routers in the area, when no topological change takes place. And the LSP is generated whenever the topological change takes place? Thanks for your time and also for clearing my doubts. Mohit Thakur R&D Trainee, 6WIND, France _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu May 12 02:54:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7aG-00031a-0B; Thu, 12 May 2005 02:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW7aE-000307-1d for isis-wg@megatron.ietf.org; Thu, 12 May 2005 02:54:10 -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 CAA28969 for ; Thu, 12 May 2005 02:54:08 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW7pt-0006GC-3L for isis-wg@ietf.org; Thu, 12 May 2005 03:10:22 -0400 Received: by wproxy.gmail.com with SMTP id 71so527582wri for ; Wed, 11 May 2005 23:53:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NcGAX1Gh92pnWXZlk2Sy8WuOCJVgSlH5jWLvoHz2R5/ErdH5hBLbm5z5vSw+xb/LSo0vUXtGcdiAhyj1unGbm15YB0+uAzdBrijPtx75PZFNPnZJcJtshpxeEQjPLIZMJDsMb5c0uN8dX3MYWd1YDCehxqG60vfNnOSdfeaarVk= Received: by 10.54.40.35 with SMTP id n35mr953623wrn; Wed, 11 May 2005 23:53:59 -0700 (PDT) Received: by 10.54.102.14 with HTTP; Wed, 11 May 2005 23:53:59 -0700 (PDT) Message-ID: Date: Thu, 12 May 2005 12:23:59 +0530 From: Abhishek Verma To: Mohit Thakur Subject: Re: [Isis-wg] External route anouncement! In-Reply-To: <427F5F43.6060705@6WIND.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <427F5F43.6060705@6WIND.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 > R1 ---------- R2 > R1 directly connected to R2 and running IS-IS between them (Level 1). If > an external route is added to R1 (lets say statically), then... >=20 > 1) The router R1 will be reported of an event, reaction to which would > be a generation of an LSP L1? Yes. > 2) If yes, the L1 - LSP generated will have an external reachability > field and this new route will be contained in that field, i think its > correct? Yes. > 3) After this the CSNP will be exchanged regularly, is that th correct > order of event happening? Yes. > 4) So ultimately the role of CSNP is to check (so called update) > LSPDatabase of the CSNP originator router with all the routers in the > area, when no topological change takes place. And the LSP is generated > whenever the topological change takes place? Yes. >=20 > Thanks for your time and also for clearing my doubts. >=20 > Mohit Thakur > R&D Trainee, > 6WIND, France >=20 -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri May 13 15:48:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWg91-00010K-Hq; Fri, 13 May 2005 15:48:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWg8w-0000z0-TO; Fri, 13 May 2005 15:48:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21663; Fri, 13 May 2005 15:48:16 -0400 (EDT) Message-Id: <200505131948.PAA21663@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 13 May 2005 15:48:16 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-caps-02.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-02.txt Pages : 8 Date : 2005-5-13 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-02.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-02.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-02.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-5-13155939.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-caps-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-caps-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-13155939.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 Wed May 18 11:43:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQhi-00042H-UN; Wed, 18 May 2005 11:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYQhi-00042B-AV for isis-wg@megatron.ietf.org; Wed, 18 May 2005 11:43:26 -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 LAA04036 for ; Wed, 18 May 2005 11:43:23 -0400 (EDT) Received: from adsl-66-120-207-101.dsl.sntc01.pacbell.net ([66.120.207.101] helo=coffee.rawdofmt.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYQyg-0005wJ-5j for isis-wg@ietf.org; Wed, 18 May 2005 12:00:59 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by coffee.rawdofmt.org (Postfix) with ESMTP id 5B15B3DCCAD for ; Wed, 18 May 2005 08:43:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ISIS WG From: Christian Hopps Date: Wed, 18 May 2005 08:43:10 -0700 X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Isis-wg] WG Last Call on IS-IS 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 As the MIB doctor review is complete the IS-IS MIB is now in WG last call. Please recall that we are only looking for issues with the current version of the MIB as we need to get this document published. It was pointed out that we could add support for graceful restart; however, changes such as this will have to be addressed in a later revision of the MIB. Please post any comments by June 1st. Chris and Dave. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu May 19 15:46:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqy1-0006MD-Bq; Thu, 19 May 2005 15:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYqxx-0006H9-9d; Thu, 19 May 2005 15:45:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14854; Thu, 19 May 2005 15:45:55 -0400 (EDT) Message-Id: <200505191945.PAA14854@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 19 May 2005 15:45:55 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-experimental-tlv-05.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 : TLV for Experimental Use Author(s) : P. Christian Filename : draft-ietf-isis-experimental-tlv-05.txt Pages : 0 Date : 2005-5-19 This document defines a TLV that may be used by any individual, company or other organisation for experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-05.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-experimental-tlv-05.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-experimental-tlv-05.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-5-19153545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-experimental-tlv-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-experimental-tlv-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-19153545.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 Tue May 24 06:45:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaWug-000621-8c; Tue, 24 May 2005 06:45:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaWuf-00061m-CQ for isis-wg@megatron.ietf.org; Tue, 24 May 2005 06:45:29 -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 GAA15884 for ; Tue, 24 May 2005 06:45:26 -0400 (EDT) Received: from oceanus.uk.clara.net ([80.168.70.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaXCn-0005hL-8T for isis-wg@ietf.org; Tue, 24 May 2005 07:04:15 -0400 Received: from claranet by oceanus.uk.clara.net with local (Exim 4.22) id 1DaWua-000Dkz-MS; Tue, 24 May 2005 11:45:24 +0100 From: "Adrian Farrel" To: isis-wg@ietf.org Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB. Date: Tue, 24 May 2005 11:45:24 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Remote_Addr: 156.106.205.69 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: adrian@olddog.co.uk X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, I have a few comments on the MIB module. Cheers, Adrian 1. Imports It is useful to indicate the RCF from which the import is taken. For example... TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32, Unsigned32, Counter32, mib-2 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] 2. AdminState TC AdminState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Type used in enabling and disabling a row. Values match those in RFC 2863." SYNTAX INTEGER { on(1), off(2) } Note that while the values *do* match RFC2863, - the names for the values are different ("up" and "down"_ - RFC2863 also defines testing(3) Perhaps best just to delete the reference to RFC2863? 3. Choice between unsigned32 and integer32 The choice between these Syntaxes appears a bit arbitrary throughout. Perhaps you just need to check that you are happy with the choice and that the MIB Doctor agrees. 4. isisSysType isisSysType OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2), level1L2IS (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "At which levels is the Intermediate System running? This object may not be modified when the isisSysAdminState variable is in state 'on' for this Intermediate System." REFERENCE "{ISIS.aoi iSType (2)}" DEFVAL { level1L2IS } ::= { isisSysObject 2 } Why don't you use SYNTAX IsisAdjLevel ? Is it the name of the TC that puts you off? In which case perhaps change the name? 5. isisManAreaAddrExistState isisManAreaAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisManAreaAddrEntry. If the isisSysAdminState for this Intermediate System is 'on', and an attempt is made to set this object to the value 'destroy' or 'notInService' when this is the only isisManAreaAddrEntry in state 'active' for this Intermediate System should return inconsistentValue. A row entry cannot be modified when the value of this object is 'active'." ::= { isisManAreaAddrEntry 2 } Since the only objects are the index and the row status it may be superfluous to say that the row entry cannot be modified. 6. isisRedistributeAddrExistState Ditto point 5. 7. isisSysLevelSetOverloadUntil isisSysLevelSetOverloadUntil OBJECT-TYPE SYNTAX Unsigned32 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 } I think you also need to describe what happens if you set isisSysLevelSetOverload to false when isisSysLevelSetOverloadUntil is non-zero. 8. isisCircLevel Ditto point 4. 9. isisCircLastUpTime isisCircLastUpTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "Seconds since startup when this circuit was last 'on'" MAX-ACCESS read-only STATUS current DESCRIPTION "If the circuit is enabled, the number of seconds since system startup when isisCircAdminState most recently entered the state 'on', or 0 if the circuit has never been 'on'." ::= { isisCircEntry 13 } Wouldn't we usually use SYNTAX TimeStamp from RFC2579? 10. Counters Don't we need some description of the discontinuity behavior of the counters? 11. Wide counters Are you happy with running the hello and packet counters at only 32 bits? Woth considering how often they would wrap in normal (default timer) processing. Then note that they would be used to diagnose misconfiguration of timers when packet thrash might occur. 12. isisISAdjLastUpTime Ditto point 9. 13. Notifications Can we turn off notifications? 14. I-D nits Note also that running the idnits script generates a few other minor issues. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed May 25 12:54:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daz9O-0005Zy-WA; Wed, 25 May 2005 12:54:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daz9N-0005Z5-2U for isis-wg@megatron.ietf.org; Wed, 25 May 2005 12:54:33 -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 MAA29758 for ; Wed, 25 May 2005 12:54:30 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DazRm-0002oG-00 for isis-wg@ietf.org; Wed, 25 May 2005 13:13:35 -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 j4PGsBIg007118; Wed, 25 May 2005 09:54:11 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j4PGs4R0024058; Wed, 25 May 2005 09:54:04 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j4PGs2UM024047; Wed, 25 May 2005 09:54:03 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 25 May 2005 09:54:02 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "Wijnen, Bert \(Bert\)" 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 Tue, 24 May 2005, Adrian Farrel wrote: > I have a few comments on the MIB module. Glad to see these comments. I'd like to amplify on a few points. > 1. Imports > It is useful to indicate the RCF from which the import is taken. > For example... > > TEXTUAL-CONVENTION, RowStatus, TruthValue > FROM SNMPv2-TC -- [RFC2579] > MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, > Integer32, Unsigned32, Counter32, mib-2 > FROM SNMPv2-SMI -- [RFC2578] > MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP > FROM SNMPv2-CONF -- [RFC2580] We MIB Doctors have been asking that people not put citation tags in MIB modules, since that has the effect of creating a dangling pointer when the MIB module is extracted for separate use. So, if you want to do this, please do it like so: TEXTUAL-CONVENTION, RowStatus, TruthValue FROM SNMPv2-TC -- RFC 2579 > 5. isisManAreaAddrExistState > > isisManAreaAddrExistState OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The state of the isisManAreaAddrEntry. If the > isisSysAdminState for this Intermediate System is 'on', and > an attempt is made to set this object to the value 'destroy' > or 'notInService' when this is the only > isisManAreaAddrEntry in state 'active' for this > Intermediate System should return inconsistentValue. > > A row entry cannot be modified when the value of this > object is 'active'." > ::= { isisManAreaAddrEntry 2 } > > Since the only objects are the index and the row status it may be > superfluous to say that the row entry cannot be modified. It also does not hurt to have the text there, and having it there will make MIB module maintenance easier if columns are added in the future. > 9. isisCircLastUpTime > > isisCircLastUpTime OBJECT-TYPE > SYNTAX Unsigned32 > UNITS "Seconds since startup when this circuit was last 'on'" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "If the circuit is enabled, the number of seconds > since system startup when isisCircAdminState most > recently entered the state 'on', or 0 if the > circuit has never been 'on'." > ::= { isisCircEntry 13 } > > Wouldn't we usually use SYNTAX TimeStamp from RFC2579? That would probably be a good idea. If you do that, adjust the DESCRIPTION clause and get rif of the UNITS clause (the units of TimeStamp are 1/100ths of a second). > 10. Counters > > Don't we need some description of the discontinuity behavior > of the counters? That is needed only if discontinuities can occur at times other than a management subsystem re-initialization. For counters that are tied to interfaces (i.e., where ifIndex is one of the row indices) ifCounterDiscontinuityTime is sometimes used (see RFCs 2863 and 3289). //cmh _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed May 25 15:54:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1xi-0003kY-Vo; Wed, 25 May 2005 15:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1xf-0003jw-O0; Wed, 25 May 2005 15:54:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16336; Wed, 25 May 2005 15:54:38 -0400 (EDT) Message-Id: <200505251954.PAA16336@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 25 May 2005 15:54:37 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-link-attr-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 : Definition of an IS-IS Link Attribute sub-TLV Author(s) : J. Vasseur, S. Previdi Filename : draft-ietf-isis-link-attr-01.txt Pages : 5 Date : 2005-5-25 This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-link-attr-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-link-attr-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-link-attr-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-5-25160201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-link-attr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-link-attr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-25160201.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 Wed May 25 15:54:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1xx-0003m0-FP; Wed, 25 May 2005 15:54:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1xu-0003kx-KZ; Wed, 25 May 2005 15:54:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16357; Wed, 25 May 2005 15:54:52 -0400 (EDT) Message-Id: <200505251954.PAA16357@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 25 May 2005 15:54:52 -0400 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-caps-03.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --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-03.txt Pages : 8 Date : 2005-5-25 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-03.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-03.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-03.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-5-25160208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-caps-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-caps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-25160208.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 May 27 06:03:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbbh4-0004KY-I4; Fri, 27 May 2005 06:03:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbbh3-0004KT-AB for isis-wg@megatron.ietf.org; Fri, 27 May 2005 06:03:53 -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 GAA26153 for ; Fri, 27 May 2005 06:03:51 -0400 (EDT) Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dbbzm-0006jh-B4 for isis-wg@ietf.org; Fri, 27 May 2005 06:23:17 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH500MP67YAVK@tid.hi.inet> for isis-wg@ietf.org; Fri, 27 May 2005 12:03:47 +0200 (MEST) Received: from tid.es ([172.19.16.77]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IH50006K7YA3W@tid.hi.inet> for isis-wg@ietf.org; Fri, 27 May 2005 12:03:46 +0200 (MEST) Date: Fri, 27 May 2005 12:04:45 +0200 From: Alberto Rubio To: isis-wg@ietf.org Message-id: <4296F0BD.4090306@tid.es> MIME-version: 1.0 X-Accept-Language: es-es User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; es-ES; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:5.60136 C:4 M:0 S:11 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.7 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Isis-wg] correct parent branch of isisMIB X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0134649753==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============0134649753== Content-type: multipart/alternative; boundary="Boundary_(ID_bA5Kb6QCoZm5anyv1tSg4w)" --Boundary_(ID_bA5Kb6QCoZm5anyv1tSg4w) Content-type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7BIT Hi, I have a question on the MIB module: What's the correct parent branch of isisMIB? According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt isisMIB MODULE-IDENTITY .... ::= { mib-2 XXX } -- RFC Editor - please replace with proper IANA Value However according to IANA http://www.iana.org/assignments/smi-numbers Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.) 37 ISIS-MIB Integrated ISIS protocol MIB Thanks, Alberto --Boundary_(ID_bA5Kb6QCoZm5anyv1tSg4w) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi,

I have a question on the MIB module:

What's the correct parent branch of isisMIB?

According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt

    isisMIB MODULE-IDENTITY
        ....
    ::= { mib-2 XXX }

-- RFC Editor - please replace with proper IANA Value

However according to IANA
 http://www.iana.org/assignments/smi-numbers

Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.)
37   ISIS-MIB      Integrated ISIS protocol MIB

Thanks,
Alberto
--Boundary_(ID_bA5Kb6QCoZm5anyv1tSg4w)-- --===============0134649753== 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 --===============0134649753==-- From isis-wg-bounces@ietf.org Fri May 27 09:06:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeXj-0001Ov-LR; Fri, 27 May 2005 09:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbeXi-0001Oc-DB for isis-wg@megatron.ietf.org; Fri, 27 May 2005 09:06:26 -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 JAA08528 for ; Fri, 27 May 2005 09:06:25 -0400 (EDT) Received: from anthrax.middlebury.edu ([140.233.2.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbeqU-0002Pn-VK for isis-wg@ietf.org; Fri, 27 May 2005 09:25:52 -0400 Received: from arcticcat.middlebury.edu [140.233.2.8] by anthrax.middlebury.edu with XWall v3.32 ; Fri, 27 May 2005 09:06:13 -0400 Received: from GRASSHOPPER.middlebury.edu ([140.233.2.6]) by arcticcat.middlebury.edu with Microsoft SMTPSVC(5.0.2195.6713); Fri, 27 May 2005 09:06:12 -0400 Received: GRASSHOPPER 140.233.2.6 from 140.233.20.200 140.233.20.200 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 27 May 2005 09:06:13 -0400 Subject: Re: [Isis-wg] correct parent branch of isisMIB From: "Parker, Jeff" To: Alberto Rubio , Message-ID: In-Reply-To: <4296F0BD.4090306@tid.es> Mime-version: 1.0 X-OriginalArrivalTime: 27 May 2005 13:06:12.0785 (UTC) FILETIME=[DB9DC210:01C562BC] X-Spam-Score: 1.9 (+) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1793499619==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1793499619== Content-type: multipart/alternative; boundary="B_3200029573_24877" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3200029573_24877 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The MIB is not yet an official document. When it becomes one, it will be given an official ID. I was encouraged =ADnot- to use the experimental ID, for excellent reasons that I have long since forgotten. - jeff parker - mib scribe On 5/27/05 6:04 AM, "Alberto Rubio" wrote: > Hi, >=20 > I have a question on the MIB module: >=20 > What's the correct parent branch of isisMIB? >=20 > According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-2= 0.txt >=20 > isisMIB MODULE-IDENTITY > .... > ::=3D { mib-2 XXX } >=20 > -- RFC Editor - please replace with proper IANA Value >=20 > However according to IANA > http://www.iana.org/assignments/smi-numbers >=20 > Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.) > 37 ISIS-MIB Integrated ISIS protocol MIB >=20 > Thanks, > Alberto >=20 >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg --B_3200029573_24877 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Isis-wg] correct parent branch of isisMIB The M= IB is not yet an official document.  When it becomes one, it will be gi= ven an official ID.

I was encouraged –not- to use the experimental ID, for excellent reas= ons that I have long since forgotten.

- jeff parker
- mib scribe


On 5/27/05 6:04 AM, "Alberto Rubio" <arh39@tid.es> wrote:
Hi,

I have a question on the MIB module:

What's the correct parent branch of isisMIB?

According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.= txt

    isisMIB MODULE-IDENTITY
        ....
    ::=3D { mib-2 XXX }

-- RFC Editor - please replace with proper IANA Value

However according to IANA
 http://www.iana.= org/assignments/smi-numbers

Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.)
37   ISIS-MIB      Integrated ISI= S protocol MIB

Thanks,
Alberto

____________________= ___________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

 --B_3200029573_24877-- --===============1793499619== 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 --===============1793499619==-- From isis-wg-bounces@ietf.org Sat May 28 20:38:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcBp4-0007h2-0r; Sat, 28 May 2005 20:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcBp1-0007gx-Vn for isis-wg@megatron.ietf.org; Sat, 28 May 2005 20:38:32 -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 UAA15249 for ; Sat, 28 May 2005 20:38:29 -0400 (EDT) From: jcucchiara@mindspring.com Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcC88-0003KV-Js for isis-wg@ietf.org; Sat, 28 May 2005 20:58:16 -0400 Received: from h-67-101-123-156.cmbrmaor.dynamic.covad.net ([67.101.123.156] helo=jluciani-laptop) by pop06.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1DcBok-0002pZ-00; Sat, 28 May 2005 20:38:15 -0400 Message-Id: <3.0.1.32.20050528155041.0149ba78@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 28 May 2005 15:50:41 -0400 To: Christian Hopps , ISIS WG Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB. In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 1.2 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 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 Most of my comments deal with the following 2 objects: isisSysType OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2), level1L2IS (3) } MAX-ACCESS read-write STATUS current DESCRIPTION "At which levels is the Intermediate System running? This object may not be modified when the isisSysAdminState variable is in state 'on' for this Intermediate System." REFERENCE "{ISIS.aoi iSType (2)}" DEFVAL { level1L2IS } ::= { isisSysObject 2 } isisCircLevel OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), level1L2(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates which type of packets will be sent and accepted on this circuit. The values used will be modified by the settings of isisSysType. This object follows the replaceOnlyWhileDisabled behavior." DEFVAL { level1L2 } ::= { isisCircEntry 8 } 1a) Why can't the TC IsisAdjLevel be used for isisSysType and isisCircLevel? IsisAdjLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies one or more levels." SYNTAX INTEGER { level1(1), level2(2), level1and2(3) } If this TC can be used (and I think that it can/should) then please rename this to something more generic such as IsisLevelType 1b) The naming is inconsistent for the following related objects isisSysType and isisCircLevel Since these are related, could they be renamed so as to indicate they are related, e.g. isisSysType, isisCircType or isisSysLevel, isisCircLevel, or isisSysLevelType, isisCircLevelType? 1c) Could the description of isisCircLevel be clarified such that an implementor understands what the agent is supposed to return for an error in the event that isisSysType has a value of level1(1) and an operator attempts to set isisCircLevel to level2(2) or level1and2(3)? 2) Several Entry descriptions contain a phrase similar to "Configured values will survive an agent reboot", I don't understand why this would be dictated by a MIB? In other words, why isn't a StorageType object present in these tables? 3) The following object's isisCircIfSubSelector OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "A specifier for the part of the interface ifIndex to which this circuit corresponds, such as a DLCI or VPI/VCI. This object cannot be modified after creation. Holds 0 if not used." DEFVAL { 0 } ::= { isisCircEntry 3 } DESCRIPTION is confusing. In the case of ATM, does this value contain an ifIndex or zero, and if so, what is the ifType that corresponds to this ifIndex? Or, could it contain an actual VPI/VCI in which case 0 could be a valid VPI/VCI? Furthermore, the Abstract states: "This document describes a management information base for the IS-IS Routing protocol when it is used to construct routing tables for IP networks." so why is there a need to have this object at all? Thanks, -Joan At 08:43 AM 5/18/05 -0700, Christian Hopps wrote: >As the MIB doctor review is complete the IS-IS MIB is now in WG last >call. Please recall that we are only looking for issues with the >current version of the MIB as we need to get this document published. >It was pointed out that we could add support for graceful restart; >however, changes such as this will have to be addressed in a later >revision of the MIB. > >Please post any comments by June 1st. > >Chris and Dave. > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue May 31 13:16:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdALh-0002PL-2a; Tue, 31 May 2005 13:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdALg-0002P9-1S for isis-wg@megatron.ietf.org; Tue, 31 May 2005 13:16:16 -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 NAA26381 for ; Tue, 31 May 2005 13:16:12 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAfK-0006yc-8x for isis-wg@ietf.org; Tue, 31 May 2005 13:36:34 -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 j4VHG5Ig004172 for ; Tue, 31 May 2005 10:16:05 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j4VHG2iU001838; Tue, 31 May 2005 10:16:02 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j4VHG0aC001825; Tue, 31 May 2005 10:16:02 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 31 May 2005 10:16:00 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG Subject: Re: [Isis-wg] correct parent branch of isisMIB In-Reply-To: <4296F0BD.4090306@tid.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 5/27/05 6:04 AM, "Alberto Rubio" wrote: Alberto> I have a question on the MIB module: Alberto> Alberto> What's the correct parent branch of isisMIB? Alberto> Alberto> According to http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt Alberto> Alberto> isisMIB MODULE-IDENTITY Alberto> .... Alberto> ::= { mib-2 XXX } Alberto> Alberto> -- RFC Editor - please replace with proper IANA Value Alberto> Alberto> However according to IANA Alberto> http://www.iana.org/assignments/smi-numbers Alberto> Alberto> Prefix: iso.org.dod.internet.experimental (1.3.6.1.3.) Alberto> 37 ISIS-MIB Integrated ISIS protocol MIB >>>>> On Fri, 27 May 2005, Parker, Jeff replied: Jeff> The MIB is not yet an official document. When it becomes one, Jeff> it will be given an official ID. Jeff> Jeff> I was encouraged -not- to use the experimental ID, for excellent Jeff> reasons that I have long since forgotten. This is done to comply with the policy set forth in RFC 2578 Section 4, which says: The mgmt(2) subtree is used to identify "standard" objects. The experimental(3) subtree is used to identify objects being designed by working groups of the IETF. If an information module produced by a working group becomes a "standard" information module, then at the very beginning of its entry onto the Internet standards track, the objects are moved under the mgmt(2) subtree. Since this MIB module is being moved to the standards track, the objects need to be registered under the mgmt subtree. The traditional place is under mib-2, which is { mgmt 1 }. The reason for this split is that we enforce rather strict standards on backward compatibility once an object is defined in a published RFC. We can't do that (and don't want to do that) for stuff that is still under development (i.e., still in the Internet-Draft stage). OIDs under the experimental subtree can be assigned so that people can experiment with pre-standard implementations. It would be OK to continue to use the { experimental 37 } node for pre-standard implementations of the ISIS-MIB provided that they were strictly experimental and were not targeted for deployment in an operational environment. See also draft-ietf-ops-mib-review-guidelines-04.txt Section 4.3. Hope this helps. Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue May 31 13:26:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAVQ-0003RT-PP; Tue, 31 May 2005 13:26:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdAVP-0003RN-Dc for isis-wg@megatron.ietf.org; Tue, 31 May 2005 13:26:19 -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 NAA27327 for ; Tue, 31 May 2005 13:26:16 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdAp3-0007Ek-LJ for isis-wg@ietf.org; Tue, 31 May 2005 13:46:38 -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 j4VHQBIg006251; Tue, 31 May 2005 10:26:11 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j4VHQ6EC004645; Tue, 31 May 2005 10:26:06 -0700 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j4VHQ3oT004625; Tue, 31 May 2005 10:26:03 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Tue, 31 May 2005 10:26:03 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ISIS WG Subject: Re: [Isis-wg] WG Last Call on IS-IS MIB. In-Reply-To: <3.0.1.32.20050528155041.0149ba78@pop.mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Wijnen, Bert \(Bert\)" 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 Sat, 28 May 2005 jcucchiara@mindspring.com wrote: > 2) Several Entry descriptions contain a phrase similar to > "Configured values will survive an agent reboot", I don't understand > why this would be dictated by a MIB? In other words, why isn't > a StorageType object present in these tables? Having a StorageType column is one option, but it is not the only option. According to draft-ietf-ops-mib-review-guidelines-04.txt Section 4.6.4, - If dynamic row creation and/or deletion by management applications is supported, then: [ ... ] - There either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart. The language in the DESCRIPTION clause is equivalent to having an a StorageType column that can assume only the value nonVolatile(3). Mike Heard _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Jun 02 09: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 1Ddq7s-0004QU-Vz; Thu, 02 Jun 2005 09: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 1DbDao-0005hQ-JD for isis-wg@megatron.ietf.org; Thu, 26 May 2005 04:19: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 EAA10384 for ; Thu, 26 May 2005 04:19:48 -0400 (EDT) Received: from [62.93.168.242] (helo=tcpsi.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbDtL-0002cS-8W for isis-wg@ietf.org; Thu, 26 May 2005 04:39:01 -0400 Received: from larry by tcpsi.com (Servidor de Correo TCP Sistemas e Ingenieria) with SMTP id CNG74113; Thu, 26 May 2005 10:21:44 +0200 Message-ID: <001801c561cb$f85e6b80$551013ac@tcpsi.es> From: =?iso-8859-1?Q?Enrique_Gonz=E1lez?= To: Date: Thu, 26 May 2005 10:21:51 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.6 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa X-Mailman-Approved-At: Thu, 02 Jun 2005 09:52:47 -0400 Cc: arubio@tcpsi.es Subject: [Isis-wg] Question of different branch in protocol IS-IS 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: , Content-Type: multipart/mixed; boundary="===============1468728625==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1468728625== Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0014_01C561DC.BB6672C0" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C561DC.BB6672C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01C561DC.BB68E3C0" ------=_NextPart_001_0015_01C561DC.BB68E3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello. My name is Enrique Gonzalez. I am a Spanish company's engineer of = systems management network that we are accomplishing a project of = management service in and we need to monitoring a part of environment = of network MPLS. For it, we need to know the OID needed to know the information = correlated to the protocol IS-IS that it seems not to be very = standardized, because in the IETF's RFC = http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt) the = iso.org.dod.internet.mgmt.mib-2 appears in the branch mib-2 ( = 1.3.6.1.2.1 )=20 However, in the IANA (http://www.iana.org/assignments/smi-numbers) it = hangs up on iso.org.dod.internet.experimental ( 1.3.6.1.3 )=20 It is an element that hangs up of the experimental branch such and how = it can be appreciated from that page. I would like could have clarified what information is valid and why this = difference. Thank you very much. Greetings. -------------------------------------------------------------------------= ------- ------=_NextPart_001_0015_01C561DC.BB68E3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Hello.

My name is Enrique Gonzalez. I = am a Spanish=20 company's engineer of systems  management  network that we = are =20 accomplishing a project of management service  in and we need = to =20 monitoring a part of environment of network MPLS.

For it, we need = to know=20 the OID needed to know the information correlated to the protocol=20 IS-IS  that it seems not to be very standardized, because in the = IETF's RFC=20 http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-20.txt) = the iso.org.dod.internet.mgmt.mib-2 appears in the branch mib-2 ( = 1.3.6.1.2.1 )=20
However, in the IANA (http://www.iana.org/assignments/smi-numbers) = it hangs=20 up on iso.org.dod.internet.experimental ( 1.3.6.1.3 )
It is an = element that=20 hangs up of the experimental branch such and how it can be appreciated = from that=20 page.
I would like could have clarified what information is valid and = why=20 this difference.

Thank you very = much.

Greetings.
 
 
3D""
 
------=_NextPart_001_0015_01C561DC.BB68E3C0-- ------=_NextPart_000_0014_01C561DC.BB6672C0 Content-Type: image/gif; name="TarjetaTCP_Quique.gif" Content-Transfer-Encoding: base64 Content-ID: <001301c561cb$f7db58d0$551013ac@tcpsi.es> Content-Transfer-Encoding: base64 R0lGODlhHAGPAPcAAAAAAP/////9/v/8//39/93h6gAygUBoonGOuuTq8wA7hzFgnVh+sGKEtG+M tHCOtRBJj0BupT5ml013q22Ot26PuG2NtG2Ns2+PtW6OtLbG2bnH2dzl8Nvj7e7y9wNDixRPkxpW lyFamidgnTZqpDpupkFzqUZ3rFKAsVqFtGOKt2ePu2uOtXKXv22Qtm6Qtm6QtW2PtHudw3GPsoKi xoqoypOwz5GuzZq10pKrxp60zK7D2rTH3bvN4cjX59Hd6s7Z5dXg7A1NkStkoDFooj1xp0N2qzxo lT1plj5qlz5plkh5rT5plD5pkz9qlE59r1aEs12JtmGMuGWOuWqSvG6VvmyQtGuPs26Stnabwm2P sm2OsW+Qs26Psm6Pr36hxXGQr4SlyIipyoyry5az0J+51KW91p2zyarB2aG1yrHG3LXJ3bjL37bI 27/Q4rbG1sPT5M3b6dnj7d/o8eXs8+rw9vH1+fj6/DlrmjxrlztqlT1qlD5rlT1pkz1qkz5qkT9r kj9pkWuRtWyQsm2QsG+RsZ60ydnk7t3n8OHq8jtqkzxslDxpkD1qkWyPrZy1yp60x7bI18/a4+Pr 8ufu9DltlT1skT5rj2yPq9rj6vX4+s7Z39rl6/v9/vr8/fn7/Gx/hPn///v///7///3//vv//P7/ /vv/+v3//P3/+v3++f//+////f39+////p6bhv/++v79+bavm9THqf7357CSV/vTf/79+/zDXP/Q fv/Sgf/ShPzRgtOubf/Th/7nv/6xMP+yM/64SP+/W/7AW//CXf7AXf2/XP/BXvzBXfu/Xf3CXvvB XvzBX//EZf7Ibv/Pfv/QgP/Qgf/Rgv/Qg/7Ogv/RhP/Shf/Shv/Wlf7grf7px//v1v++Xf+/Xf+/ Xv/AXv2+X/+/Yf/79f/9/P7+/v39/f///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAOcALAAAAAAcAY8A AAj/AAOwCkAqwChSrFgZ8pKECR89fiJKnEixosWLGDNq3Mixo8ePIEOKHEmy5EQneiAZDEAgYQAB A0cFEBhrlCQ+mB6JYiXg5cyfQIMKHUq0qNGjSJMqXcq0qdOnUKNKBUpKEkMdklAJJbCqnExMe4Cs SkVuVDlWoqaqXcu2rdu3cOMmJVcOFZAzeSQFHVgugCRHXmSe3TnKXCm5iBMrXsy48VGvrLQCYQJk JitSpcgFANJEZQCv5AYO7Om4tOnTqFMLXcWqXE9UNyX1lUlqFB8gXgXOXCUqt+rfwIMLjzoKleZR o1hJ8iOwdQBMkFgVF3gQlfRymodr385duFavozSj/zLkCDIrPqzIEaA+cKbM9t3jy5+P+KxW56y8 SBqoA5JXAWbRJyBQWum2FwHZDfCeZTutFAAqohRokFYyUfeZTwMV2NeAjf0VwCp7EFQKhBVyOF+E rZ111kx1PUhdKzsNRAprPY1GGimkYVjjLdL59JlLJio2kCOSAOHITFqRkl2Q881WkECoqCjYk3yl 91mFEd5inVY9iUIKAb3NJIBXqFj3GULwMfkWWoa0+You0ETDiy7VRGPnnXjmqeeefPbpp53STLML Nr5gcw2hhu6iqDXTSPPno5D6CU0uv2gVWl99mQOlQGm5eOGHrJFCyk6Y8iWQOat8qZlLZf5Uoppv lf/ziCFMkHbZirByN9Av1EDDS5y52ElNLtBAMyw1v7jXkzkBzgYgK+vdB0sAsAjQ039AIadprnH9 1cSDBQLIra4EschKKKusp4EGOWgQyRuy1FKLLtEEm0uv9EZDTb3rIdfTkwQg5F4qM5X15LhuCcCH E8lJ9yrCwQ1kTkIbjklOlKywxm4XWMzwQgYxUDBKJutG0oYcBsV5Z5xx6pIsTDxl7JqnELPVRBIT zwRLbTUHh0qOZiIHlLXJrSLHBjm8wEUO5eQAgxVcaBEDFxWwwMUD7ZocSQcB/FJnNLZUY8svApCy Yc9S9cUKRE1h+qlQmJ5ds9ws/kR3U++ZBUsokWT/EkAGgGfAhQswZNDFCxU8gAEFGWCgASR+OLEH JjqcAcks9dpJaV8HD7RexhLiuIq/5b50EE+pJFe6gHsw1xQAsMN+FABTxU67VLffnpTuAfC+e9vI sZJKKOJ2oEEMVmxBwQwxwMBFDBkUAnUHXuixBx9NKMFHH0jssUceTejwirzVTJrsxGq3V1BMZxGQ nFYTw1TcKgKIMibrrjPlO2K877+U7v4jSv+WUo4AGuVi5jjLtAjGimkFYF1cYAEMXtC8B8AABgHQ Ax82uIdF6KEJfUhCE5ighD0w4oTlgF68Mocsr6zobJpxzUBWgQqZLOszpXhYd1rnFAO+xYdQASJQ /waImITcYhXM6kmFRLMecnSgDTnoAgYwEIMccMZ6jeADE77nhyZYQhF+eMgRzqAGLsDABRi4AAsy sIF46SIXwYoGiwhQDnOIQjPro44AWiGQJcmHh68TCu1k17tBzsR2vftJ7gipSAEScpCLfOQjDylJ RiaykZRcZCEzqchK8m5DoanOKNL1knLQsEIIeSILHtfFJCiCD2DcoBMukQQ/LKIJTjjD8bqwRirG IAYsYMEMrJCBdtWiXtWA431IkYpnrac24cFfD2PXyUNe0pDWBOAlt3nNSWYzd0MMiiG1iclMUnOb 2NwfNrnJO1eYwjJnCVBMApCW+rnEVJJ4hCL6wP+HEm5wESF0wiuZoIcAOG8GGRhEBi4QtQtg4HmA IwQWAlAJLxgCCPqCY7KoozYJzQeQ+hNkI8GpzZIispzXHGk5AUhNSJ6Tm+w0Zzo7KTvbkdMo76mf dZCTHKBdaBV+OYMX9jDCDfoBENrrgxcyATguvKALMOjC82KwuAcArgJWdEITsugHi0riF/eCxn1g MiCQ/k+k2UyrWhMZQCKWFJM3HSdawwlXcVoTnTDNK97MJKYAHLGnorCJDpyQBCdUwiF8OEMbHvDL M6IRZFHVAsigp4Ez6AEQ2LPlH7SIiTNgVF/JSlN8zKoUdaqUraetKUpZelfUrhWv61wnXe/61pT/ rlW2iRllDWFROT9YTxI5aFwFfmkFF2TgYxmQYAQL0QFHNIEPRPXec2MpQou+ArQHswynBmCQ8MxT IEpSDGl3d9LaRlKTkRSkajkJ23MiMr2FtCQR40tbmsL3pEXsLg2lk88AQC+NgMMAY6kIgxi84AEs eMB5rucEyWkwjIoAhAaT8IeCYkAWuajGLyIkAK1EyWwvQQX9AtCKiok3f4wRItoi1p7wLAhHJMvB 1GaAAQp2wQXMq0AXrAiISjRBg60z6gYxywRAPOJ4Bc6BLIz1C6EFIGfuQw7BzMJXxIw3MSpesXAi Mx2McUUmo9BAG6yAASt0wQIV4ALINGCI6EJ3/w9O2Cz2iHqJRfhBl4PoAlUpYAUNzEKjqRNAS36W nsIE4BTcTcyVtczoplyGnrNp0WsI8h53SS0GM4AB9X7MhCYEgg95cIJv4dyHPNjSv2r+JQZm8ICr aWDJyHrbAM7m0bgsutG4NoqXEtIeAZBjVOVKS4pgUo5yFABpLxjFHgDxYzxs783eU8Qi9sAETMjh eQVWWuMOvIXCKbkXLktIQfrSlRM/5aVZbgsQ8Vva2XLLfQWxTkKSgxAkughj9BzF5x7hiCNgT4OB YDAuw+iHNBzPBRSAwQwS3oUHWEEQVnjBFjKAhQ3MohfQ0MV6BK3Dt9y6KDeda1x8OF+jmBZhtv8q pUHI8SygavdKXFLPKHoCCR00AQ/P1YPkkNCEDgIhB8TMgAWg90vAPWDAXLBAB3KAhXbVCRqitTWK 242UdJ/b5D3M9VtmNApIaKHnSNADQfeAChZgusDN64IWnneBomuBAqzAQAYKN4gcdMBO5UDIxS7k MNUZqCkfFyBaJcnelrKUteJ0ryX1Sl9KOv6+m9S6UhJSJptAAhMS9kIHAFe4uXte6DEgRONiIGao Bh1kCNDAsMCMClJ0QtCREUiOAD/10jJypuBUa+5TO9vY0tW9vCfpSHcv+aIYuq/uSYMk2iC4NRKX ghSU+wvKzAmnXYGCjIWBFiSbg15EAyZkbdH/WU7RcaQEfnb1pe1701/eubpUvr9vf31ry/ji/+Q7 AQgNs4rT4a68Ibgfo2ZShAFqJ3cZwAoDZgEvYAUFZkFR1XS9EGuHoW8X4kdLcX5Yh1e2VVeupYEr xXhuNRS553shZ39EkRw5pBvrsWvtEWODAAbCVDgxgDWZQHQY4AVaUAEMZQFyl3APQAizQC/F9nJP gYF2NX+6x3sdOFMfGHKIZ14pRX9W12jtcTauYS0xJBChwArbwgOLpYNTFAmRkEZUpQULOIPQI0EO BQNv4C770kd/xxRGmHjkdHuFx36Kp16VpIfodHvm5U31Z4LS8SQyVBxo8SCp0GIAQg6d8n8x/1AO MLAFWBADLhADkhVVgPMxL3ABWhAAN1ZMmVAN1FAWRVh7JniKcXEWkdEjBtEXNaJE90QdM9cbSAM4 zTNFjQNRXVABBOhfjQMy7aIvpYiKxMgkHRAJyAM9M8ACxvUAWmAFbYhQDTh3pIcsNfIkSyIaQDGH xdiNv4E+bfAGmPZLyBWOgnABwzUDLuAAZ5QBmPMLCQEg7zFuATIT3OiN+FgatHEhfcEuXiBBAeBU ZihgB2YFF+BtswANlGaInDN795iPEKkYMBFvCBFNAXCMASBZCfUCggA4WzB9UFNMvWIW+saFT7aN phiRKmka9HYL9vMeLlEhx2iJFoSGVAQykv8lB5TSEwNgHWFijym5kkK5GLGXfwIwOhWiOnRRDlzB A+J4QWpWZi/gAs2VkL8wKnlXIg85lFwpFZoSGvf2I2fRCgOhGduCCnLALi6gOA9wAQHABIoAhLlA VijZlXbZGC1hIH1xGBtSQ6FEaEp0CBqgBWyGPXnQB2cggT+xlXfZmIwhHREyLUBgCJYAS06gBLNQ DbYSEY7ZmduxileiGwJQOXqgCI6ALGWCBEHpmazpGDBZj9/BE7JyBrPQZHywmq2Zm/oYWI/GE58x hIypm8KpFn0hYt8xHXQpAHY2nMyJGivSYTMhKrrRBLjZnNYZFd9VQxHyI6YiJrV0neCZGBv/Egtm 43eWEZxC6TZ1E55TcTdCgZ5d6Z7s6RTyWZfhWZ/zSZ/mV5352Z9IgZ9A2Z/sxk4Dqm7681KvU6Dx VVO+Y1OtJXX5WXIlJxfpNqFZJ3KOt1qBiFJyyJ+taUAWChcVaqAiaFcSuqEP2qERKnjuVnjjdHjf ZF8uCn98GHkI2qIy2ngPmk6TRHg6ehR7oAf3EZ5tRYe7x6MpCkm35YExBXIbeHIlmqL2RXxsJXxH CKQh8iQC05z+A6Uy9aTmBFvDh25XOkQt1Vpe6qQIenLrd1s3ShTXsx4vsRN8xJxdiqENiqZiuqRp mldQmKRUh6FLuKclCKd+UEOHQQ4Ew6Xh/3SnvQemUrinHehuJKinOPqoUdqop+VahToUQfoMSCIQ AOqY8lemd6iBbdpNe7igRiqjMGqqDbp4OHpeqBqm5scEwFANNTRzo+qfjTaFqLEHioAMwKANMkEO LueryioVQQoO3wAM3GBK2bWs1CqHfIAMxgAOwcANo/Ez+qYirKmgVzeFa+qk7PWjM7p46CaruINf h2dJ3iMOxOANwiAM3ACdFGMds3eXISqoV5plJtVWR8qkJThfvhdImXqu7gZd3gAOyJAMwgCqACKn JBauF2quKGqpIDiwQjShkYqw/uql5YA98ooL4ECvz/AqANKrENmlPYpekKekjZenGqupkv+KsTD1 sTVKUrjFbmkKZ8eArd/wDckADNSQITKTrI0JpTLLhJqKWxtrhyLFsW+6o+7HpE34Wpias++5CM76 DcaADN5QDMGgDUwUh/yqh+vFqa66hFW7tRyosxzKtFj7pTZadXP7nsOaDCb7Dc3QDcTKDVRisbCq hG/ltOvGoQtaqYB6qXKruICIsSFKbUELDuCgDGL7DeAArStRp6Rqs4M6giqFuJnaqek3qJBbunVL qCD4gYobAK3jDcgwu5Y7u8hQr9zwEqOzd8mxLUPproBopazKhKlKU5eKpn4Yq8Angsk7t94kvMar oXYzE7cpu7TrsOAgDuAQsaIxcwkxMSn/WK2SB6xuEbu2W7vdQLTFELGfsymqIGjiW63Ve74Oiwy4 MAyaa7SH+Bmx8BJRF7/5ab7XiwzfgL/G8A3iUKwdJhqk0CpC6bMUSqOl27x0aLfRi6475AfWiwy1 Cw7FsAwcjAzdAK0EIC7It5Kmi7e/800Cq6dOmLdZK6XbIcAc7LDEgL7IUAzaGq2jdBnl5439in4r vLp3q7UJS7OoGx8jq8H0G8LOigzLoLm4azf72rK/Z6MUvKpI3Kmk27Et+rjcQcMdbLlkbLnNwL2e O3OL2iVAfMUcq4RRy8WQ+rYhuq7sqh1ijL1lTMYcHLEPojo7FZEheF49W7Oqe4RvLKVI/+y6r4vH TDzAe0zGw2C53OthJjyk3TjIjcuBG1qoDvq4i8zIMuzIGzzGkZwMzioOEVshryGdi1qMcQWpcOyo RCzLVmuqLtzIw5HHNRzJyCCvzbC51HAl5dApP1x8EPyqOgp5FazLynyjDhq1F/xHj1zDvbzH33DD DWsMwUANBNAKAJI6sfC/ACycvBzJZPwNmAsO+Jur2jIKfHQL5Qye54zOYeus4LAMlgutNXLM89ya 9YzOAg2t7xHIM7GotTacFfq2IYVrAS3Q6Lyt96Y68+a51qli8kWlEfnQEE3GIMzN3JAK+voa33Wd GD14XMnRHV27xlAMnNsc7ZEQr6x1dv8cs7Q6s+nahzyb0xmqvNUEKyq90ukrr9s6cyv7IOSsZZFq Urc8uhoqumzLp6/1p0wS1BC9DM1AwMYA0u9jnsicqozrgesXzbYlulRah6tVqmpi1RDdDH9Lu5wb M3Q5vv8qqQObVnT7eOu1xZysV+QbHGyNzpqrz/m8z9zgvfKIzJsa1rJ1uJs6yrbMtga7gUES2CvN x9sKlmD2Ewit1MnLzFXqSapqq3c82qza0zr902tdzaZ82RA9yduaIxQtHRZN145B1jiLipbt2g6L u2hiLUjtILkmrsPx1xCz27xNxv+sm8gdyZ4wBxBtgsbd1Kox3fhTynqc3JaLAzjQ0TP/QQl3ABSe kAg/YAZm4AMeMC40C7DHG0RdudtB4AY+YAM0MAZTEAJhEAc+4AY8gAgBYLkJ4AmUUAYRMAaeMBNu wABDQAIQ8AEhEAEy4ANHIQc0sAaJwAaaEACdIAeU8BvrHagZe1YpzdrZDdFjAAIQoAAG8AEsLgQg AAJCEAWTYLlqcAJVYAJCoAAi4AEe0AIiIAIrYAZlEAZZsAAKEAI74Anu+QlSgAJSkAU2QAmJUAdU QAYBQAc+oAl3UAdB0AkB0OUzEQSasB6JYAc/UQdukOHuTXgMGrkhGIVISNlavK5J6ofcstuIYAM1 8AUMIAIfYAI1MAZhcANyYLk0AAIK/wACI8DiJeABOHACZiAH5eABdGAQiVADIRACZHDgQmEHJgAH QTAGOFAGKkAFMc4GYdACNkAGUNACYhAGUHADdmADK0AFNhAHKJAF6Z0ALRAFVfADQWSld02p7FfW xs7JjNvYcFzVJH7Nlw0HIkACh/C1ZPwFCvABJ9ADPkACChAGOLACdTATc1ACXwAUbKAAJpDecGMG WQAHa/AFWTAFONACNCAFX1AGUnACUzAHUJACPpAFUPAFP3ADUIADTyAGiRAAWbAEaGAENUCxDR3V BfuoclXxqKXsXHu6/aPWq43dzr7SKKAAYhDJWcDiMkDGZfABOEAEUzATdGAEH2AGQP9BByGwBGYu FJoAB3RABSRAA2iAAmFgBl+wAmXQA2UwBWug8GoQAGEgAj3w5VHgBjIgBXJAAE/uAz7v5RdLvDCc yxb/9U3K16fr13fe7MmNBkIwAohQxp5ABh+gAFOgCWScCCmwA0OwAjNhAx8gAkEAFOVQBClAFHbw BKwOBbWOAlFgA2YgBjaA6lOw9FXABuZQA0UgA2xQBUuQBV9ABU8vBlHgAy1ABloPslxP3WIv1jC8 1FO97JVt9rxNBQqQBXvsASZgACTAAWXsAXCACCEABQHwCSFPBGqu4T1ABGVAFOVgBrEeB3BgBlXA /IkQB1Mg7zsg4WgQBJ+gBjtQBiv/UAU84AZRUAZmPgkyEAVZcAjuXezy57GMHMuoKtqo/czWrRrN PQncjgZ7zAEkYABhABDgBA4UCMVEuUNDFMgIEADRjhQibtyx46nhxYt1yjUcZSeAgIYe5gTo5OlT xXJ3AoxC9GmlBzdwNgY4pAnjTZw5dV4EsNPnT6BAewYlWtToUaN7/HhD1lQgMoJRo66BQCKqnRog QviQKnAOjjs4PpBIpCbLgg8ixpTzkQIO0ptsnvzQWQcFDrhwh+bl+3NvX8CB8ypl6hQc1K5RfyxR MCUqpRIKqHhKLLDOEwUkUkBQEILGoYZlFJRxuCPOxSBsPG60o0bORQI/6gSI8wVR/4A6bjw2tBOH h4cAP9TMFlzc+HHkyZMubYoYcWWBZT58GBPVhxAQbKTW8VBOoA8RH4SEQFFm5EUzIciUKSFChAw7 ZYiQgALFByUpS8p7IpPCxBM5fIAiwCdMQIEHO1IwIosw5FiDCCJMKAIN5Sq08EIMiyKsuaegG2gN ED7oYSA43MBBgRImISgOGqLgSiAzxJMBEXC+AQcjM0SwgYQQ3GAAhBZIKIOSGoTgIQwq5EAjhDGq ICKOEyYgIwQ0jIiCgylEWCOEKtxYYooRvqBkDAW+yPBMNNNMbkPDnoNOug/QEAiHIcZQQwEi6hAI DhU+gMAGgtBQIAWpGhIgxx1XCP8ADRFGiKKTAOhA4QYUikABhRCogCKLAIK0QQQ6T4jCCBHKGKGM Q54gYgiPPCiBUzVjlXXWoNh0zkOB4hjBAMf6/EITD0j4QAwfEIDAABHMiMoMBWroqiFEI6Bh0RFI KGI2Dk6w4QkqyiBDih05baEEG0bAQYQV0PgChR2I4CGISkeYrQ4iZJiJVnzzldXWDnEFZ40DRGiP hoGCyIKE8Bb44gepzn2x0DIgGGOBFgKIuAUToNhhih7DiAIOGQ5AY4EKRllhgTFA2MEIdieYwI0h fvChhDBGOHAKA6bVd2eeMeT3MH8FmgQNM+SQKg4czOAgMTGMoKSyHhjYYYIaAlD/Y4Ee1CDCiBQm pOOJEUa4IZEJprUhBRxIiOOHCUAgAQ5KlggiiBSEW9WIA8i417i9e/Z71p/dDHpwgtTAQZPKNKFE kyDoCMCDuRtQoYwvRuAhAErYCCKAcn5I5HEOKPnBpgR6GKmTIDS5Yw6VODB9DkpGsbDvv2v3mbk2 Cdd9d5w8kcFAIsJwqSjabTf+eMD24OObZr75ZhhvdpceV1wGeoaVAFpZCftRQMIeefDDx5AVpcDx phlxapx+/cSe92aYYZzZhpVWRrEfFdm/F39//gErByQ/MEEc34DKN5ZhI/YlcCDfeF8ylCGMbQSA HPobhf76d0EMBoUUDWkCJnqB/4xjFIMZxhCcAqVXwIGIA4Lbs58AZJdBGMZQJ5DQQRpecQxxLEMc JTTh7qKXvmEgUBjZwN4qOCJDJCIRFTrQASwYIY5kdKMbhunh9L6RDG+IgxjDSMYwcBGMbAQgFAFg RfGSeEbxGcIQrHBEL7zRRQRWcXriaIZAvpE+xAxxHJ4ACRr9yD9U7KEhQACFAQmYPjlKrxg2IuDz 7KhCZ9CCjH+kJPjOYIiGlOMPvRDHFIvRHMRcEZSg9Eb02vcUHhKukeJQYTC4MYpVgCQVDbFgmsxY yQsKACSoMFQAgNCHhvDyl98IxwCjN8UaFeMwowSlMZzJoYGU0pRdcWY1qynNrv+Io3rNAIY2OEKK UZCij7gk54XK+L9yrCIVouCDJPq4ER0UkhiHWcYymFLHOHbFeXHMZz6lwkyANud5yDjgMIgBDGqU MQCkIAUreCmrcmwkouXE4ChgsZKNeMEQ+StHGWHhBUX0YpHG+GQ3ajTAfaZUmthUX0prtNKVJgam 0hSHMgXSjGV0AxjPCIA5AnCKh6ppI6yopfhuecbvgUQAjvBC915YjnD6Ug+96IaNkDEMZDQDqwAl SClR2RxjfDWgYwXlSbshjmEckBjC4On/JBiro/4touVAxTkpiopykEMUm9DDIHg5E6LKLqJAUAQo emEjVtYooHZ03gIb29hlMpOXcMlYJPTOBw5xeEMYwOAG516IJqI6tK6oCCpFxScAVkiCEIEAwkw2 yIpRkEMAM9HeGRShh0XoARBMyIMffPtb3zrBCU0gbnGFK1ziChe4y2WuH/jAB+YqYg9JcMIe8KAH P0igCXxghBMAEcDmhle842UuE/iwB/SilwnkZW973ctc6L5XvvOlb3394AQ+KAISnFvJRVgREAA7 ------=_NextPart_000_0014_01C561DC.BB6672C0-- --===============1468728625== 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 --===============1468728625==--