From isis-wg-admin@spider.juniper.net Tue Apr 3 07:54:47 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27481 for ; Tue, 3 Apr 2001 07:54:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA45009; Tue, 3 Apr 2001 05:30:04 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA44994 for ; Tue, 3 Apr 2001 05:29:22 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f33Blub27842 for ; Tue, 3 Apr 2001 04:47:56 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26818; Tue, 3 Apr 2001 07:50:50 -0400 (EDT) Message-Id: <200104031150.HAA26818@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 03 Apr 2001 07:50:50 -0400 --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 : Routing IPv6 with IS-IS Author(s) : C. Hopps Filename : draft-ietf-isis-ipv6-02.txt Pages : 6 Date : 02-Apr-01 This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol [0]. The method utilizes the same mechanisms described in RFC 1195 [1]. This is accomplished by adding 2 new TLVs and defining their use. These new TLVs are patterned from the ones described in 'IS-IS extensions for Traffic Engineering' [2]. Just as in RFC 1195 [1] with IPv4 and OSI, this method allows one to route both IPv4 and IPv6 using a single intra-domain routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt 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-ipv6-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-ipv6-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: <20010402124417.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124417.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 6 15:51:52 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18830 for ; Fri, 6 Apr 2001 15:51:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63845; Fri, 6 Apr 2001 13:22:04 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63833 for ; Fri, 6 Apr 2001 13:21:35 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f36Jdab73193 for ; Fri, 6 Apr 2001 12:39:36 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'isis-wg@juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] SNMP MIB Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 6 Apr 2001 15:42:39 -0400 I have put the ISIS mib through major changes, as outlined below I have sent the document to a dozen folks who had commented on the recent draft. I have also sent a copy to the reflector, but the file is too large to fit the profile. (Chalk up one win for traffic management.) If you have the interest and the time to review this, I would be happy to send a private copy. I will fold in any comments received and resubmit as version .04 next week. - jeff parker -- Changes this version -- -- Split off counting PDUs into a new table isisPacketCountTable -- responding to several suggestion on WG mail list -- Split off many level-specific circuit parameters into -- Circuit Level Table to allow more than two levels, -- responding to request from Tony Li -- Finished ripping out Authentication, as per request of R. Atkinson -- Striped mention of any metric other than default, as not used -- Compressed Rate Limiting variables -- Defined behavior when setting isisCircLevelHelloTimer at level 2 -- on a p2p link -- Deprecate isisCircIPEncaps OBJECT-TYPE -- -- Many changes suggested by Hans De Vleeschouwer, of Antwerp -- Use isisSysInstance to replace many local copies of same value -- Did the same for isisCircIndex -- Changed many MAX-ACCESS clauses of type read-write to read-create -- Limits on length of fields such as OSINSAddres and SystemID (now 0..6) -- While SystemIDs are all 6 if valid, there are places we need -- to represent a null SystemID, such as the isisCircLevelDesIS -- Fix mismatches of AdminState syntax and OperState descriptions -- Added text to describe isisISAdjNeighSysID for 3-way hello -- Removed IP Dest table, as this is covered by RFC 2096 -- -- Bugs: we are still stuck with L1 and L2 in -- isisSysMinL2LSPGenInt, isisSysOrigL2LSPBuffSize, -- isisSysLSPL2DbaseOloads, isisSysL2toL1Leaking _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Apr 13 07:03:29 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04676 for ; Fri, 13 Apr 2001 07:03:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA03099; Fri, 13 Apr 2001 04:40:04 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA03084 for ; Fri, 13 Apr 2001 04:39:43 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 13 Apr 2001 16:38:08 +0530 Received: from amudha (amudha.future.futsoft.com [192.168.5.7]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f3DJ3mL22240 for ; Sat, 14 Apr 2001 00:33:49 +0530 Reply-To: From: "Amudhavalli Narayanan" To: Message-Id: <000b01c0c409$d6c728e0$0705a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Test suites for ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 13 Apr 2001 16:36:49 +0530 Content-Transfer-Encoding: 7bit Hi, I would like to know if there are any publicly available ISIS test suites for protocol conformance Thanks, Amudha _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 17 10:09:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08086 for ; Tue, 17 Apr 2001 10:09:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA28062; Tue, 17 Apr 2001 07:47:04 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA28050 for ; Tue, 17 Apr 2001 07:46:51 -0700 (PDT) Received: from optic3.ipoptical.com ([64.242.9.180]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3HE33b83388 for ; Tue, 17 Apr 2001 07:03:03 -0700 (PDT) X-JNPR-Received-From: outside Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Apr 2001 10:02:59 -0400 Message-ID: From: Ben Abarbanel To: "'isis-wg@juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] IS-IS Traffic Engineering Extensions Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Apr 2001 10:02:58 -0400 Hi guys: I was looking at the draft "IS-IS extensions for Traffic Engineering" . I looked at TLV type 135 (The Extented IP Reachability TLV) section 4.0 it mentions that there would be additional support for subTLVs. I was wondering if there is definition for these SubTLVs. A few big vendors have implemented these subTLVs but I have not seen any public disclosure of them. Any help will be appreciated, Ben _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 17 10:52:19 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09138 for ; Tue, 17 Apr 2001 10:52:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA28327; Tue, 17 Apr 2001 08:29:04 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA28315 for ; Tue, 17 Apr 2001 08:28:27 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3HEicb85050 for ; Tue, 17 Apr 2001 07:44:38 -0700 (PDT) X-JNPR-Received-From: outside Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id IAA08527; Tue, 17 Apr 2001 08:47:37 -0600 Message-Id: <200104171447.IAA08527@tcb.net> X-Mailer: exmh version 2.0.3 To: Ben Abarbanel cc: "'isis-wg@juniper.net'" From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: [Isis-wg] IS-IS Traffic Engineering Extensions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 17 Apr 2001 08:47:37 -0600 Jeff P. proposed some text for the layout of the sub-TLVs a while back, though well after the -02 version of the draft was issued. Perhaps they'll find their way into the *next* version of the draft... Henk? I've included Jeff's message below, you can find it (and the rest of the thread) in the archives. Of course, this doesn't necessarily mean that what you've seen floating around conforms in any way. -danny > Hi guys: > I was looking at the draft "IS-IS extensions for Traffic Engineering" > . > > I looked at TLV type 135 (The Extented IP Reachability TLV) section 4.0 it > mentions that there would be additional support for subTLVs. I was > wondering if > there is definition for these SubTLVs. A few big vendors have implemented > these > subTLVs but I have not seen any public disclosure of them. > > Any help will be appreciated, [snip] From: Jeff Parker To: "'Tony Li'" Cc: "'henk@procket.com'" , "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Encoding of TE Sub-TLVs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 3 Jan 2001 09:59:36 -0500 Tony, Henk - This is offered to try to make the draft unambiguous to implement. You do refer to the values as "sub-TLV" throughout. However, there have been enough questions about the need for L in TLV on this and other lists recently that it would be good to remove doubt. This draft is being cited by a number of other drafts, so the effort to make it clear is worthwhile. In section in 4.0 The proposed extended IP reachability TLV contains a new data structure, consisting of: 4 bytes of metric information 1 byte of control information, consisting of 1 bit of up/down information 1 bit indicating the existence of sub-TLVs 6 bits of prefix length 0-4 bytes of IPv4 prefix 0-250 optional octets of sub-TVLs, if present consisting of 1 octet of length of sub-TLVs 0-249 octets of sub-TLVs you could replace the last line with 0-249 octets of sub-TLVs, consisting of a sequence of 1 octet of sub-type 1 octet of length 1-247 octets of value and the phrase in section 5.0 The proposed extended IS reachability TLV contains a new data structure, consisting of 7 octets of system Id and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs could be extended by 0-244 octets of sub-TLVs, consisting of a sequence of 1 octet of sub-type 1 octet of length 1-242 octets of value An example would help: either before section 4.0 or in a final section. For example, the sequence of 41 octets below 0x16 0x27 0xAAAA AAAA AAAA 00 0x00000A 0x06 0x03 0x04 0x01020304 0xBBBB BBBB BBBB 00 0x00000A 0x00 0xCCCC CCCC CCCC 00 0x00000A 0x00 is a TLV which describes three IS-IS neighbors. The first of these has an administrative color, defined by subtype 3, which consists of 4 octets of information. Someone could make the case that this is not prescriptive enough: it simply describes what should be done in a couple of cases. Such a person could argue for a special section describing the rules for a sub-TLV. - - jeff parker > Not doing a TLV is unthinkable, as that would completely > break the spirit > of the IS-IS design. > > If you would like to propose text, that's fine. It's > probably best to give > it to Henk as he has a bit more spare time than I do at present. > > | All of the examples given are fixed length, allowing an unwary > | implementor to imagine that they might be implemented as TV's > | rather than TLVs (that is, one is at risk of imagining that > | the length could be omitted). I can propose text to the list, > | but won't do so if this has been described someplace. > | > | - jeff parker > | - axiowave networks > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------- End of Forwarded Message _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 24 16:31:04 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14634 for ; Tue, 24 Apr 2001 16:31:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70636; Tue, 24 Apr 2001 14:07:13 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.jnpr.net [207.17.137.28]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62657 for ; Fri, 6 Apr 2001 08:08:40 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f36EQSb59729 for ; Fri, 6 Apr 2001 07:26:29 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BEA5.F7EB2D00" Subject: [Isis-wg] ISIS Mib Update Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 6 Apr 2001 10:29:20 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0BEA5.F7EB2D00 Content-Type: text/plain; charset="iso-8859-1" I have put the ISIS mib through major changes, as outlined below (these notes are also at the head of the file). I am sending this to the list for review before I submit as a draft. At present, my whimpy mib compiler cannot cope with a mib this large, so I will be dismembering it and feeding it into the compiler one part at a time. -- Changes this version -- -- Split off counting PDUs into a new table isisPacketCountTable -- responding to several suggestion on WG mail list -- Split off many level-specific circuit parameters into -- Circuit Level Table to allow more than two levels, -- responding to request from Tony Li -- Striped mention of any metric other than default -- -- Many changes suggested by Hans De Vleeschouwer, of Antwerp -- Use isisSysInstance to replace many local copies of same value -- Did the same for isisCircIndex -- Changed many MAX-ACCESS clauses of type read-write to read-create -- Limits on length of fields such as OSINSAddres and SystemID (now 0..6) -- While SystemIDs are all 6 if valid, there are places where -- we want to represent a null SystemID, such as the DIS -- Fix mismatches of AdminState syntax and OperState descriptions -- Added text to describe isisISAdjNeighSysID for 3-way hello -- Removed IP Dest table, as this is covered by RFC 2096 - jeff parker - axiowave networks - Those are my principles. If you don't like them, I have others. - Groucho Marx ------_=_NextPart_000_01C0BEA5.F7EB2D00 Content-Type: text/plain; name="isismib.txt" Content-Disposition: attachment; filename="isismib.txt" Content-Transfer-Encoding: quoted-printable -- Changes this version -- -- Split off counting PDUs into a new table isisPacketCountTable=20 -- responding to several suggestion on WG mail list -- Split off many level-specific circuit parameters into=20 -- Circuit Level Table to allow more than two levels, -- responding to request from Tony Li -- Striped mention of any metric other than default -- -- Many changes suggested by Hans De Vleeschouwer, of Antwerp -- Use isisSysInstance to replace many local copies of same value -- Did the same for isisCircIndex -- Changed many MAX-ACCESS clauses of type read-write to read-create -- Limits on length of fields such as OSINSAddres and SystemID (now = 0..6) -- While SystemIDs are all 6 if valid, there are places where -- we want to represent a null SystemID, such as the DIS=20 -- Fix mismatches of AdminState syntax and OperState descriptions -- Added text to describe isisISAdjNeighSysID for 3-way hello -- Removed IP Dest table, as this is covered by RFC 2096 --=09 -- This document defines an experimental portion of the MIB -- containing objects for managing the operation of the IS-IS -- protocol. The objects are mainly derived from the GDMO -- definitions in ISO 10589. -- -- The contents of the MIB are based on a draft revision of an IETF -- MIB dated September 1992 and titled "Integrated IS-IS Management -- Information Base". -- -- Portions of the orignal MIB, such as objects for ES-IS exchange, -- have not been included due to being inapplicable. Additionally, -- corrections and enhancements have been included. -- -- The names of some original items have been left in the text -- as comments, as an indication of missing items. Many of these -- are relevant to routing CLNS traffic -- ISIS-MIB DEFINITIONS ::=3D BEGIN IMPORTS TEXTUAL-CONVENTION, DisplayString, RowStatus, TruthValue, TestAndIncr, DateAndTime FROM SNMPv2-TC MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, Integer32, Counter32, IpAddress, experimental FROM SNMPv2-SMI; isis MODULE-IDENTITY LAST-UPDATED "200103121200Z" -- UTC date of the most recent = REVISION. ORGANIZATION "IETF IS-IS for IP Internets Working Group" CONTACT-INFO "Jeff Parker Axiowave Networks 100 Nickerson Rd. Marlborough, MA 01752 jparker@axiowave.com" DESCRIPTION "" ::=3D { experimental 37 } -- OBJECT IDENTIFIER definitions isisSystem OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 1 } isisCirc OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 2 } isisCircLevelValues OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 3 } isisCircPDUCounters OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 4 } isisISAdj OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 5 } isisReachAddr OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 6 } isisIPReachAddr OBJECT-IDENTITY STATUS current DESCRIPTION "" ::=3D { isis 7 } -- Type definitions OSINSAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "OSI Network Service Address, e.g. NSAP, Network Entity = Title" SYNTAX OCTET STRING (SIZE(1..20)) SNPAAddress ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A MAC Address or DTE Address or other SNPA Address." SYNTAX OCTET STRING (SIZE(0..20)) NSAPPrefix ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "NSAP Prefix. The first octet of the string is used to encode as an unsigned integer the length in bits of the subsequent prefix. This length must be a multiple of 4 bits and may range from 0..160. The second and subsequent octets are used to hold the prefix value. If the last 4 bits of the last octet are not part of the prefix then their value is undefined." SYNTAX OCTET STRING (SIZE(1..21)) SNPAPrefix ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "SNPA Prefix. The first octet of the string is used to encode as an unsigned integer the length in bits of the subsequent prefix. The second and subsequent octets are used to hold the prefix value. Bits in the last octet which are not part of the prefix have undefined value." SYNTAX OCTET STRING (SIZE(1..21)) SystemID ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "A system ID." SYNTAX OCTET STRING (SIZE(0..6)) AdminState ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Type used in enabling and disabling a row." SYNTAX INTEGER { off(1), on(2) } UpTime ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Number of seconds since the object has entered the state = 'up'. If the object is not up, the number of seconds since the circuit was up, or since the system started, if the = circuit has never been up." SYNTAX Integer32 LSPBuffSize ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Integer sub range for LSP size." SYNTAX Integer32 (512..1492) LevelState ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "states of the ISIS protocol." SYNTAX INTEGER { off (1), on (2), waiting (3) } SupportedProtocol ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Types of network protocol supported by Integrated ISIS. The values for ISO8473 and IP are those registered for these protocols in ISO TR9577." SYNTAX INTEGER { iso8473(129), ip(204), ipV6(205) } DefaultMetric ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Integer sub-range for default metric for single hop." SYNTAX Integer32 (1..63) MetricType ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Class of metric at Level 2." SYNTAX INTEGER { internal(1), external(2) } CircuitID ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "ID for a circuit." SYNTAX OCTET STRING (SIZE(2..9)) ISPriority ::=3D TEXTUAL-CONVENTION STATUS current DESCRIPTION "Integer sub-range for ISIS priority." SYNTAX Integer32 (1..127) -- Behaviour Definitions -- ResettingTimer behaviour definition -- "This object specifies the interval between certain events in -- the operation of the protocol state machine. If the value of -- this object is set to a new value while the protocol state -- machine is in operation, the implementation shall take the -- necessary steps to ensure that for any time interval which -- was in progress when the value of the corresponding object -- was changed, the next expiration of that interval takes place -- the specified time after the original start of that interval, -- or immediately, whichever is later. The precision with which -- this time shall be implemented shall be the same as that -- associated with the basic operation of the timer object." -- ReplaceOnlyWhileDisabled behaviour definition -- "This object may not be modified while the corresponding=20 -- table row's variable of type AdminState is in state on." -- OperationalState behaviour definition -- "This object controls the enabling and disabling of the -- corresponding table row. Setting this object to the value -- off has the effect of disabling the corresponding row. -- Setting this object to the value on has the effect of -- enabling the corresponding row. Setting the value of this -- object to the same value as its current value has no effect. -- If the table entry also contains an object controlling the -- row status then the object following the operationalState -- behaviour shall not be set to on when the object following -- the Row Status behaviour has value off. An attempt to do -- so is rejected." isisSysTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of instances of the Integrated IS-IS protocol existing on the system." ::=3D { isisSystem 1 } isisSysEntry OBJECT-TYPE SYNTAX IsisSysEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each row defines information specific to a single instance of the protocol existing on the system." REFERENCE "{ISIS.poi cLNSISISBasic-P (1)}" INDEX { isisSysInstance } ::=3D { isisSysTable 1 } IsisSysEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisSysVersion DisplayString, isisSysType INTEGER, isisSysID SystemID, isisSysMaxPathSplits Integer32, isisSysMaxLSPGenInt Integer32, isisSysOrigL1LSPBuffSize LSPBuffSize, isisSysMaxAreaAddresses Integer32, isisSysMinL1LSPGenInt =20 Integer32, isisSysMinL2LSPGenInt=20 Integer32, isisSysPollESHelloRate Integer32, isisSysWaitTime Integer32, isisSysAdminState AdminState, isisSysL1State LevelState, isisSysCorrLSPs Counter32, isisSysLSPL1DbaseOloads Counter32, isisSysManAddrDropFromAreas Counter32, isisSysAttmptToExMaxSeqNums Counter32, isisSysSeqNumSkips Counter32, isisSysOwnLSPPurges Counter32, isisSysIDFieldLenMismatches Counter32, isisSysMaxAreaAddrMismatches Counter32, isisSysOrigL2LSPBuffSize LSPBuffSize, isisSysL2State LevelState, isisSysLSPL2DbaseOloads Counter32, isisSysAuthFails Counter32, isisSysLSPIgnoreErrors TruthValue, isisSysLogAdjacencyChanges TruthValue, isisSysPartChanges Counter32, isisSysMaxAreaCheck TruthValue, isisSysNextCircIndex TestAndIncr, isisSysExistState RowStatus, isisSysL2toL1Leaking TruthValue, isisSysSetOverload INTEGER } isisSysInstance OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the Integrated IS-IS instance to which this row corresponds. This object follows the index behaviour." ::=3D { isisSysEntry 1 } isisSysVersion OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The version number of the IS-IS protocol to which this instance conforms. This value must be set by the implementation when the row is valid." REFERENCE "{ISIS.aoi version (1)}" ::=3D { isisSysEntry 2 } isisSysType OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2), level1l2IS (3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of this instance of the Integrated IS-IS protocol. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi iSType (2)}" ::=3D { isisSysEntry 3 } isisSysID OBJECT-TYPE SYNTAX SystemID MAX-ACCESS read-create STATUS current DESCRIPTION "The ID for this instance of the Integrated IS-IS protocol. This value is appended to each of the instance's area addresses to form the Network Entity Titles valid for this instance. The derivation of a value for this object is implementation-specific. Some implementations may assign values and not permit write, others may require the value to be set manually." REFERENCE "{ISIS.aoi systemId (119)}" ::=3D { isisSysEntry 4 } isisSysMaxPathSplits OBJECT-TYPE SYNTAX Integer32 (1..32) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum number of paths with equal routing metric value which it is permitted to split between. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi maximumPathSplits (3)}" DEFVAL { 2 } ::=3D { isisSysEntry 5 } isisSysMaxLSPGenInt OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum interval, in seconds, between generated LSPs by this instance. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi maximumLSPGenerationInterval (6)}" DEFVAL { 900 } ::=3D { isisSysEntry 6 } isisSysOrigL1LSPBuffSize OBJECT-TYPE SYNTAX LSPBuffSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum size of Level 1 LSPs and SNPs originated by this instance. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi originatingL1LSPBufferSize (9)}" DEFVAL { 1492 } ::=3D { isisSysEntry 7 } isisSysMaxAreaAddresses OBJECT-TYPE SYNTAX Integer32 (3..254) MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum number of area addresses to be permitted for the area in which this instance exists. Note that all Intermediate Systems in the same area must have the same value configured for this attribute if correct operation is to be assumed. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi maximumAreaAddresses (4)}" DEFVAL { 3 } ::=3D { isisSysEntry 8 } isisSysMinL1LSPGenInt OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in seconds, between successive generatio= n of L1 LSPs with the same LSPID by this instance. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi minimumLSPGenerationInterval (11)}" DEFVAL { 30 } ::=3D { isisSysEntry 9 } isisSysMinL2LSPGenInt OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in seconds, between successive = generation of L2 LSPs with the same LSPID by this instance. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi minimumLSPGenerationInterval (11)}" DEFVAL { 30 } ::=3D { isisSysEntry 10 } isisSysPollESHelloRate OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "The value, in seconds, to be used for the suggested ES configuration timer in ISH PDUs when soliciting the ES configuration." REFERENCE "{ISIS.aoi pollESHelloRate (13)}" DEFVAL { 50 } ::=3D { isisSysEntry 11 } isisSysWaitTime OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Number of seconds to delay in waiting state before entering on state. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi waitingTime (15)}" DEFVAL { 60 } ::=3D { isisSysEntry 12 } isisSysAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of this instance of the = Integrated IS-IS protocol. Setting this object to the value on when its current value is off enables operation of this instance of the Integrated IS-IS protocol." DEFVAL { off } ::=3D { isisSysEntry 13 } isisSysL1State OBJECT-TYPE SYNTAX LevelState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the Level 1 database." REFERENCE "{ISIS.aoi l1State (17)}" ::=3D { isisSysEntry 14 } isisSysCorrLSPs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of corrupted LSPs detected." REFERENCE "{ISIS.aoi corruptedLSPsDetected (19)}" ::=3D { isisSysEntry 15 } isisSysLSPL1DbaseOloads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the LSP L1 database has become overloaded." REFERENCE "{ISIS.aoi lSPL1DatabaseOverloads (20)}" ::=3D { isisSysEntry 16 } isisSysManAddrDropFromAreas OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a manual address has been dropped from the area." REFERENCE "{ISIS.aoi manualAddressesDroppedFromArea (21)}" ::=3D { isisSysEntry 17 } isisSysAttmptToExMaxSeqNums OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the IS has attempted to exceed the maximum sequence number." REFERENCE "{ISIS.aoi attemptsToExceedmaximumSequenceNumber (22)}" ::=3D { isisSysEntry 18 } isisSysSeqNumSkips OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a sequence number skip has occurred." REFERENCE "{ISIS.aoi sequenceNumberSkips (23)}" ::=3D { isisSysEntry 19 } isisSysOwnLSPPurges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a zero-aged copy of the system's own LSP is received from some other node." REFERENCE "{ISIS.aoi ownLSPPurges (24)}" ::=3D { isisSysEntry 20 } isisSysIDFieldLenMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a PDU is received with a different value for ID field length to that of the receiving system." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::=3D { isisSysEntry 21 } isisSysMaxAreaAddrMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times a PDU is received with a different value for MaximumAreaAddresses from that of the receiving system." REFERENCE "{ISIS.aoi MaximumAreaAddressesMismatches (118)}" ::=3D { isisSysEntry 22 } -- The following objects map those from the cLNSISISLevel2-P -- Package isisSysOrigL2LSPBuffSize OBJECT-TYPE SYNTAX LSPBuffSize MAX-ACCESS read-create STATUS current DESCRIPTION "The maximum size of Level 2 LSPs and SNPs originated by this system. This object follows the replaceOnlyWhileDisabled behaviour." REFERENCE "{ISIS.aoi originatingL2LSPBufferSize (26)}" DEFVAL { 1492 } ::=3D { isisSysEntry 23 } isisSysL2State OBJECT-TYPE SYNTAX LevelState MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the Level 2 database." REFERENCE "{ISIS.aoi l2State (28)}" ::=3D { isisSysEntry 24 } isisSysLSPL2DbaseOloads OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of times the Level 2 LSP database has become overloaded." REFERENCE "{ISIS.aoi lSPL2DatabaseOverloads (32)}" ::=3D { isisSysEntry 25 } isisSysAuthFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of authentication failures recognized by this instance of the protocol." ::=3D { isisSysEntry 26 } isisSysLSPIgnoreErrors OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, allow the router to ignore IS-IS link state = packets (LSPs) that are received with internal checksum errors = rather than purging the LSPs." DEFVAL { false } ::=3D { isisSysEntry 27 } isisSysLogAdjacencyChanges OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, causes IS-IS to generate a log message when an IS-IS adjacency changes state (up or down)." DEFVAL { false } ::=3D { isisSysEntry 28 } isisSysPartChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "partition changes" ::=3D { isisSysEntry 29 } isisSysMaxAreaCheck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "When on, enables checking of maximum area addresses per IS version of ISO10589." DEFVAL { true } ::=3D { isisSysEntry 30 } isisSysNextCircIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-only STATUS current DESCRIPTION "This object is used to assign values to isisCircIndex as described in 'Textual Conventions for SNMPv2'. The network manager reads this object, and then writes the value back as the isisCircIndex in a SET that creates=20 a new instance of isisCircEntry. If the SET=20 fails with the code 'inconsistentValue', then=20 the process must be repeated; If the SET succeeds,=20 then the object is incremented, and the new=20 instance is created according to the manager's=20 directions." ::=3D { isisSysEntry 31 } isisSysExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the ISIS router. Turning this off forces the router to forget all current state" DEFVAL { active } ::=3D { isisSysEntry 32 } isisSysL2toL1Leaking OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, allow the router to leak L2 routes into L1." DEFVAL { false } ::=3D { isisSysEntry 33 } isisSysSetOverload OBJECT-TYPE SYNTAX INTEGER { setL1Overload(1), setL2Overload(2), setL1L2Overload(3), overloadClear(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Administrativly set the overload bit for each level. The overload bit will continue to be set if the implementation runs out of memory, independent of this variable" DEFVAL {overloadClear } ::=3D { isisSysEntry 34 } -- The Level 1 Manual Area Address Table -- contains the set of area addresses manually configured -- for each instance of the Integrated IS-IS protocol. -- At least one row in which the value of -- isisManAreaAddrExistState -- is on must be present for each instance of the protocol -- when isisSysAdminState is also on for that instance. The -- maximum number of rows in this table for each instance of -- the protocol for which the object isisManAreaAddrExistState -- has the value on is the value of isisSysMaxAreaAddresses. -- An Attempt to create a new row such that the number of=20 -- rows with isisManAreaAddrExistState set to on for that=20 -- protocol instance exceeds isisSysMaxAreaAddresses -- is rejected." isisManAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of manual area addresses configured on this Intermediate System." REFERENCE "{ISIS.aoi manualAreaAddresses (10)}" ::=3D { isisSystem 2 } isisManAreaAddrEntry OBJECT-TYPE SYNTAX IsisManAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address manually configured on this system" INDEX { isisSysInstance, isisManAreaAddr } ::=3D { isisManAreaAddrTable 1 } IsisManAreaAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisManAreaAddr OSINSAddress, isisManAreaAddrExistState RowStatus } isisManAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "A manually configured area address for this system. This object follows the index behaviour. Note: an index for the entry {1, {49.0001} active} in this table would be the ordered pair (1, (0x03 0x49 0x00 0x01)), as the length of an Octet string is part of the OID." ::=3D { isisManAreaAddrEntry 1 } isisManAreaAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisManAreaAddrEntry. This object follows the Row Status behaviour. If an attempt is made to set this object to the value off when the corresponding isisManAreaAddrEntry is the only valid entry for this instance and when the corresponding ISIS instance has isisSysAdminState set to On then the attempt is rejected." DEFVAL { active } ::=3D { isisManAreaAddrEntry 2 } -- The Level 1 Area Address Table -- The Level 1 Area Address Table contains the -- union of the sets of area addresses reported in all Level 1 -- LSPs received by this Intermediate System. isisAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The union of the sets of area addresses reported in all Level 1 LSPs received by this instance of the protocol." REFERENCE "{ISIS.aoi areaAddresses (18)}" ::=3D { isisSystem 3 } isisAreaAddrEntry OBJECT-TYPE SYNTAX IsisAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one area address reported in a Level 1 LSP received by this instance of the protocol." INDEX { isisSysInstance, isisAreaAddr } ::=3D { isisAreaAddrTable 1 } IsisAreaAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisAreaAddr OSINSAddress } isisAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An area address reported in a Level 1 LSP received by this instance of the protocol." ::=3D { isisAreaAddrEntry 1 } -- The System Integrated Group -- The System Integrated Group is present if the system -- supports Integrated ISIS at Level 1. -- The System Protocol Supported Table -- The System Protocol Supported Table contains the manually -- configured set of protocols supported by each -- instance of the Integrated ISIS protocol. -- isisSysProtSuppTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSysProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the manually configured set of protocols supported by each instance of the Integrated ISIS protocol." ::=3D { isisSystem 4 } isisSysProtSuppEntry OBJECT-TYPE SYNTAX IsisSysProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by an instance of the Integrated ISIS protocol." INDEX { isisSysInstance, isisSysProtSuppProtocol } ::=3D { isisSysProtSuppTable 1 } IsisSysProtSuppEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisSysProtSuppProtocol SupportedProtocol, isisSysProtSuppExistState RowStatus } isisSysProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS not-accessible STATUS current DESCRIPTION "One supported protocol. This object follows the index behaviour." ::=3D { isisSysProtSuppEntry 1 } isisSysProtSuppExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of the isisSysProtSuppEntry. This object follows the RowStatus behavior." DEFVAL { active } ::=3D { isisSysProtSuppEntry 2 } -- The Summary Address Table -- The Summary Address Table contains the set of summary -- addresses manually configured for each instance of -- IP Integrated ISIS on the system. isisSummAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisSummAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of IP summary addresses to use in forming the contents of LSPs originated by this Intermediate System." ::=3D { isisSystem 5 } isisSummAddrEntry OBJECT-TYPE SYNTAX IsisSummAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP summary address." INDEX { isisSysInstance, isisSummAddress, isisSummAddrMask } ::=3D { isisSummAddrTable 1 } IsisSummAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisSummAddress IpAddress, isisSummAddrMask IpAddress, isisSummAddrExistState RowStatus, isisSummAddrAdminState INTEGER, isisSummAddrDefaultMetric DefaultMetric } isisSummAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP Address value for this summary address. This object follows the index behaviour." ::=3D { isisSummAddrEntry 1 } isisSummAddrMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The mask value for this summary address. This object follows the index behaviour." ::=3D { isisSummAddrEntry 2 } isisSummAddrExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this summary address. This object follows the row status behaviour." DEFVAL { active } ::=3D { isisSummAddrEntry 3 } isisSummAddrAdminState OBJECT-TYPE SYNTAX INTEGER { summaryl1(1), summaryl2(2), summaryl1l2(3), summaryOff(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of this entry. When the administrative state changes, if the new value would cause the contents of LSPs originated by the system to change, then those new LSPs must be generated and sent as soon as is permitted by the ISIS protocol." DEFVAL { summaryOff } ::=3D { isisSummAddrEntry 4 } isisSummAddrDefaultMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value to announce this summary address with in LSPs generated by this system." DEFVAL { 20 } ::=3D { isisSummAddrEntry 5 } -- The Circuit Group -- The Circuit Group is current -- The Circuit Table -- Each broadcast or point-to-point interface on the system -- corresponds to one entry in the Circuit table. There may be -- many X.25 DA circuit entries in the Circuit table for an -- X.25 interface. isisCircTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of circuits used by each instance of Integrated IS-IS on this system." ::=3D { isisCirc 1 } isisCircEntry OBJECT-TYPE SYNTAX IsisCircEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircEntry exists for each circuit used by Integrated IS-IS on this system." INDEX { isisSysInstance, isisCircIndex } ::=3D { isisCircTable 1 } IsisCircEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisCircIfIndex Integer32, isisCircIfSubIndex Integer32, isisCircLocalID Integer32, isisCircAdminState AdminState, isisCircExistState RowStatus, isisCircType INTEGER, isisCircExtDomain TruthValue, isisCircAdjChanges Counter32, isisCircInitFails Counter32, isisCircRejAdjs Counter32, isisCircOutCtrlPDUs Counter32, isisCircInCtrlPDUs Counter32, isisCircIDFieldLenMismatches Counter32, isisCircLevel INTEGER, isisCircMCAddr INTEGER, isisCircPtToPtCircID CircuitID, isisCircPassiveCircuit TruthValue, isisCircMeshGroupEnabled INTEGER, isisCircMeshGroup Integer32, isisCircSmallHellos AdminState, isisCircIPEncaps TruthValue, isisCircUpTime UpTime } isisCircIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of this circuit, unique within the instance of the protocol. This object follows the index behaviour. This is for SNMP Indexing purposes only and has no relation to any protocol value." ::=3D { isisCircEntry 2 } isisCircIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "The value of ifIndex for the interface to which this circuit corresponds. This object cannot be modified after creation" ::=3D { isisCircEntry 3 } isisCircIfSubIndex 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" ::=3D { isisCircEntry 4 } isisCircLocalID OBJECT-TYPE SYNTAX Integer32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "An identification that can be used in protocol packets to identify a circuit. Values of isisCircLocalID do=20 not need to be unique. They are only required to differ=20 on LANs where the Intermediate System is the Designated=20 Intermediate System." ::=3D { isisCircEntry 5 } isisCircAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the circuit. This=20 object follows the AdminState behaviour." DEFVAL { off } ::=3D { isisCircEntry 6 } isisCircExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this circuit. This object follows the Row Status behaviour." DEFVAL { active } ::=3D { isisCircEntry 7 } isisCircType OBJECT-TYPE SYNTAX INTEGER { broadcast(1), ptToPt(2), staticIn(3), staticOut(4), dA(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of the circuit. This object follows the replaceOnlyWhileDisabled behaviour. The type specified must be compatible with the type of the interface defined by the value of isisCircIfIndex." REFERENCE "{ISIS.aoi type (33)}" ::=3D { isisCircEntry 8 } isisCircExtDomain OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If true, suppress normal transmission of and interpretation of Intra-domain ISIS PDUs on this circuit." REFERENCE "{ISIS.aoi externalDomain (46)}" DEFVAL { false } ::=3D { isisCircEntry 9 } isisCircAdjChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an adjacency state change has occurred on this circuit." REFERENCE "{ISIS.aoi changesInAdjacencyState (40)}" ::=3D { isisCircEntry 14 } isisCircInitFails OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times initialization of this circuit has failed." REFERENCE "{ISIS.aoi initializationFailures (41)}" ::=3D { isisCircEntry 15 } isisCircRejAdjs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an adjacency has been rejected on this circuit." REFERENCE "{ISIS.aoi rejectedAdjacencies (42)}" ::=3D { isisCircEntry 16 } isisCircOutCtrlPDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS control PDUs sent on this circuit." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisCircEntry 17 } isisCircInCtrlPDUs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS control PDUs received on this circuit." REFERENCE "{ISIS.aoi controlPDUsReceived (44)}" ::=3D { isisCircEntry 18 } isisCircIDFieldLenMismatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times an IS-IS control PDU with an ID field length different to that for this system has been received." REFERENCE "{ISIS.aoi iDFieldLengthMismatches (25)}" ::=3D { isisCircEntry 19 } 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 behaviour." DEFVAL { level1l2 } ::=3D { isisCircEntry 20 } isisCircMCAddr OBJECT-TYPE SYNTAX INTEGER{ group (1), functional (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies which type of multicast address will be used for sending HELLO PDUs on this circuit." DEFVAL { group } ::=3D { isisCircEntry 21 } isisCircPtToPtCircID OBJECT-TYPE SYNTAX CircuitID MAX-ACCESS read-create STATUS current DESCRIPTION "The ID of the circuit allocated during initialization. If no value has been negotiated (either because the adjacency is to an End System, or because initialization has not yet successfully completed), this object has the value which would be proposed for this circuit (i.e. the concatenation of the local system ID and the one octet local Circuit ID for this circuit." REFERENCE "{ISIS.aoi ptPtCircuitID (51)}" ::=3D { isisCircEntry 22 } isisCircPassiveCircuit OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we include this interface in LSPs, even if it is not running the ISIS Protocol?" REFERENCE "{}" DEFVAL { false } ::=3D { isisCircEntry 23 } isisCircMeshGroupEnabled OBJECT-TYPE SYNTAX INTEGER { inactive(1), blocked(2), set(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "Is this port a member of a mesh group, or blocked? Circuits in the same mesh group act as a virtual multiaccess network. LSPs seen on one circuit in a mesh group will not be flooded to another circuit in the same mesh group." REFERENCE "{}" DEFVAL { inactive } ::=3D { isisCircEntry 24 } isisCircMeshGroup OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS read-create STATUS current DESCRIPTION "Circuits in the same mesh group act as a virtual multiaccess network. LSPs seen on one circuit in a mesh group will not be flooded to another circuit in the same mesh group. If isisCircMeshGroupEnabled is inactive, this value is ignored." REFERENCE "{}" DEFVAL { 1 } ::=3D { isisCircEntry 25 } isisCircSmallHellos OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "Can we send unpadded hellos on LAN circuits? Off means LAN Hellos must be padded." DEFVAL { off } ::=3D { isisCircEntry 26 } isisCircIPEncaps OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Should we encapsulate IS-IS in IP packets?" DEFVAL { false } ::=3D { isisCircEntry 27 } isisCircUpTime OBJECT-TYPE SYNTAX UpTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the circuit is up, the amount of time in seconds since this circuit entered state 'up'. If the circuit is not up, the number of seconds since the circuit was up, or since the system started, if the circuit has never been up. Note: This can be implemented as start time less the current time." ::=3D { isisCircEntry 28 } -- The Circuit Level Table -- This table captures level-specific information about a circuit isisCircLevelTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisCircLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Level specific information about circuits used by IS-IS" ::=3D { isisCircLevelValues 1 } isisCircLevelEntry OBJECT-TYPE SYNTAX IsisCircLevelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An isisCircLevelEntry exists for each level on each circuit used by Integrated IS-IS on this system." INDEX { isisSysInstance, isisCircIndex, isisCircLevelIndex } ::=3D { isisCircLevelTable 1 } IsisCircLevelEntry ::=3D SEQUENCE { isisSysInstance, Integer32, isisCircIndex Integer32, isisCircLevelIndex=20 Integer32, isisCircLevelDefaultMetric DefaultMetric, isisCircLevelISPriority ISPriority, isisCircLevelCircID CircuitID, isisCircLevelDesIS SystemID, isisCircLevelLANDesISChanges=20 Counter32, isisCircLevelHelloMultiplier Integer32, isisCircLevelHelloTimer Integer32, isisCircLevelDRHelloTimer Integer32, isisCircLevelLSPThrottle Integer32, isisCircLevelMinBroadLSPTransInt Integer32, isisCircLevelMinLSPTransInt Integer32, isisCircLevelCSNPInterval Integer32, isisCircLevelPartSNPInterval Integer32 } isisCircLevelIndex OBJECT-TYPE SYNTAX INTEGER { level1IS (1), level2IS (2), } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level that this entry describes." ::=3D { IsisCircLevelEntry 1 } DefaultMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value of this circuit for this level." REFERENCE "{ISIS.aoi l1DefaultMetric (35)}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 2 } isisCircLevelISPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-create STATUS current DESCRIPTION "The priority for becoming LAN Designated Intermediate System at this level." REFERENCE "{ISIS.aoi l2IntermediateSystemPriority (73)}" DEFVAL { 64 } ::=3D { IsisCircLevelEntry 3 } =20 isisCircLevelCircID OBJECT-TYPE SYNTAX CircuitID MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the circuit allocated during initialization. If no value has been negotiated (either because the adjacency is to an End System, or because initialization has not yet successfully completed), this object has the value which would be proposed for this circuit (i.e. the concatenation of the local system ID and the one octet local Circuit ID for this circuit." REFERENCE "{ISIS.aoi ptPtCircuitID (51)}" ::=3D { IsisCircLevelEntry 4 } =20 isisCircLevelDesIS OBJECT-TYPE SYNTAX SystemID MAX-ACCESS read-only STATUS current DESCRIPTION "The ID of the LAN Designated Intermediate System on this circuit at this level. If, for any reason,=20 this system is not partaking in the relevant=20 Designated Intermediate System election process,=20 then the value returned is the zero length OCTET STRING." REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}" ::=3D { IsisCircLevelEntry 5 } isisCircLevelLANDesISChanges OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of times the LAN Designated Intermediate System has changed at this level." REFERENCE "{ISIS.aoi lanL2DesignatedIntermediateSystemChanges (76)}" ::=3D { IsisCircLevelEntry 6 } isisCircLevelHelloMultiplier OBJECT-TYPE SYNTAX Integer32 (2..100) MAX-ACCESS read-create STATUS current DESCRIPTION "This value is multiplied by the corresponding HelloTimer and the result in seconds (rounded up) is used as the holding time in transmitted hellos, to be used by = receivers of hello packets from this IS" REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 7 } isisCircLevelHelloTimer OBJECT-TYPE SYNTAX Integer32 (10..600000) MAX-ACCESS read-create STATUS current DESCRIPTION "Maximum period, in milliseconds, between IIH PDUs=20 on multiaccess networks at this level for LANs. =20 The value at level 1 is used as the period between=20 Hellos on point to point circuits. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 3000 } ::=3D { IsisCircLevelEntry 8 } isisCircLevelDRHelloTimer OBJECT-TYPE SYNTAX Integer32 (10..120000) MAX-ACCESS read-create STATUS current DESCRIPTION "Period, in milliseconds, between Hello PDUs on multiaccess networks when this IS is the Designated Intermediate System. This object follows the resettingTimer behaviour." REFERENCE "{ISIS.aoi iSISHelloTimer (45)}" DEFVAL { 1000 } ::=3D { IsisCircLevelEntry 9 } isisCircLevelLSPThrottle OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimal interval of time, in milliseconds, between transmissions of LSPs on a point to point interface at this level." REFERENCE "{}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 10 } isisCircLevelMinBroadLSPTransInt OBJECT-TYPE SYNTAX Integer32 (1..1000) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in milliseconds, between transmission of LSPs on a broadcast circuit. This object follows the resettingTimer behaviour. This timer shall be capable of a resolution not coarser than 10 milliseconds." REFERENCE "{ISIS.aoi minimumBroadcastLSPTransmissionInterval = (7)}" DEFVAL { 33 } ::=3D { IsisCircLevelEntry 11 } isisCircLevelMinLSPTransInt OBJECT-TYPE SYNTAX Integer32 (1..300) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval, in seconds, between re-transmission of an LSP at this level. This object follows the = resettingTimer behaviour. Note that isisCircLevelMinBroadLSPTransInt controls how fast we send back to back LSPs. This variable controls how fast we re-send the same LSP." REFERENCE "{ISIS.aoi minimumLSPTransmissionInterval (5)}" DEFVAL { 5 } ::=3D { IsisCircLevelEntry 12 } isisCircLevelCSNPInterval OBJECT-TYPE SYNTAX Integer32 (1..600) MAX-ACCESS read-create STATUS current DESCRIPTION "Interval of time, in seconds, between transmission of CSNPs on multiaccess networks if this router is=20 the designated router at this level." REFERENCE "{}" DEFVAL { 10 } ::=3D { IsisCircLevelEntry 13 } isisCircLevelPartSNPInterval SYNTAX Integer32 (1..120) MAX-ACCESS read-create STATUS current DESCRIPTION "Minimum interval between sending Partial Sequence Number=20 PDUs at this level. This object follows the = resettingTimer=20 behaviour." REFERENCE "{ISIS.aoi partialSNPInterval (14)}" DEFVAL { 2 } ::=3D { IsisCircLevelEntry 14 } -- isisPacketCountTable keeps track of the number of IS-IS -- control packets sent and received at each level isisPacketCountTable OBJECT-TYPE SYNTAX SEQUENCE OF isisPacketCountEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about IS-IS packets sent and received" ::=3D { isisCircPDUCounters 1 } isisPacketCountEntry OBJECT-TYPE SYNTAX isisPacketCountEntry=20 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about IS-IS protocol traffic at one level=20 on one circuit in one direction" INDEX { isisSysInstance, isisCircIndex, isisPacketCountLevel, isisPacketCountDirection } ::=3D { isisPacketCountTable 1 } isisPacketCountEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisPacketCountLevel INTEGER, isisPacketCountDirection=20 INTEGER, isisPacketCountHello Counter32, isisPacketCountLSP Counter32, isisPacketCountCSNP Counter32, isisPacketCountPSNP Counter32 } isisPacketCountLevel OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), } MAX-ACCESS read-create STATUS current DESCRIPTION "The level at which these PDU counts have been collected." ::=3D { isisPacketCountEntry 1 } isisPacketCountDirection OBJECT-TYPE SYNTAX INTEGER { sending(1), receiving(2), } MAX-ACCESS read-create STATUS current DESCRIPTION "Were we sending or receiving these PDUs?" ::=3D { isisPacketCountEntry 2 } isisPacketCountHello OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS Hello PDUs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 3 } isisPacketCountLSP OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS LSPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 4 } isisPacketCountCSNP OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS CSNPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 5 } isisPacketCountPSNP OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of IS-IS PSNPs seen in this direction at this level." REFERENCE "{ISIS.aoi iSISControlPDUsSent (43)}" ::=3D { isisPacketCountEntry 6 } -- The Circuit IS Group -- -- The Circuit IS Group is present if the system supports the -- IS functions of the ISO 9542 protocol. -- The Circuit IS Table -- -- This table is not implemented - jdp -- The IS Adjacency Group -- -- The IS Adjacency Group is current and contains information -- about adjacencies to routers maintained by the Integrated -- IS-IS protocol -- -- The IS Adjacency Table -- -- Each adjacency to an IS corresponds to one entry in this -- table. isisISAdjTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of adjacencies to Intermediate Systems." ::=3D { isisISAdj 1 } isisISAdjEntry OBJECT-TYPE SYNTAX IsisISAdjEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry corresponds to one adjacency to an Intermediate System on this system." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex } ::=3D { isisISAdjTable 1 } IsisISAdjEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjIndex Integer32, isisISAdjState INTEGER, isisISAdjNeighSNPAAddress SNPAAddress, isisISAdjNeighSysType INTEGER, isisISAdjNeighSysID OCTET STRING, isisISAdjUsage INTEGER, isisISAdjHoldTimer Integer32, isisISAdjNeighPriority ISPriority, isisISAdjUpTime UpTime } isisISAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value identifying the IS adjacency from all other such adjacencies on this circuit. This value is assigned by the system when the adjacency is created automatically." ::=3D { isisISAdjEntry 1 } isisISAdjState OBJECT-TYPE SYNTAX INTEGER { initializing (1), up (2), failed (3), down (4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the adjacency" REFERENCE "{ISIS.aoi adjacencyState (78)}" ::=3D { isisISAdjEntry 2 } isisISAdjNeighSNPAAddress OBJECT-TYPE SYNTAX SNPAAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SNPA address of the neighboring system." REFERENCE "{ISIS.aoi neighbourSNPAAddress (79)}" ::=3D { isisISAdjEntry 3 } isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { l1IntermediateSystem(1), l2IntermediateSystem(2), l1l2IntermediateSystem(3), unknown(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the neighboring system." REFERENCE "{ISIS.aoi neighbourSystemType (80)}" ::=3D { isisISAdjEntry 4 } isisISAdjNeighSysID OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..12)) MAX-ACCESS read-only STATUS current DESCRIPTION "The system ID and 4 byte circuit ID of the=20 neighboring Intermediate System set from=20 the source ID field of the Three-Way-Handshake information from the neighbor's IIH PDUs." REFERENCE "{ISIS.aoi neighbourSystemIds (83)}" ::=3D { isisISAdjEntry 5 } isisISAdjUsage OBJECT-TYPE SYNTAX INTEGER { undefined(1), level1(2), level2(3), level1and2(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "An adjacency of type level1 is used for level 1 traffic only. An adjacency of type level2 is used for level 2 traffic only. An adjacency of type level1and2 is used for both level 1 and level 2 traffic. There may be two adjacencies (of types level1 and level2) between the same pair of Intermediate Systems." REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::=3D { isisISAdjEntry 6 } isisISAdjHoldTimer OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The holding time for this adjacency updated from received IIH PDUs." REFERENCE "{ISIS.aoi holdingTimer (85)}" ::=3D { isisISAdjEntry 7 } isisISAdjNeighPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the LAN Level 1 Designated Intermediate System if the value of isisISAdjNeighSysType is L1IntermediateSystem or LAN Level 2 Designated Intermediate System if the value of isisISAdjNeighSysType is L2IntermediateSystem." REFERENCE "{ISIS.aoi lANPriority (86)}" ::=3D { isisISAdjEntry 8 } isisISAdjUpTime OBJECT-TYPE SYNTAX UpTime MAX-ACCESS read-only STATUS current DESCRIPTION "If the adjacency is up, the amount of time in seconds since this adjacency entered state 'up'. If the adjacency is not up, the number of seconds since the adjacency was up, or since the system started, if the adjacency has never been up. Note: This can be implemented as start time less the current time." ::=3D { isisISAdjEntry 9 } -- The IS Adjacency Area Address Table -- The IS Adjacency Area Address Table contains the set of -- Area Addresses of neighboring -- Intermediate Systems as reported in IIH PDUs. isisISAdjAreaAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of Area Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." REFERENCE "{ISIS.aoi areaAddressesOfNeighbour (84)}" ::=3D { isisISAdj 2 } isisISAdjAreaAddrEntry OBJECT-TYPE SYNTAX IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one Area Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjAreaAddrAdjIndex, isisISAdjAreaAddress } ::=3D { isisISAdjAreaAddrTable 1 } IsisISAdjAreaAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjAreaAddrAdjIndex Integer32, isisISAdjAreaAddress OSINSAddress } isisISAdjAreaAddrAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the IS adjacency to which this entry belongs." ::=3D { isisISAdjAreaAddrEntry 1 } isisISAdjAreaAddress OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "One Area Address as reported in IIH PDUs received from the neighbor." ::=3D { isisISAdjAreaAddrEntry 2 } -- The IS Adjacency IP Group -- The IS Adjacency IP Group is present if the system supports -- IP Integrated IS-IS -- The IS Adjacency IP Address Table -- The IS Adjacency IP Address Table contains the -- set of IP Addresses of neighboring Intermediate Systems -- as reported in received IIH PDUs. isisISAdjIPAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of IP Addresses of neighboring Intermediate Systems as reported in received IIH PDUs." ::=3D { isisISAdj 3 } isisISAdjIPAddrEntry OBJECT-TYPE SYNTAX IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjIPAddrAdjIndex } ::=3D { isisISAdjIPAddrTable 1 } IsisISAdjIPAddrEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjIPAddrAdjIndex Integer32, isisISAdjIPAddress IpAddress } isisISAdjIPAddrAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier of the IS adjacency to which this entry belongs." ::=3D { isisISAdjIPAddrEntry 1 } isisISAdjIPAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "One IP Address as reported in IIH PDUs received from the neighbor." ::=3D { isisISAdjIPAddrEntry 2 } -- The IS Adjacency Integrated Group -- -- The IS Adjacency Integrated Group is present if the system -- supports Integrated ISIS. -- -- -- The IS Adjacency Protocol Supported Table -- -- The IS Adjacency Protocol Supported Table contains the set of -- protocols supported by neighboring -- Intermediate Systems as reported in received IIH PDUs. -- isisISAdjProtSuppTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the set of protocols supported by neighboring Intermediate Systems as reported in received IIH PDUs." ::=3D { isisISAdj 4 } isisISAdjProtSuppEntry OBJECT-TYPE SYNTAX IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by a neighboring Intermediate System as reported in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjProtSuppAdjIndex, isisISAdjProtSuppProtocol } ::=3D { isisISAdjProtSuppTable 1 } IsisISAdjProtSuppEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisISAdjProtSuppAdjIndex Integer32, isisISAdjProtSuppProtocol SupportedProtocol } isisISAdjProtSuppAdjIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier the IS adjacency to which this entry corresponds." ::=3D { isisISAdjProtSuppEntry 1 } isisISAdjProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "One supported protocol as reported in IIH PDUs received from the neighbor." ::=3D { isisISAdjProtSuppEntry 2 } -- -- -- The ES Adjacency Group -- -- The ES Adjacency Group is present if the system supports -- reception of ES Hellos -- The ES Adjacency Table -- -- Not supported - jdp -- -- -- The Reachable Address Group -- -- The Reachable Address Group is optional. -- The Reachable Address Table -- Each entry records information about a reachable address -- (NSAP or address prefix) manually configured on the system -- or learned through another protocol. isisRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of Reachable Addresses to NSAPs or Address Prefixes." ::=3D { isisReachAddr 1 } isisRAEntry OBJECT-TYPE SYNTAX IsisRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines a Reachable Address to a NSAP or Address Prefix." INDEX { isisSysInstance, isisCircIndex, isisRAIndex } ::=3D { isisRATable 1 } IsisRAEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisRAIndex Integer32, isisRAExistState RowStatus, isisRAAdminState AdminState, isisRAAddrPrefix NSAPPrefix, isisRAMapType INTEGER, isisRADefMetric DefaultMetric, isisRADefMetricType MetricType, isisRASNPAAddress SNPAAddress, isisRASNPAMask SNPAPrefix, isisRASNPAPrefix SNPAPrefix, isisRAType INTEGER } isisRAIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier for this isisRAEntry. This value must be unique amongst all Reachable Addresses on the same parent Circuit. This object follows the index and manualOrAutomatic behaviours." ::=3D { isisRAEntry 1 } isisRAExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The existence state of this Reachable Address. This object follows the Row Status behaviours." DEFVAL { active } ::=3D { isisRAEntry 2 } isisRAAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the Reachable Address. This object follows the AdminState and manualOrAutomatic behaviours." DEFVAL { off } ::=3D { isisRAEntry 3 } isisRAAddrPrefix OBJECT-TYPE SYNTAX NSAPPrefix MAX-ACCESS read-create STATUS current DESCRIPTION "The destination of this Reachable Address. This is an Address Prefix. This object follows the replaceOnlyWhileDisabled and manualOrAutomatic behaviours." REFERENCE "{ISIS.aoi addressPrefix (98)}" ::=3D { isisRAEntry 4 } isisRAMapType OBJECT-TYPE SYNTAX INTEGER { none (1), explicit (2), extractIDI (3), extractDSP (4) } MAX-ACCESS read-create STATUS current DESCRIPTION "The type of mapping to be employed to ascertain the SNPA Address which should be used in forwarding PDUs for this Reachable Address prefix. This object follows the manualOrAutomatic behaviour. The following values of mapping type are defined: none: The mapping is null because the neighbor SNPA is implicit by nature of the subnetwork (e.g. a point-to-point linkage). explicit: The subnetwork addresses in the object isisRASNPAAddress is to be used. extractIDI: The SNPA is embedded in the IDI of the destination NSAP Address. The mapping algorithm extracts the SNPA to be used according to the format and encoding rules of ISO8473/Add2. This SNPA extraction algorithm can be used in conjunction with Reachable Address prefixes from the X.121, F.69, E.163 and E.164 addressing subdomains. extractDSP: All, or a suffix, of the SNPA is embedded in the DSP of the destination address. This SNPA extraction algorithm extracts the embedded subnetwork addressing information by performing a logical AND of the isisRASNPAMask object value with the destination address. The part of the SNPA extracted from the destination NSAP is appended to the isisRASNPAPrefix object value to form the next hop subnetwork addressing information." REFERENCE "{ISO10589-ISIS.aoi mappingType (107)}" ::=3D { isisRAEntry 5 } isisRADefMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value for reaching the specified prefix over this circuit. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi defaultMetric (99)}" DEFVAL { 20 } ::=3D { isisRAEntry 6 } isisRADefMetricType OBJECT-TYPE SYNTAX MetricType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the default metric is internal or external. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi defaultMetricType (103)}" DEFVAL { internal } ::=3D { isisRAEntry 7 } isisRASNPAAddress OBJECT-TYPE SYNTAX SNPAAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination which matches the address prefix of the Reachable Address. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi sNPAAddresses (109)}" -- note only one address may be specified per Reachable Address -- in the MIB DEFVAL { ''H } ::=3D { isisRAEntry 8 } isisRASNPAMask OBJECT-TYPE SYNTAX SNPAPrefix MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask with 1 bits indicating the positions in the effective destination address from which embedded SNPA information is to be extracted. For the extraction the first octet of the isisRASNPAMask object value is aligned with the first octet (AFI) of the NSAP Address. If the isisRASNPAMask object value and NSAP Address are of different lengths, the shorter of the two is logically padded with zeros before performing the extraction. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi sNPAMask (122)}" DEFVAL { '00'H } ::=3D { isisRAEntry 9 } isisRASNPAPrefix OBJECT-TYPE SYNTAX SNPAPrefix MAX-ACCESS read-create STATUS current DESCRIPTION "A fixed SNPA prefix for use when the isisRAMapType is extractDSP. The SNPA Address to use is formed by concatenating the fixed SNPA prefix with a variable SNPA part that is extracted from the effective destination address. For Reachable Address prefixes in which the entire SNPA is embedded in the DSP the SNPA Prefix shall be null. This object follows the manualOrAutomatic behaviour." REFERENCE "{ISIS.aoi sNPAPrefix (123)}" DEFVAL { '00'H } ::=3D { isisRAEntry 10 } isisRAType OBJECT-TYPE SYNTAX INTEGER { manual (1), automatic (2) } MAX-ACCESS read-create STATUS current DESCRIPTION " The type of Reachable address. Those of type manual are created by the network manager. Those of type automatic are created through propogation of routing information from another routing protocol (eg. IDRP). " DEFVAL {manual} ::=3D {isisRAEntry 11 } -- The IP Reachable Address Group -- The IP Reachable Address Group is optional. -- The IP Reachable Address Table -- Each entry records information about one IP reachable -- address manually configured on this system or learned from -- another protocol. isisIPRATable OBJECT-TYPE SYNTAX SEQUENCE OF IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of IP Reachable Addresses to networks, subnetworks or hosts either manually configured or learned from another protocol." ::=3D { isisIPReachAddr 1 } isisIPRAEntry OBJECT-TYPE SYNTAX IsisIPRAEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry defines an IP Reachable Address to a network, subnetwork or host." INDEX { isisSysInstance, isisCircIndex, isisIPRAType, isisIPRAIndex } ::=3D { isisIPRATable 1 } IsisIPRAEntry ::=3D SEQUENCE { isisSysInstance Integer32, isisCircIndex Integer32, isisIPRAIndex Integer32, isisIPRAType INTEGER, isisIPRADest IpAddress, isisIPRAMask IpAddress, isisIPRAExistState RowStatus, isisIPRAAdminState AdminState, isisIPRADefMetric DefaultMetric, isisIPRADefMetricType MetricType, isisIPRASNPAAddress SNPAAddress } isisIPRAIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The identifier for this isisIPRAEntry. This value must be unique amongst all IP Reachable Addresses on the same parent Circuit. This object follows the index and manualOrAutomatic behaviours." ::=3D { isisIPRAEntry 1 } isisIPRAType OBJECT-TYPE SYNTAX INTEGER { manual (1), automatic (2) } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The type of this IP Reachable Address. Those of type manual are created by the network manager. Those of type automatic are created through propagation of routing information from another routing protocol." ::=3D { isisIPRAEntry 2 } isisIPRADest OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The destination of this IP Reachable Address. This is either a network address, subnetwork address or host address. This object follows the manualOrAutomatic behaviour." ::=3D { isisIPRAEntry 3 } isisIPRAMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The network mask for the IP Address in the isisIPRADest object. This object follows the manualOrAutomatic behaviour." ::=3D { isisIPRAEntry 4 } isisIPRAExistState OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The state of this IP Reachable Address. This object follows the ExistenceState and manualOrAutomatic behaviours." DEFVAL { active } ::=3D { isisIPRAEntry 5 } isisIPRAAdminState OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-create STATUS current DESCRIPTION "The administrative state of the IP Reachable Address. = This object follows the AdminState and manualOrAutomatic behaviours." DEFVAL { off } ::=3D { isisIPRAEntry 6 } isisIPRADefMetric OBJECT-TYPE SYNTAX DefaultMetric MAX-ACCESS read-create STATUS current DESCRIPTION "The default metric value for reaching the specified destination over this circuit. This object follows the manualOrAutomatic behaviour." DEFVAL { 20 } ::=3D { isisIPRAEntry 7 } isisIPRADefMetricType OBJECT-TYPE SYNTAX MetricType MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates whether the default metric is internal or external. This object follows the manualOrAutomatic behaviour." DEFVAL { internal } ::=3D { isisIPRAEntry 8 } isisIPRASNPAAddress OBJECT-TYPE SYNTAX SNPAAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The SNPA Address to which a PDU may be forwarded in order to reach a destination which matches this IP Reachable Address. This object follows the manualOrAutomatic behaviour." DEFVAL { ''H } ::=3D { isisIPRAEntry 9 } -- The Circuit CLNS Group -- -- The Circuit CLNS Table contains objects controlling the -- operation of the IS functions of the CLNS protocol -- -- Removed - jdp -- -- The IP Destination Group -- The IP Destination Group is present if the system forwards -- IP packets. -- The IP Destination Table -- The IP Destination Table records information about each -- destination known to the Intermediate System -- Removed: overlaps RFC 2096 END -- End of Object Definitions ------_=_NextPart_000_01C0BEA5.F7EB2D00-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 24 16:32:45 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14671 for ; Tue, 24 Apr 2001 16:32:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70685; Tue, 24 Apr 2001 14:10:17 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA40079 for ; Thu, 19 Apr 2001 10:20:42 -0700 (PDT) Received: from web14104.mail.yahoo.com (web14104.mail.yahoo.com [216.136.172.134]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f3JGaMb82689 for ; Thu, 19 Apr 2001 09:36:32 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: <20010419163959.74749.qmail@web14104.mail.yahoo.com> Received: from [153.39.146.202] by web14104.mail.yahoo.com; Thu, 19 Apr 2001 09:39:59 PDT From: Amir Birjandi To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] Multilevel verses multi instance Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 19 Apr 2001 09:39:59 -0700 (PDT) Hi, I have a basic question. What are the pros and cons of Multi instance verses Multi level ISIS? I apologize if this has already been addressed. I tried the mailing list up to mid 2000, but i couldn't find anything. Regards A. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 24 16:33:06 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14683 for ; Tue, 24 Apr 2001 16:33:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70713; Tue, 24 Apr 2001 14:11:18 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA68354 for ; Tue, 24 Apr 2001 04:03:57 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f3OAYto41784 for ; Tue, 24 Apr 2001 03:35:06 -0700 (PDT) X-JNPR-Received-From: outside Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 24 Apr 2001 15:55:45 +0530 Received: from vamsik (vamsik.future.futsoft.com [10.20.6.28]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f3OAJYe08994 for ; Tue, 24 Apr 2001 15:49:35 +0530 Reply-To: From: "Vamsi K" To: Message-Id: <000501c0cca4$eeb33a40$1c06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] help needed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Apr 2001 15:27:10 +0530 Content-Transfer-Encoding: 7bit Hi , I need small clarification regarding the IS-IS routing protocol functinalities. Here i have small set up | L2 IS(A)|<-------------------->|L1IS(B)|<-------------------------->|L2IS(C)| In the above configuration whether the L2IS A exchanges the L2 link state PDUs with L2IS at C. Assumption there is no direct link between these two. The Intermediate Systems both A and C act as L1 and as well as L2. Here my doubt is whether L2 PDUS can be traversed through L1IS B to reach the L2IS C. Could anybody can help me in this regard. Thanks & Regards vamsi.P _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 24 16:50:23 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15033 for ; Tue, 24 Apr 2001 16:50:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70918; Tue, 24 Apr 2001 14:24:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70906 for ; Tue, 24 Apr 2001 14:23:46 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3OKchb50255 for ; Tue, 24 Apr 2001 13:38:44 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'vamsik@future.futsoft.com'" , isis-wg@juniper.net Subject: RE: [Isis-wg] help needed MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CCFF.185081F0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Apr 2001 16:42:36 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0CCFF.185081F0 Content-Type: text/plain; charset="iso-8859-1" > Here i have small set up > > L1L2 IS(A)<-------->L1 IS(B)<------->L1L2 IS(C) > > Assumption there is no direct link between (A and C) > > The Intermediate Systems both A and C act as L1 and as well as L2. > > Here my doubt is whether L2 PDUS can be traversed through > L1IS B to reach the L2IS C. > > vamsi.P You are right to have doubts. The L2 domain is split. There are provisions in the spec to replair broken L1 areas, but not to patch split L2. - jeff parker - axiowave networks - I think, therefore I am. I think. ------_=_NextPart_001_01C0CCFF.185081F0 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] help needed

> Here i have small set up
>   
> L1L2 IS(A)<-------->L1 IS(B)<------->L1L2 IS(C)
>
> Assumption there is no direct link between (A and C)
>
> The Intermediate Systems both  A and C act as L1 and as well as L2.
>
> Here my doubt is whether L2 PDUS can be traversed through
> L1IS B to reach the L2IS C.
>
> vamsi.P

You are right to have doubts.  The L2 domain is split. 
There are provisions in the spec to replair broken L1
areas, but not to patch split L2. 

- jeff parker
- axiowave networks
- I think, therefore I am. I think.

------_=_NextPart_001_01C0CCFF.185081F0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 24 16:53:04 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15071 for ; Tue, 24 Apr 2001 16:53:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70980; Tue, 24 Apr 2001 14:29:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA70968 for ; Tue, 24 Apr 2001 14:28:41 -0700 (PDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3OKhZb50479 for ; Tue, 24 Apr 2001 13:43:35 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-161-44-19-46.cisco.com [161.44.19.46]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA23748; Tue, 24 Apr 2001 13:47:21 -0700 (PDT) Message-Id: <4.3.2.7.2.20010424154356.01c42ee8@ce-nfs-1.cisco.com> X-Sender: mbartell@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Micah Bartell Subject: Re: [Isis-wg] help needed Cc: In-Reply-To: <000501c0cca4$eeb33a40$1c06140a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Apr 2001 15:47:16 -0500 Assuming that RTRB is an L1 Only IS, no, it will not act as a transit for L2 LSPs. L2 IS's must be contiguous. This is because the ADJ between RTRA and RTRB would be L1 only, and so RTRA would not flood an L2 LSP over and L1 Only ADJ. Same goes for the RTRB and RTRC ADJ. /mpb At 15:27 04/24/2001 +0530, Vamsi K wrote: > Hi , > I need small clarification regarding the IS-IS routing protocol >functinalities. > > >Here i have small set up > > > > | L2 >IS(A)|<-------------------->|L1IS(B)|<-------------------------->|L2IS(C)| > > > >In the above configuration whether the L2IS A exchanges the L2 link state >PDUs with L2IS at C. >Assumption there is no direct link between these two. > >The Intermediate Systems both A and C act as L1 and as well as L2. > >Here my doubt is whether L2 PDUS can be traversed through L1IS B to reach >the L2IS C. > > >Could anybody can help me in this regard. > > >Thanks & Regards >vamsi.P > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Apr 24 17:22:08 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15557 for ; Tue, 24 Apr 2001 17:22:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA71229; Tue, 24 Apr 2001 14:59:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA71217 for ; Tue, 24 Apr 2001 14:58:20 -0700 (PDT) Received: from optic3.ipoptical.com ([64.242.9.180]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3OLDEb51809 for ; Tue, 24 Apr 2001 14:13:15 -0700 (PDT) X-JNPR-Received-From: outside Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Apr 2001 17:13:08 -0400 Message-ID: From: Ben Abarbanel To: "'vamsik@future.futsoft.com'" , isis-wg@juniper.net Subject: RE: [Isis-wg] help needed MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Apr 2001 17:13:07 -0400 Vamsi: A level 1 router will flood to all its neighbors except the originating Level 1 router its L1 LSP. A Level 2 router will do the same. Thus B must speak both Level 1 and Level 2 to flood IS(A) LSP-Level-1 to IS(C) and vice versa. You should assume,that Level 1 routers will reach all Level 1 routers in the cloud if there is Level 1 reachability. Same goes with Level 2. The other way to get Level-1 routes to Level-2 routers is to Leak the routes inside the LSP to the other Level and hence flood them inside the other Level-n LSP. I hope this helped more than confused you. Regards, Ben -----Original Message----- From: Vamsi K [mailto:vamsik@future.futsoft.com] Sent: Tuesday, April 24, 2001 5:57 AM To: isis-wg@juniper.net Subject: [Isis-wg] help needed Hi , I need small clarification regarding the IS-IS routing protocol functinalities. Here i have small set up | L2 IS(A)|<-------------------->|L1IS(B)|<-------------------------->|L2IS(C)| In the above configuration whether the L2IS A exchanges the L2 link state PDUs with L2IS at C. Assumption there is no direct link between these two. The Intermediate Systems both A and C act as L1 and as well as L2. Here my doubt is whether L2 PDUS can be traversed through L1IS B to reach the L2IS C. Could anybody can help me in this regard. Thanks & Regards vamsi.P _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 01:45:06 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29686 for ; Wed, 25 Apr 2001 01:45:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA73252; Tue, 24 Apr 2001 23:23:05 -0700 (PDT) Received: from mail16.bigmailbox.com (mail16.bigmailbox.com [209.132.220.47]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA73240 for ; Tue, 24 Apr 2001 23:22:50 -0700 (PDT) Received: by mail16.bigmailbox.com (8.8.7/8.8.7) id WAA23767; Tue, 24 Apr 2001 22:41:44 -0700 Message-Id: <200104250541.WAA23767@mail16.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [61.135.52.198] From: "Navaneeth Krishnan" To: isis-wg@spider.juniper.net Subject: [Isis-wg] ISIS References.. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Apr 2001 22:41:44 -0700 Content-Transfer-Encoding: binary Hi, Can anybody suggest some good references/drafts/links for implementing ISIS over IP Unnumbered interfaces, ISIS Multiple Instance support and redistirbution of routes into ISIS? This will be greatly helpful. Regards Navaneeth. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 05:29:24 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09740 for ; Wed, 25 Apr 2001 05:29:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA74383; Wed, 25 Apr 2001 03:08:06 -0700 (PDT) Received: from mailgate.alcatel.fr (mail.alcatel.fr [194.133.58.151]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA74369 for ; Wed, 25 Apr 2001 03:07:42 -0700 (PDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mailgate.alcatel.fr (ALCANET/SMTP) with ESMTP id KAA25731 for ; Wed, 25 Apr 2001 10:05:09 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id LAA14405 for ; Wed, 25 Apr 2001 11:20:12 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id LAA27886 for ; Wed, 25 Apr 2001 11:26:12 +0200 (MET DST) Received: from reaumur.dinsunnet (reaumur [188.9.33.51]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id LAA11693 for ; Wed, 25 Apr 2001 11:26:18 +0200 (MET DST) Received: from ms.alcatel.fr by reaumur.dinsunnet (SMI-8.6/SMI-SVR4) id LAA23463; Wed, 25 Apr 2001 11:21:22 +0200 Message-ID: <3AE69712.A97FBC7D@ms.alcatel.fr> From: Bruno Mongazon X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "isis-wg@spider.juniper.net" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] IS-IS restart (more comments) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 11:21:22 +0200 Content-Transfer-Encoding: 7bit Hi Mike, Here are some more comments about your IS-IS restart draft. 1. Simultaneous restart of peers The draft does not explicitely indicate if simultaneous restart of peers is possible/supported. My current understanding is that it is not possible for peers to restart simultaneously mainly because the restart mechanism implies a peer to help the restarting router. If my understanding is correct, it could be fine to indicate explicitely in the draft that simultaneous restart is not possible. If my understanding is not correct, can you give a few explanation of what happens in the case of simultaneous restart of peers. 2. State table Could be fine to split the state table in two state tables: -state table of the restarting IS-IS -state table of a peer IS-IS which helps a peer to restart My motivations are the followings: -make the state table more readable and understandable as it is currently -distinguish two behaviors: engine restart and engine restart assistance 3. Forwarding activity during restart I understand the draft as useful _only_ if the forwarding activity is not discontinued when ISIS is restarting. This might be stated explicitely in the draft because it implies a control/forwarding separation in the router. If forwarding is not discontinued during restart, it might however be temporarily out-of-date until restart completes (engine is back to Running state) if routing has changed in the meantime. Since being out-of-date during restart might have impacts on network users, i guess this should be stated explicitely in the draft. In particular excessive restart times definitely have impacts on routing. 4. Typo's Page 8: <= ...(which is has generated, but not yet transmitted)... => ...(which it has generated, but not yet transmitted)... Thanks in advance for your reply. Bruno. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 06:24:48 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10077 for ; Wed, 25 Apr 2001 06:24:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA74687; Wed, 25 Apr 2001 04:03:05 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA74675 for ; Wed, 25 Apr 2001 04:02:09 -0700 (PDT) Received: from mshand-w2k.cisco.com (uxb-dhcp-198-135-1-186.cisco.com [198.135.1.186]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA22729; Wed, 25 Apr 2001 11:17:37 +0100 (BST) Message-Id: <4.3.2.7.2.20010425103727.00b92f30@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Bruno Mongazon From: mike shand Subject: Re: [Isis-wg] IS-IS restart (more comments) Cc: "isis-wg@spider.juniper.net" In-Reply-To: <3AE69712.A97FBC7D@ms.alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 11:15:34 +0100 At 11:21 25/04/2001 +0200, Bruno Mongazon wrote: >Hi Mike, > >Here are some more comments about your IS-IS restart draft. > >1. Simultaneous restart of peers > >The draft does not explicitely indicate if simultaneous restart of peers >is possible/supported. My current understanding is that it is not >possible for peers to restart simultaneously mainly because the restart >mechanism implies a peer to help the restarting router. > >If my understanding is correct, it could be fine to indicate explicitely >in the draft that simultaneous restart is not possible. If my >understanding is not correct, can you give a few explanation of what >happens in the case of simultaneous restart of peers. It depends what you mean by supported. I think it has to be supported in the sense that if neighbors do restart simultaneously nothing bad happens. Although the draft doesn't state this explicitly, both neighbors can operate the restart algorithms with each other (as well as their non-restarted neighbors). So both would set RR and both would expect RA and note the LSP IDs from the received CSNPs. In the case where both neighbors were restarting the initial CSNPs over those interfaces would not reference very much and so those two neighbors would not add very much to the set of LSPs which must be acquired before synchronization is declared complete. But presumably other interfaces would contribute the full set of LSP IDs so the synchronization would not terminate prematurely. Obviously if one of the routers in question were ONLY connected to the other restarting router, then it may be fooled into thinking that it was synchronized prematurely. This would negate the "restart" capability but would be equivalent to what would have happened with a standard implementation. So nothing "bad" happens. >2. State table > >Could be fine to split the state table in two state tables: > >-state table of the restarting IS-IS >-state table of a peer IS-IS which helps a peer to restart > >My motivations are the followings: > >-make the state table more readable and understandable as it is >currently >-distinguish two behaviors: engine restart and engine restart assistance I'll look into that. >3. Forwarding activity during restart > >I understand the draft as useful _only_ if the forwarding activity is >not discontinued when ISIS is restarting. This might be stated >explicitely in the draft because it implies a control/forwarding >separation in the router. OK >If forwarding is not discontinued during restart, it might however be >temporarily out-of-date until restart completes (engine is back to >Running state) if routing has changed in the meantime. Since being >out-of-date during restart might have impacts on network users, i guess >this should be stated explicitely in the draft. In particular excessive >restart times definitely have impacts on routing. Sure. I would only expect it to be used where restart times were of the order of a few seconds. One possibility is to abort the restart when the neighbor detects a topology change. Ideally this would only be a topology change which affects routes passing through the restarting router. i.e. if the neighbor thinks that the restarting router's forwarding table may be wrong, it treats the adjacency as down and routes around it (if possible). But if we wanted to do that we would need an indication from the neighbor that it had now re-run its SPF, and hence the adjacency is trustworthy. This could either be explicitly signalled by another bit in the hello restart TLV, or perhaps we could notice that the neighbor had re-issued its own LSP. >4. Typo's > >Page 8: ><= ...(which is has generated, but not yet transmitted)... >=> ...(which it has generated, but not yet transmitted)... Noted. >Thanks in advance for your reply. >Bruno. Thanks for your comments. BTW, in case people hadn't noticed, the draft is now available from the usual places e.g. ftp://ftp.ietf.org/internet-drafts/draft-shand-isis-restart-00.txt Mike >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 09:24:37 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14594 for ; Wed, 25 Apr 2001 09:24:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA75558; Wed, 25 Apr 2001 07:02:06 -0700 (PDT) Received: from mel.alcatel.fr (mel.alcatel.fr [212.208.74.132]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA75546 for ; Wed, 25 Apr 2001 07:01:51 -0700 (PDT) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA24580; Wed, 25 Apr 2001 14:05:48 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA26027; Wed, 25 Apr 2001 15:14:13 +0200 (MET DST) Received: from ms.ms.alcatel.fr (ms.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA09876; Wed, 25 Apr 2001 15:20:08 +0200 (MET DST) Received: from reaumur.dinsunnet (reaumur [188.9.33.51]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with SMTP id PAA07602; Wed, 25 Apr 2001 15:20:16 +0200 (MET DST) Received: from ms.alcatel.fr by reaumur.dinsunnet (SMI-8.6/SMI-SVR4) id PAA24062; Wed, 25 Apr 2001 15:15:21 +0200 Message-ID: <3AE6CDE9.34829CA1@ms.alcatel.fr> From: Bruno Mongazon X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mike shand CC: "isis-wg@spider.juniper.net" Subject: Re: [Isis-wg] IS-IS restart (more comments) References: <4.3.2.7.2.20010425103727.00b92f30@jaws.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 15:15:21 +0200 Content-Transfer-Encoding: 7bit mike shand wrote: > > At 11:21 25/04/2001 +0200, Bruno Mongazon wrote: > >Hi Mike, > > > >Here are some more comments about your IS-IS restart draft. > > > >1. Simultaneous restart of peers > > > >The draft does not explicitely indicate if simultaneous restart of peers > >is possible/supported. My current understanding is that it is not > >possible for peers to restart simultaneously mainly because the restart > >mechanism implies a peer to help the restarting router. > > > >If my understanding is correct, it could be fine to indicate explicitely > >in the draft that simultaneous restart is not possible. If my > >understanding is not correct, can you give a few explanation of what > >happens in the case of simultaneous restart of peers. > > It depends what you mean by supported. I think it has to be supported in > the sense that if neighbors do restart simultaneously nothing bad happens. > Although the draft doesn't state this explicitly, both neighbors can > operate the restart algorithms with each other (as well as their > non-restarted neighbors). So both would set RR and both would expect RA and > note the LSP IDs from the received CSNPs. In the case where both neighbors > were restarting the initial CSNPs over those interfaces would not reference > very much and so those two neighbors would not add very much to the set of > LSPs which must be acquired before synchronization is declared complete. > But presumably other interfaces would contribute the full set of LSP IDs so > the synchronization would not terminate prematurely. > > Obviously if one of the routers in question were ONLY connected to the > other restarting router, then it may be fooled into thinking that it was > synchronized prematurely. This would negate the "restart" capability but > would be equivalent to what would have happened with a standard > implementation. So nothing "bad" happens. > Fine, you designed the mechanism in a way that nothing bad should happen in case of simultaneous restarts. Then you might or not state it explicitely in the draft. Note that this question came to my mind while checking the state table for such a case. In particular could you please clarify my following wonders: When the state table specifies an Action such as the one depicted hereafter, State: Running Event: Router Restarted Action: Set SRM Send RR Send CSNP Start T1 Next state: Restarting Do you assume that all PDUs transmission performed as part of an action are done before a PDU reception (more generally an event) can be handled by the state machine ? More clearly, given the previous action, do you assume it is not possible for a RA PDU to enter the state machine after RR has been sent and while CSNP is not yet sent ? > >2. State table > > > >Could be fine to split the state table in two state tables: > > > >-state table of the restarting IS-IS > >-state table of a peer IS-IS which helps a peer to restart > > > >My motivations are the followings: > > > >-make the state table more readable and understandable as it is > >currently > >-distinguish two behaviors: engine restart and engine restart assistance > > I'll look into that. > > >3. Forwarding activity during restart > > > >I understand the draft as useful _only_ if the forwarding activity is > >not discontinued when ISIS is restarting. This might be stated > >explicitely in the draft because it implies a control/forwarding > >separation in the router. > > OK > > >If forwarding is not discontinued during restart, it might however be > >temporarily out-of-date until restart completes (engine is back to > >Running state) if routing has changed in the meantime. Since being > >out-of-date during restart might have impacts on network users, i guess > >this should be stated explicitely in the draft. In particular excessive > >restart times definitely have impacts on routing. > > Sure. I would only expect it to be used where restart times were of the > order of a few seconds. One possibility is to abort the restart when the > neighbor detects a topology change. Ideally this would only be a topology > change which affects routes passing through the restarting router. i.e. if > the neighbor thinks that the restarting router's forwarding table may be > wrong, it treats the adjacency as down and routes around it (if possible). > But if we wanted to do that we would need an indication from the neighbor > that it had now re-run its SPF, and hence the adjacency is trustworthy. > This could either be explicitly signalled by another bit in the hello > restart TLV, or perhaps we could notice that the neighbor had re-issued its > own LSP. > Interesting proposal? If there is an additional bit in the restart TLV indicating that the neighbor has or not re-run its SPF, then the restarting router might use the bit to re-run or not its SPF. If there is no additional bit, i guess the restarting router will have to always re-run its SPF after restart. Is the additional bit interesting? Bruno. > >4. Typo's > > > >Page 8: > ><= ...(which is has generated, but not yet transmitted)... > >=> ...(which it has generated, but not yet transmitted)... > > Noted. > > >Thanks in advance for your reply. > >Bruno. > > Thanks for your comments. > > BTW, in case people hadn't noticed, the draft is now available from the > usual places > > e.g. ftp://ftp.ietf.org/internet-drafts/draft-shand-isis-restart-00.txt > > Mike > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 14:08:58 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24897 for ; Wed, 25 Apr 2001 14:08:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA76719; Wed, 25 Apr 2001 11:46:34 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA75060 for ; Wed, 25 Apr 2001 05:12:46 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3PBRbb71700 for ; Wed, 25 Apr 2001 04:27:37 -0700 (PDT) X-JNPR-Received-From: outside Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 25 Apr 2001 17:07:13 +0530 Received: from vamsik (vamsik.future.futsoft.com [10.20.6.28]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f3PBXae27830 for ; Wed, 25 Apr 2001 17:03:37 +0530 Reply-To: From: "Vamsi K" To: Message-Id: <000b01c0cd78$68545220$1c06140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Help needed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 16:40:58 +0530 Content-Transfer-Encoding: 7bit Hi , In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit confusing. Here i am quoting the exact words. Once a particular adjacency has been assigned to a particular LSP number, it is desirable that it not be moved to another LSP number. This is because moving an adjacency from one LSP to another can cause temporary loss of connectivity to that system. This can occur if the new version of the LSP which orginally contained information about the adjacency (which now doesnot contain information) is propagated before the new version of the other LSP ( which now contains the information about the adjacency). Here my doubt is what is the need for attaching the specific LSP number (not the sequence number) for a particular adjacency. The field "Intermediate system Neighbours" in the LSP PDU contains the neighbour id field which indicates the particular adjacency, the information is pertaining to. Can anybody clear my doubt regarding this. Thanks in advance vamsi.P _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 14:09:08 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24907 for ; Wed, 25 Apr 2001 14:09:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA76694; Wed, 25 Apr 2001 11:44:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA74957 for ; Wed, 25 Apr 2001 04:53:55 -0700 (PDT) Received: from localhost.localdomain ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3PB8kb71145 for ; Wed, 25 Apr 2001 04:08:46 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a2 [192.168.57.22]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id QAA04030 for ; Wed, 25 Apr 2001 16:31:47 +0530 From: "Sivakumar A" Message-Id: <200104251101.QAA04030@localhost.localdomain> To: Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057" MIME-Version: 1.0 Subject: [Isis-wg] Is L1 and L2 address same in an area? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 16:37:36 +0530 --=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057 Content-Type: text/plain; charset=us-ascii Hi all, With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last. What is the L2 area address and how is it different from area address of a particular area. thanks and regards Sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057 Content-Type: text/html; charset=us-ascii

Hi all,

With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last.

What is the L2 area address and how is it different from area address of a particular area.

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_200142531637361717226057-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 14:28:01 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25741 for ; Wed, 25 Apr 2001 14:28:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA76922; Wed, 25 Apr 2001 12:06:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA76910 for ; Wed, 25 Apr 2001 12:05:27 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3PIK5b87914 for ; Wed, 25 Apr 2001 11:20:05 -0700 (PDT) X-JNPR-Received-From: outside Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15089; Wed, 25 Apr 2001 14:24:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03388; Wed, 25 Apr 2001 14:24:07 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Apr 2001 14:24:05 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5531DBF4@vie-msgusr-01.dc.fore.com> From: "Sunkad, Ravindra" To: "'Sivakumar A'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Is L1 and L2 address same in an area? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CDB4.E8D58A90" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 14:24:05 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0CDB4.E8D58A90 Content-Type: text/plain; charset="iso-8859-1" Sivakumar, That is "twelve" not L2. Ravi -----Original Message----- From: Sivakumar A [mailto:sivaa@indiatimes.com] Sent: Wednesday, April 25, 2001 7:08 AM To: isis-wg@juniper.net Subject: [Isis-wg] Is L1 and L2 address same in an area? Hi all, With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last. What is the L2 area address and how is it different from area address of a particular area. thanks and regards Sivakumar _____ Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com ------_=_NextPart_001_01C0CDB4.E8D58A90 Content-Type: text/html; charset="iso-8859-1"
Sivakumar,
 
That is "twelve" not L2.
 
Ravi
-----Original Message-----
From: Sivakumar A [mailto:sivaa@indiatimes.com]
Sent: Wednesday, April 25, 2001 7:08 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Is L1 and L2 address same in an area?

Hi all,

With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned that Area Address option shall be present only in an LSP with LSP number zero. If there are more area addreeses than will fit in a single instance of the Area Addresses option field, then the IS shall place L2 area addresses in each instance of the field except the last.

What is the L2 area address and how is it different from area address of a particular area.

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
------_=_NextPart_001_01C0CDB4.E8D58A90-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 14:33:56 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26064 for ; Wed, 25 Apr 2001 14:33:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA76979; Wed, 25 Apr 2001 12:12:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA76967 for ; Wed, 25 Apr 2001 12:11:49 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3PIQcb88355 for ; Wed, 25 Apr 2001 11:26:38 -0700 (PDT) X-JNPR-Received-From: outside Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id LAA26168; Wed, 25 Apr 2001 11:30:38 -0700 (PDT) From: Mike Truskowski Message-Id: <200104251830.LAA26168@diablo.cisco.com> Subject: RE: [Isis-wg] Is L1 and L2 address same in an area? To: Ravindra.Sunkad@marconi.com (Sunkad, Ravindra) Cc: sivaa@indiatimes.com, isis-wg@juniper.net In-Reply-To: <39469E08BD83D411A3D900204840EC5531DBF4@vie-msgusr-01.dc.fore.com>; from "Sunkad, Ravindra" at Apr 25, 101 11:28 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 11:30:38 PDT Looked like L2 to me also... mwt > > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C0CDB4.E8D58A90 > Content-Type: text/plain; > charset="iso-8859-1" > > Sivakumar, > > That is "twelve" not L2. > > Ravi > > -----Original Message----- > From: Sivakumar A [mailto:sivaa@indiatimes.com] > Sent: Wednesday, April 25, 2001 7:08 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Is L1 and L2 address same in an area? > > > > Hi all, > > With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned > that Area Address option shall be present only in an LSP with LSP number > zero. If there are more area addreeses than will fit in a single instance of > the Area Addresses option field, then the IS shall place L2 area addresses > in each instance of the field except the last. > > What is the L2 area address and how is it different from area address of a > particular area. > > thanks and regards > > Sivakumar > > _____ > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > > > ------_=_NextPart_001_01C0CDB4.E8D58A90 > Content-Type: text/html; > charset="iso-8859-1" > > > > > > > > >
class=643502018-25042001>Sivakumar,
>
class=643502018-25042001> 
>
That > is "twelve" not L2.
>
class=643502018-25042001> 
>
class=643502018-25042001>Ravi
>
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"> >
size=2>-----Original Message-----
From: Sivakumar A > [mailto:sivaa@indiatimes.com]
Sent: Wednesday, April 25, 2001 7:08 > AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Is L1 and L2 > address same in an area?

>

Hi all,

>

With reference to ISO/IEC 10589:1992 (E) clause 7.3.4.3, it is mentioned > that Area Address option shall be present only in an LSP with LSP number zero. > If there are more area addreeses than will fit in a single instance of the > Area Addresses option field, then the IS shall place L2 area addresses in each > instance of the field except the last.

>

What is the L2 area address and how is it different from area address of a > particular area.

>

thanks and regards

>

Sivakumar

>
> Get Your Private, Free E-mail from Indiatimes at href="http://email.indiatimes.com">http://email.indiatimes.com >
> > ------_=_NextPart_001_01C0CDB4.E8D58A90-- > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 14:36:44 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26224 for ; Wed, 25 Apr 2001 14:36:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA77047; Wed, 25 Apr 2001 12:16:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA77030 for ; Wed, 25 Apr 2001 12:15:55 -0700 (PDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3PIUib88629 for ; Wed, 25 Apr 2001 11:30:44 -0700 (PDT) X-JNPR-Received-From: outside Received: from MBARTELL-W2K.cisco.com (dhcp-161-44-19-46.cisco.com [161.44.19.46]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA14433; Wed, 25 Apr 2001 11:34:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20010425132608.031c9ef0@ce-nfs-1.cisco.com> X-Sender: mbartell@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Micah Bartell Subject: Re: [Isis-wg] Help needed Cc: In-Reply-To: <000b01c0cd78$68545220$1c06140a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 13:34:35 -0500 If for instance you have LSPA-FRAG3 that contains adjacency Z. A whole bunch of circuits are restored, and the LSPA-FRAG3 contains these new adjacencies and adjacency Z gets moved to LSPA-FRAG4. When LSPA-FRAG3 is flooded, other IS's will receive this and see that adjacency Z is no longer there. So they remove it for their SPF. However, shortly after, LSPA-FRAG4 would arrive with adjacency Z and it would be restored. This could cause the temporary loss of connectivity. When a link goes down, you don't repack everything as densely as possible, the recommendation is that the number of LSPs generated be within 10% of the optimal number of LSPs if they were densely packed. When new adjacencies come up, you add them into the lowest LSP with available space, which will optimize the number of LSPs vs amount of information being sent. /mpb Full Quote of 7.3.4.4 & Note and Footnote: 7.3.4.4 Once a particular adjacency has been assigned to a particular LSP Number, it is desirable that it not be moved to another LSP Number. This is because moving an adjacency from one LSP to another can cause temporary loss of connectivity to that system. This can occur if the new version of the LSP which originally contained information about the adjacency (which now does not contain that information) is propagated before the new version of the other LSP (which now contains the information about the adjacency). NOTE 25 An implementation is recommended to ensure that the number of LSPs generated for a particular system is within approximately 10% of the optimal number which would be required if all LSPs were densely packed with neighbour options. Where possible this should be accomplished by re-using space in LSPs with a lower LSP Number for new adjacencies. If it is necessary to move an adjacency from one LSP to another, the SRMflags (see 7.3.15) for the two new LSPs shall be set as an atomic action.1) 1) If the two SRMflags are not set atomically, a race condition will exist in which one of the two LSPs may be propagated quickly, while the other waits for an entire propagation cycle. If this occurs, adjacencies will be falsely eliminated from the topology and routes may become unstable for periods of time potentially as large as maximumLSPGenerationInterval. At 16:40 04/25/2001 +0530, Vamsi K wrote: >Hi , > In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit >confusing. Here i am quoting the exact words. > > >Once a particular adjacency has been assigned to a particular LSP number, it >is desirable that it not be moved to another LSP number. >This is because moving an adjacency from one LSP to another can cause >temporary loss of connectivity to that system. This can occur if the >new version of the LSP which orginally contained information about the >adjacency (which now doesnot contain information) is propagated before the >new version of the other LSP ( which now contains the information about the >adjacency). > > > > > >Here my doubt is what is the need for attaching the specific LSP number >(not the sequence number) for a particular adjacency. The field >"Intermediate system Neighbours" in the LSP PDU contains the neighbour id >field which indicates the particular adjacency, the information is >pertaining to. > > >Can anybody clear my doubt regarding this. > > >Thanks in advance >vamsi.P > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Apr 25 17:34:13 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01867 for ; Wed, 25 Apr 2001 17:34:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA78007; Wed, 25 Apr 2001 15:12:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA77995 for ; Wed, 25 Apr 2001 15:11:29 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3PLQGb97421 for ; Wed, 25 Apr 2001 14:26:16 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA26175; Wed, 25 Apr 2001 17:29:16 -0400 (EDT) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-114.cisco.com [64.102.83.114]) by dingdong.cisco.com (Mirapoint) with ESMTP id AEK24723; Wed, 25 Apr 2001 17:30:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20010425143803.049d0f00@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: Jeff Learman Subject: Re: [Isis-wg] Help needed Cc: In-Reply-To: <000b01c0cd78$68545220$1c06140a@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 25 Apr 2001 14:58:58 -0400 Vamsi, >Here my doubt is what is the need for attaching the specific LSP number >(not the sequence number) for a particular adjacency. For example, let's say adjacency A is currently in LSP segment 2, and is moved to LSP segement 3. Both LSP segments' (independent) sequence numbers get incremented, and both segments get transmitted. Now, if segment 3 gets dropped due to noise on an Ethernet, segment 2 gets flooded first. All the routers that get segment 2 and not segment 3 will assume that there is no adjacency A. Note that this could also happen if the segments simply arrive in the obvious order (2 first, then 3), if the receiving implementation has a hold-down timer on running SPF. If it weren't for the "don't move" rule, we wouldn't be able to have hold-down timers on running SPF, which can be useful especially in embedded systems like SONET NEs, where routing is not the system's principal concern. Regards, Jeff At 07:10 AM 4/25/2001, Vamsi K wrote: >Hi , > In the ISO/IEC 10589: 1992(E) document, the section 7.3.4.4 is a bit >confusing. Here i am quoting the exact words. > > >Once a particular adjacency has been assigned to a particular LSP number, it >is desirable that it not be moved to another LSP number. >This is because moving an adjacency from one LSP to another can cause >temporary loss of connectivity to that system. This can occur if the >new version of the LSP which orginally contained information about the >adjacency (which now doesnot contain information) is propagated before the >new version of the other LSP ( which now contains the information about the >adjacency). > > > > > >Here my doubt is what is the need for attaching the specific LSP number >(not the sequence number) for a particular adjacency. The field >"Intermediate system Neighbours" in the LSP PDU contains the neighbour id >field which indicates the particular adjacency, the information is >pertaining to. > > >Can anybody clear my doubt regarding this. > > >Thanks in advance >vamsi.P > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 07:08:39 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04829 for ; Mon, 30 Apr 2001 07:08:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA05745; Mon, 30 Apr 2001 04:47:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA05733 for ; Mon, 30 Apr 2001 04:46:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3UB0ob23705 for ; Mon, 30 Apr 2001 04:00:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04362; Mon, 30 Apr 2001 07:05:05 -0400 (EDT) Message-Id: <200104301105.HAA04362@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Apr 2001 07:05:05 -0400 --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-04.txt Pages : 60 Date : 27-Apr-01 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-04.txt 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-04.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-04.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: <20010427152439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010427152439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 14:29:16 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21548 for ; Mon, 30 Apr 2001 14:29:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA07497; Mon, 30 Apr 2001 12:08:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA79804 for ; Wed, 25 Apr 2001 22:28:07 -0700 (PDT) Received: from localhost.localdomain ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3Q4gnb11590 for ; Wed, 25 Apr 2001 21:42:50 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a3 [192.168.57.23]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id KAA19974 for ; Thu, 26 Apr 2001 10:04:29 +0530 From: "Sivakumar A" Message-Id: <200104260434.KAA19974@localhost.localdomain> To: Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428" MIME-Version: 1.0 Subject: [Isis-wg] downstream paths? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 26 Apr 2001 09:57:39 +0530 --=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428 Content-Type: text/plain; charset=us-ascii Hi all, a)What is downsteam path? b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E) If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this?? thanks and regards Sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428 Content-Type: text/html; charset=us-ascii

Hi all,

a)What is downsteam path?

b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E)

If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this??

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_20014264957392008532428-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 14:31:14 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21629 for ; Mon, 30 Apr 2001 14:31:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA07522; Mon, 30 Apr 2001 12:10:38 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA90900 for ; Fri, 27 Apr 2001 22:24:29 -0700 (PDT) Received: from localhost.localdomain ([203.199.93.15]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3S4cob94881 for ; Fri, 27 Apr 2001 21:38:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from 192.168.57.15 (a3 [192.168.57.23]) by localhost.localdomain (8.9.3/8.9.3) with SMTP id KAA11696 for ; Sat, 28 Apr 2001 10:01:15 +0530 From: "Sivakumar A" Message-Id: <200104280431.KAA11696@localhost.localdomain> To: Reply-To: "Sivakumar A" X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205" MIME-Version: 1.0 Subject: [Isis-wg] downstream path? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sat, 28 Apr 2001 09:54:23 +0530 --=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205 Content-Type: text/plain; charset=us-ascii Hi, a)What is downsteam path? b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E) If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this?? thanks and regards Sivakumar Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205 Content-Type: text/html; charset=us-ascii

Hi,

a)What is downsteam path?

b) In clause 7.2.6.4 of ISO/IEC 10589 : 1992 (E)

If an IS is a L1 intermediate system which supports all four metrics, and additionally computes downstream paths, it would execute the algorith 4 * (number of neighbours +1) times. Can any one clarify this??

thanks and regards

Sivakumar

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com --=_MAILER_ATTACH_BOUNDARY1_2001428695423126107205-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 14:42:26 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21910 for ; Mon, 30 Apr 2001 14:42:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA07644; Mon, 30 Apr 2001 12:21:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA07632 for ; Mon, 30 Apr 2001 12:20:53 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3UIYpb40664 for ; Mon, 30 Apr 2001 11:34:51 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: From: Jeff Parker To: "'Sivakumar A'" , isis-wg@juniper.net Subject: RE: [Isis-wg] downstream paths? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D1A4.D190E6B0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Apr 2001 14:38:58 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D1A4.D190E6B0 Content-Type: text/plain; charset="iso-8859-1" > a)What is downsteam path? Something closer to the "ocean" - a nearby L2 router with a better sense of direction. Take a look at section 7.2.6.2 7.2.6.2 A system executes the SPF algorithm to find a set of legal paths to a destination system in the routeing domain. The set may consist of a) a single path of minimum metric sum: these are termed minimum cost paths; b) a set of paths of equal minimum metric sum: these are termed equal minimum cost paths; or c) a set of paths which will get a PDU closer to its destination than the local system: these are called downstream paths. - jeff parker - axiowave networks - A child of five could understand this. Fetch me a child of five. ------_=_NextPart_001_01C0D1A4.D190E6B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] downstream paths?

> a)What is downsteam path?

Something closer to the "ocean" - a nearby = L2 router with a better
sense of direction.  Take a look at section = 7.2.6.2

7.2.6.2 A system executes the SPF algorithm to find a = set of legal
paths to a destination system in the routeing = domain. The set may consist of

a)      a single path of = minimum metric sum: these are termed minimum cost paths;

b)      a set of paths of = equal minimum metric sum: these are termed equal minimum cost paths; = or

c)      a set of paths which = will get a PDU closer to its destination than
        the local = system: these are called downstream paths.

- jeff parker
- axiowave networks
- A child of five could understand this.  Fetch = me a child of five.

------_=_NextPart_001_01C0D1A4.D190E6B0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 18:10:49 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27115 for ; Mon, 30 Apr 2001 18:10:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA08623; Mon, 30 Apr 2001 15:50:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA08008 for ; Mon, 30 Apr 2001 13:20:30 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3UJYRb43499 for ; Mon, 30 Apr 2001 12:34:27 -0700 (PDT) X-JNPR-Received-From: outside Received: from bcn.East.Sun.COM ([129.148.75.4]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29609; Mon, 30 Apr 2001 12:38:40 -0700 (PDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA11826; Mon, 30 Apr 2001 15:38:39 -0400 (EDT) Message-Id: <200104301938.PAA11826@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] downstream paths? To: isis-wg@juniper.net, sivaa@indiatimes.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MxACpYXkll60gdI1G7QT3w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Apr 2001 15:38:38 -0400 (EDT) OK. Reading Jeff Parker's reply I now understand, but perhaps it's worth having a 2nd person explain it. I didn't remember this from IS-IS at all (I assume it got put in by ISO and wasn't in the original DECnet Phase V routing algorithm), but apparently (based on the section quoted by Jeff) you're allowed to forward a packet destined to D to neighbor N even if N isn't on a minimal path from you to D, but instead neighbor N is closer to D than you are. In other words, you have a path through neighbor N1 to D that is of cost 50, and that's your best path. Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. If you forward through N your path will be 53, clearly worse than your path through N1, but since N is closer to D than you (N is 48 away, you're 50 away), you're allowed to forward to N. A neighbor closer to D than you is "downstream". So N (as well as N1) would be downstream. The normal Dijkstra calculation wouldn't tell you all neighbors closer to D than you. The only way to get this is to calculate Dijkstra from the point of view of each neighbor. That's why, if you have k neighbors, you'd have to calculate Dijkstra from your own point of view, plus from the point of view of each neighbor (to find out, for each destination, which of your neighbors is closer to the destination than you are). And with multiple metrics, you'd have to multiply the number of Dijkstra calculations by the number of metrics (I never did like the multiple metric thing, especially the way ISO specified it...that you leave out links that don't advertise that metric so you're calculating an "optimal" path based on a subset of the links!). So that explains why the section you quoted says if there are 4 metrics, and you want to "calculate downstream paths) i.e., find out which neighbors are closer than you for each destination), you "would execute the algorithm 4 * (number of neighbours +1) times" I always thought the multiple metrics were not worth the extra calculation and configuration (and were actually quite dangerous given how ISO specified it since it's very nonintuitive why you might get really horrible routes if you use any metric that isn't universally supported on every link). I'd think this "calculating downstream paths" would also not be worth the extra computation and storage. Does any IS-IS implementation bother with this "downstream paths" thing? Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 18:59:48 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27875 for ; Mon, 30 Apr 2001 18:59:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA08789; Mon, 30 Apr 2001 16:14:06 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA08777 for ; Mon, 30 Apr 2001 16:13:45 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f3UMRbb51153 for ; Mon, 30 Apr 2001 15:27:37 -0700 (PDT) X-JNPR-Received-From: outside Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f3UMUOW07182; Mon, 30 Apr 2001 18:30:24 -0400 (EDT) Received: from JLEARMAN-W2K.cisco.com (dhcp-64-102-83-115.cisco.com [64.102.83.115]) by dingdong.cisco.com (Mirapoint) with ESMTP id AEU09666; Mon, 30 Apr 2001 18:31:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20010430182119.019c0548@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Radia Perlman From: Jeff Learman Subject: Re: [Isis-wg] downstream paths? Cc: isis-wg@juniper.net, sivaa@indiatimes.com In-Reply-To: <200104301938.PAA11826@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Apr 2001 18:31:26 -0400 Radia, Thanks for the clarification. Your interpretation matches the only interpretation I have ever been able to glean from the spec. I am at a loss for why anyone would bother to do more work to get less optimal routes, other than to be able to do load balancing in more circumstances. (Whether that kind of LB would actually be a good idea is another question.) I can't answer whether this is implemented in any integrated IS-IS implementations, but I will be surprised if it is. If it was, it could not be used in conjunction with reverse path filtering, of course. Regards, Jeff At 03:38 PM 4/30/2001, Radia Perlman - Boston Center for Networking wrote: >OK. Reading Jeff Parker's reply I now understand, but perhaps >it's worth having a 2nd person explain it. > >I didn't remember this from IS-IS at all (I assume >it got put in by ISO and wasn't in the original DECnet >Phase V routing algorithm), but apparently (based on >the section quoted by Jeff) you're >allowed to forward a packet destined to D to neighbor N even if >N isn't on a minimal path from you to D, but instead neighbor N >is closer to D than you are. In other words, you have a path through >neighbor N1 to D that is of cost 50, and that's your best path. >Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. >If you forward through N your path will be 53, clearly worse than >your path through N1, but since N is closer to D than you (N is >48 away, you're 50 away), you're allowed to forward to N. > >A neighbor closer to D than you is "downstream". So N (as well as N1) >would be downstream. > >The normal Dijkstra calculation wouldn't tell you all neighbors closer >to D than you. The only way to get this is to calculate Dijkstra >from the point of view of each neighbor. That's why, if you have k >neighbors, you'd have to calculate Dijkstra from your own point of >view, plus from the point of view of each neighbor (to find out, for >each destination, which of your neighbors is closer to the destination >than you are). > >And with multiple metrics, you'd have to multiply the number of Dijkstra >calculations by the number of metrics (I never did like the multiple >metric thing, especially the way ISO specified it...that you leave out >links that don't advertise that metric so you're calculating an "optimal" >path based on a subset of the links!). > >So that explains why the section you quoted says if there are 4 >metrics, and you want to "calculate downstream paths) i.e., find out >which neighbors are closer than you for each destination), you >"would execute the algorithm 4 * (number of neighbours +1) times" > >I always thought the multiple metrics were not worth the extra >calculation and configuration (and were actually quite dangerous >given how ISO specified it since it's very nonintuitive why you >might get really horrible routes if you use any metric that isn't >universally supported on every link). I'd think this "calculating >downstream paths" would also not be worth the extra computation >and storage. Does any IS-IS implementation bother with this >"downstream paths" thing? > >Radia > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Apr 30 20:56:59 2001 Received: from external.juniper.net ([207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29413 for ; Mon, 30 Apr 2001 20:56:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA09464; Mon, 30 Apr 2001 18:36:05 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA09452 for ; Mon, 30 Apr 2001 18:35:48 -0700 (PDT) Received: from mail.krioukov.net (cj114416-a.reston1.va.home.com [24.15.191.36]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f410nhb56402 for ; Mon, 30 Apr 2001 17:49:43 -0700 (PDT) X-JNPR-Received-From: outside Received: from DIMA1 ([47.184.55.188]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id UAA32335; Mon, 30 Apr 2001 20:53:55 -0400 From: "Dmitri Krioukov" To: "Radia Perlman - Boston Center for Networking" , Cc: Subject: RE: [Isis-wg] downstream paths? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200104301938.PAA11826@bcn.East.Sun.COM> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Apr 2001 20:53:56 -0400 Content-Transfer-Encoding: 7bit It's worth to note that any non-ECMP proposal (ISIS-OMP, for example) would require this. -- dima. > -----Original Message----- > From: isis-wg-admin@spider.juniper.net > [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Radia Perlman - > Boston Center for Networking > Sent: Monday, April 30, 2001 3:39 PM > To: isis-wg@juniper.net; sivaa@indiatimes.com > Subject: Re: [Isis-wg] downstream paths? > > > OK. Reading Jeff Parker's reply I now understand, but perhaps > it's worth having a 2nd person explain it. > > I didn't remember this from IS-IS at all (I assume > it got put in by ISO and wasn't in the original DECnet > Phase V routing algorithm), but apparently (based on > the section quoted by Jeff) you're > allowed to forward a packet destined to D to neighbor N even if > N isn't on a minimal path from you to D, but instead neighbor N > is closer to D than you are. In other words, you have a path through > neighbor N1 to D that is of cost 50, and that's your best path. > Your cost to neighbor N is, say, 5. N can get to D at a cost of 48. > If you forward through N your path will be 53, clearly worse than > your path through N1, but since N is closer to D than you (N is > 48 away, you're 50 away), you're allowed to forward to N. > > A neighbor closer to D than you is "downstream". So N (as well as N1) > would be downstream. > > The normal Dijkstra calculation wouldn't tell you all neighbors closer > to D than you. The only way to get this is to calculate Dijkstra > from the point of view of each neighbor. That's why, if you have k > neighbors, you'd have to calculate Dijkstra from your own point of > view, plus from the point of view of each neighbor (to find out, for > each destination, which of your neighbors is closer to the destination > than you are). > > And with multiple metrics, you'd have to multiply the number of Dijkstra > calculations by the number of metrics (I never did like the multiple > metric thing, especially the way ISO specified it...that you leave out > links that don't advertise that metric so you're calculating an "optimal" > path based on a subset of the links!). > > So that explains why the section you quoted says if there are 4 > metrics, and you want to "calculate downstream paths) i.e., find out > which neighbors are closer than you for each destination), you > "would execute the algorithm 4 * (number of neighbours +1) times" > > I always thought the multiple metrics were not worth the extra > calculation and configuration (and were actually quite dangerous > given how ISO specified it since it's very nonintuitive why you > might get really horrible routes if you use any metric that isn't > universally supported on every link). I'd think this "calculating > downstream paths" would also not be worth the extra computation > and storage. Does any IS-IS implementation bother with this > "downstream paths" thing? > > Radia > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg