From isis-wg-admin@spider.juniper.net Wed May 1 07:56:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23383 for ; Wed, 1 May 2002 07:56:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41Bd0t69314; Wed, 1 May 2002 04:39:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41Bc9t69302 for ; Wed, 1 May 2002 04:38:09 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g41BqEn27893 for ; Wed, 1 May 2002 04:52:14 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 1 May 2002 04:24:47 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20170; Wed, 1 May 2002 07:25:50 -0400 (EDT) Message-Id: <200205011125.HAA20170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: isis-wg@juniper.net, ospf@discuss.microsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 01 May 2002 11:24:47.0250 (UTC) FILETIME=[CCDF4F20:01C1F102] Subject: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 01 May 2002 07:25:49 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic restoration in link state protocols using neighbor's shortest path Author(s) : S. Kini, Y. Yang Filename : draft-kini-traf-restore-nsp-00.txt Pages : 8 Date : 30-Apr-02 Traffic recovery time when a link (or node) fails is typically in the order of tens of seconds for a link state IGP. The recovery time is governed by factors like the time it takes to detect an adjacency down, the time taken to propagate link state database changes throughout the network and the time it takes to run the SPF algorithm and install the new routes in the FIB. Till this entire process is complete, traffic in the network can be blackholed. This draft describes a technique to reduce the time for which traffic is blackholed by routing the traffic through a neighbor's shortest path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-kini-traf-restore-nsp-00.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-kini-traf-restore-nsp-00.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: <20020430135733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kini-traf-restore-nsp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020430135733.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 1 08:38:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24661 for ; Wed, 1 May 2002 08:38:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41CLht69529; Wed, 1 May 2002 05:21:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41CGAt69500 for ; Wed, 1 May 2002 05:16:10 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g41CUFn28438 for ; Wed, 1 May 2002 05:30:15 -0700 (PDT) X-JNPR-Received-From: outside Received: from cisco.com ([144.254.98.48]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 1 May 2002 05:22:55 -0700 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp110.cisco.com [10.50.0.109]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA01372 for ; Wed, 1 May 2002 13:24:01 +0100 (BST) Message-Id: <4.3.2.7.2.20020501131954.0426bb38@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@juniper.net From: mike shand Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt In-Reply-To: <200205011125.HAA20170@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 May 2002 12:22:55.0593 (UTC) FILETIME=[EC163590:01C1F10A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 01 May 2002 13:22:50 +0100 How does this differ from "downstream routes" as described in clause 7.2.6.2 (c) of ISO/IEC 10589? Mike At 07:25 01/05/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Traffic restoration in link state protocols using > neighbor's shortest path > Author(s) : S. Kini, Y. Yang > Filename : draft-kini-traf-restore-nsp-00.txt > Pages : 8 > Date : 30-Apr-02 > >Traffic recovery time when a link (or node) fails is typically in the >order of tens of seconds for a link state IGP. The recovery time is >governed by factors like the time it takes to detect an adjacency >down, the time taken to propagate link state database changes >throughout the network and the time it takes to run the SPF algorithm >and install the new routes in the FIB. Till this entire process is >complete, traffic in the network can be blackholed. This draft >describes a technique to reduce the time for which traffic is >blackholed by routing the traffic through a neighbor's shortest path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-kini-traf-restore-nsp-00.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-kini-traf-restore-nsp-00.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. >Content-Type: text/plain >Content-ID: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 1 15:55:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24870 for ; Wed, 1 May 2002 15:55:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41Jc1t71681; Wed, 1 May 2002 12:38:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41JbTt71669 for ; Wed, 1 May 2002 12:37:29 -0700 (PDT) (envelope-from skini@mahinetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g41JpbX18433 for ; Wed, 1 May 2002 12:51:37 -0700 (PDT) X-JNPR-Received-From: outside Received: from interceptor.mahinetworks.com ([216.174.224.194]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 1 May 2002 12:44:21 -0700 Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Wed, 01 May 2002 12:50:37 -0700 Received: by main.mahinetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 May 2002 12:45:27 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C903676A54@main.mahinetworks.com> From: Sriganesh Kini To: isis-wg@juniper.net Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 May 2002 19:44:21.0093 (UTC) FILETIME=[96ACC950:01C1F148] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 1 May 2002 12:45:25 -0700 At A for destination B, node C is not downstream. But there is NSP from A to B thru C. +---+ | C | +---+ 5 / \ 51 / \ +---+ +---+ | A |----------| B | +---+ 50 +---+ === Sriganesh Kini 707 283 1257 -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, May 01, 2002 5:23 AM To: isis-wg@juniper.net Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt How does this differ from "downstream routes" as described in clause 7.2.6.2 (c) of ISO/IEC 10589? Mike At 07:25 01/05/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Traffic restoration in link state protocols using > neighbor's shortest path > Author(s) : S. Kini, Y. Yang > Filename : draft-kini-traf-restore-nsp-00.txt > Pages : 8 > Date : 30-Apr-02 > >Traffic recovery time when a link (or node) fails is typically in the >order of tens of seconds for a link state IGP. The recovery time is >governed by factors like the time it takes to detect an adjacency >down, the time taken to propagate link state database changes >throughout the network and the time it takes to run the SPF algorithm >and install the new routes in the FIB. Till this entire process is >complete, traffic in the network can be blackholed. This draft >describes a technique to reduce the time for which traffic is >blackholed by routing the traffic through a neighbor's shortest path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-kini-traf-restore-nsp-00.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-kini-traf-restore-nsp-00.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. >Content-Type: text/plain >Content-ID: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 1 18:57:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16112 for ; Wed, 1 May 2002 18:57:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41Meht72581; Wed, 1 May 2002 15:40:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41Makt72555 for ; Wed, 1 May 2002 15:36:46 -0700 (PDT) (envelope-from azalani@opnet.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g41MosX22701 for ; Wed, 1 May 2002 15:50:54 -0700 (PDT) X-JNPR-Received-From: outside Received: from smtp2.opnet.com ([12.145.55.7]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 1 May 2002 15:49:47 -0700 Received: from wtn10068 (wtn10068.opnet.com) by smtp2.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Wed, 1 May 2002 18:50:50 -0400 Message-Id: <4.2.1.20020501182236.00b73e60@mail.opnet.com> X-Sender: azalani@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 To: isis-wg@juniper.net From: Ashish Zalani Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 May 2002 22:49:47.0312 (UTC) FILETIME=[7E6B1300:01C1F162] Subject: [Isis-wg] Cisco IS-IS Area == ISO10589 IS-IS Area ??? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 01 May 2002 18:50:49 -0400 I suppose this is not the best place to ask a question about something that relates to a specific vendor's terminology, but I was hoping someone on this mailing list might be able to enlighten me on this issue: I am a bit confused about what Cisco calls an "Area" w.r.t. IS-IS. From the description of it, a "Cisco Area" seems to be what I would call an "IS-IS Routing domain" (or in terms of the Multi Topology draft, an MT). I understand from the Cisco documentation that one can configure no more than 30 "areas" on a (Cisco) router. But the Cisco documentation also says that you cannot configure more than 3 NETs on a router. I should have thought that I should be allowed to configure 3 NETs per "area" per router. Furthermore, it says: "If you are configuring multiarea IS-IS, the area ID must be unique, but the system ID portion of the NET must be the same for all IS-IS routing process instances". I don't understand: - why the area ID portion of the NET has to be unique between NETs for different "areas". - how I could configure 30 "areas" with just 3 NETs and unique area IDs. Can anyone kindly explain this to me? Regards, -Ashish. Ashish Zalani Modeling Engineer OPNET Technologies, Inc. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 1 19:14:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18322 for ; Wed, 1 May 2002 19:14:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41MwPt72678; Wed, 1 May 2002 15:58:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g41Mogt72638 for ; Wed, 1 May 2002 15:50:42 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g41N4on43969 for ; Wed, 1 May 2002 16:04:50 -0700 (PDT) X-JNPR-Received-From: outside Received: from strange-brew.cisco.com ([144.254.15.119]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 1 May 2002 16:02:10 -0700 Received: from there (sjc-vpn3-422.cisco.com [10.21.65.166]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id BAA17287; Thu, 2 May 2002 01:03:13 +0200 (MET DST) Message-Id: <200205012303.BAA17287@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: Ashish Zalani , isis-wg@juniper.net Subject: Re: [Isis-wg] Cisco IS-IS Area == ISO10589 IS-IS Area ??? X-Mailer: KMail [version 1.3.1] References: <4.2.1.20020501182236.00b73e60@mail.opnet.com> In-Reply-To: <4.2.1.20020501182236.00b73e60@mail.opnet.com> MIME-Version: 1.0 X-OriginalArrivalTime: 01 May 2002 23:02:10.0265 (UTC) FILETIME=[3940B490:01C1F164] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g41Mogt72639 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 2 May 2002 01:03:04 +0200 Content-Transfer-Encoding: 8bit this is cisco-configuration specific and will take this offline. s. On Thursday 02 May 2002 00:50, Ashish Zalani wrote: > I suppose this is not the best place to ask a question about something that > relates to a specific vendor's terminology, but I was hoping someone on > this mailing list might be able to enlighten me on this issue: > > I am a bit confused about what Cisco calls an "Area" w.r.t. IS-IS. > From the description of it, a "Cisco Area" seems to be what I would call > an "IS-IS Routing domain" (or in terms of the Multi Topology draft, an MT). > > I understand from the Cisco documentation that one can configure no more > than 30 "areas" on a (Cisco) router. But the Cisco documentation also says > that you cannot configure more than 3 NETs on a router. I should have > thought that I should be allowed to configure 3 NETs per "area" per router. > Furthermore, it says: "If you are configuring multiarea IS-IS, the area ID > must be unique, but the system ID portion of the NET must be the same for > all IS-IS routing process instances". > > I don't understand: > - why the area ID portion of the NET has to be unique between NETs for > different "areas". > - how I could configure 30 "areas" with just 3 NETs and unique area IDs. > > > Can anyone kindly explain this to me? > > Regards, > -Ashish. > Ashish Zalani > Modeling Engineer > OPNET Technologies, Inc. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 2 04:18:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00395 for ; Thu, 2 May 2002 04:18:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g42811t74970; Thu, 2 May 2002 01:01:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4280Zt74955 for ; Thu, 2 May 2002 01:00:35 -0700 (PDT) (envelope-from truskows@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g428Ejn52476 for ; Thu, 2 May 2002 01:14:46 -0700 (PDT) X-JNPR-Received-From: outside Received: from wells.cisco.com ([171.71.177.223]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 2 May 2002 01:13:38 -0700 Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id BAA02502; Thu, 2 May 2002 01:14:44 -0700 (PDT) From: Mike Truskowski Message-Id: <200205020814.BAA02502@wells.cisco.com> Subject: Re: [Isis-wg] Cisco IS-IS Area == ISO10589 IS-IS Area ??? To: azalani@opnet.com Cc: isis-wg@juniper.net In-Reply-To: <4.2.1.20020501182236.00b73e60@mail.opnet.com> from Ashish Zalani at May "1," 2002 "06:50:49" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 May 2002 08:13:38.0312 (UTC) FILETIME=[43440080:01C1F1B1] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 2 May 2002 01:14:44 -0700 (PDT) Content-Transfer-Encoding: 7bit Since you are asking about a Cisco solution why ask this group. Ask your Cisco support person. Mike > I suppose this is not the best place to ask a question about something that > relates to a specific vendor's terminology, but I was hoping someone on > this mailing list might be able to enlighten me on this issue: > > I am a bit confused about what Cisco calls an "Area" w.r.t. IS-IS. > From the description of it, a "Cisco Area" seems to be what I would call > an "IS-IS Routing domain" (or in terms of the Multi Topology draft, an MT). > > I understand from the Cisco documentation that one can configure no more > than 30 "areas" on a (Cisco) router. But the Cisco documentation also says > that you cannot configure more than 3 NETs on a router. I should have > thought that I should be allowed to configure 3 NETs per "area" per router. > Furthermore, it says: "If you are configuring multiarea IS-IS, the area ID > must be unique, but the system ID portion of the NET must be the same for > all IS-IS routing process instances". > > I don't understand: > - why the area ID portion of the NET has to be unique between NETs for > different "areas". > - how I could configure 30 "areas" with just 3 NETs and unique area IDs. > > > Can anyone kindly explain this to me? > > Regards, > -Ashish. > Ashish Zalani > Modeling Engineer > OPNET Technologies, Inc. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 2 11:58:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08890 for ; Thu, 2 May 2002 11:58:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g42Ff0t77341; Thu, 2 May 2002 08:41:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g42FeRt77329 for ; Thu, 2 May 2002 08:40:27 -0700 (PDT) (envelope-from JRB@dataconnection.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g42FsdX38004 for ; Thu, 2 May 2002 08:54:39 -0700 (PDT) X-JNPR-Received-From: outside Received: from coltrane.dataconnection.com ([192.91.191.4]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 2 May 2002 08:46:44 -0700 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2655.55) id ; Thu, 2 May 2002 16:47:44 +0100 Message-ID: <37701240971DD31193970000F6CCB9F7036D715F@duke.datcon.co.uk> From: Jon Berger To: Sriganesh Kini , isis-wg@juniper.net Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 May 2002 15:46:44.0624 (UTC) FILETIME=[8F920100:01C1F1F0] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 2 May 2002 16:47:38 +0100 But, if the BC cost is 60, don't you have a loop? Jon -----Original Message----- From: Sriganesh Kini [mailto:skini@mahinetworks.com] Sent: 01 May 2002 20:45 To: isis-wg@juniper.net Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt At A for destination B, node C is not downstream. But there is NSP from A to B thru C. +---+ | C | +---+ 5 / \ 51 / \ +---+ +---+ | A |----------| B | +---+ 50 +---+ === Sriganesh Kini 707 283 1257 -----Original Message----- From: mike shand [mailto:mshand@cisco.com] Sent: Wednesday, May 01, 2002 5:23 AM To: isis-wg@juniper.net Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt How does this differ from "downstream routes" as described in clause 7.2.6.2 (c) of ISO/IEC 10589? Mike At 07:25 01/05/2002 -0400, you wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Traffic restoration in link state protocols using > neighbor's shortest path > Author(s) : S. Kini, Y. Yang > Filename : draft-kini-traf-restore-nsp-00.txt > Pages : 8 > Date : 30-Apr-02 > >Traffic recovery time when a link (or node) fails is typically in the >order of tens of seconds for a link state IGP. The recovery time is >governed by factors like the time it takes to detect an adjacency >down, the time taken to propagate link state database changes >throughout the network and the time it takes to run the SPF algorithm >and install the new routes in the FIB. Till this entire process is >complete, traffic in the network can be blackholed. This draft >describes a technique to reduce the time for which traffic is >blackholed by routing the traffic through a neighbor's shortest path. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-kini-traf-restore-nsp-00.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-kini-traf-restore-nsp-00.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. >Content-Type: text/plain >Content-ID: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 2 17:37:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10764 for ; Thu, 2 May 2002 17:37:34 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g42LL1t78816; Thu, 2 May 2002 14:21:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g42LKLt78804 for ; Thu, 2 May 2002 14:20:21 -0700 (PDT) (envelope-from skini@mahinetworks.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g42LYZX46310 for ; Thu, 2 May 2002 14:34:35 -0700 (PDT) X-JNPR-Received-From: outside Received: from interceptor.mahinetworks.com ([216.174.224.194]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 2 May 2002 14:33:27 -0700 Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Thu, 02 May 2002 14:39:41 -0700 Received: by main.mahinetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 14:34:29 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C903676A5C@main.mahinetworks.com> From: Sriganesh Kini To: "'Jon Berger'" , isis-wg@juniper.net Cc: Yibin Yang Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 May 2002 21:33:27.0203 (UTC) FILETIME=[FEDFA730:01C1F220] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 2 May 2002 14:34:29 -0700 If the cost of BC is 60 then there is no NSP from A to B through C. === Sriganesh Kini 707 283 1257 > -----Original Message----- > From: Jon Berger [mailto:JRB@dataconnection.com] > Sent: Thursday, May 02, 2002 8:48 AM > To: Sriganesh Kini; isis-wg@juniper.net > Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt > > > But, if the BC cost is 60, don't you have a loop? > > Jon > > > -----Original Message----- > From: Sriganesh Kini [mailto:skini@mahinetworks.com] > Sent: 01 May 2002 20:45 > To: isis-wg@juniper.net > Subject: RE: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt > > > At A for destination B, node C is not downstream. But there > is NSP from A to > B thru C. > > > +---+ > | C | > +---+ > 5 / \ 51 > / \ > +---+ +---+ > | A |----------| B | > +---+ 50 +---+ > > > === > Sriganesh Kini > > 707 283 1257 > > > -----Original Message----- > From: mike shand [mailto:mshand@cisco.com] > Sent: Wednesday, May 01, 2002 5:23 AM > To: isis-wg@juniper.net > Subject: Re: [Isis-wg] I-D ACTION:draft-kini-traf-restore-nsp-00.txt > > > How does this differ from "downstream routes" as described in clause > 7.2.6.2 (c) of ISO/IEC 10589? > > Mike > > At 07:25 01/05/2002 -0400, you wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Traffic restoration in link state > protocols > using > > neighbor's shortest path > > Author(s) : S. Kini, Y. Yang > > Filename : draft-kini-traf-restore-nsp-00.txt > > Pages : 8 > > Date : 30-Apr-02 > > > >Traffic recovery time when a link (or node) fails is typically in the > >order of tens of seconds for a link state IGP. The recovery time is > >governed by factors like the time it takes to detect an adjacency > >down, the time taken to propagate link state database changes > >throughout the network and the time it takes to run the SPF algorithm > >and install the new routes in the FIB. Till this entire process is > >complete, traffic in the network can be blackholed. This draft > >describes a technique to reduce the time for which traffic is > >blackholed by routing the traffic through a neighbor's shortest path. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-kini-traf-restore-n sp-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-kini-traf-restore-nsp-00.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-kini-traf-restore-nsp-00.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. >Content-Type: text/plain >Content-ID: <20020430135733.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kini-traf-restore-nsp-00.txt > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 3 07:31:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09822 for ; Fri, 3 May 2002 07:31:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g43BF0t82949; Fri, 3 May 2002 04:15:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g43BEZt82934 for ; Fri, 3 May 2002 04:14:35 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g43BSrn83039 for ; Fri, 3 May 2002 04:28:53 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Fri, 3 May 2002 04:27:44 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09717; Fri, 3 May 2002 07:28:47 -0400 (EDT) Message-Id: <200205031128.HAA09717@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 X-OriginalArrivalTime: 03 May 2002 11:27:44.0281 (UTC) FILETIME=[8B379890:01C1F295] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-11.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 03 May 2002 07:28:47 -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 : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter et al. Filename : draft-ietf-isis-gmpls-extensions-11.txt Pages : 11 Date : 02-May-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gmpls-extensions-11.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-gmpls-extensions-11.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: <20020502145010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502145010.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 6 10:57:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22218 for ; Mon, 6 May 2002 10:57:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g46Ef5t05576; Mon, 6 May 2002 07:41:05 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g46EeLt05564 for ; Mon, 6 May 2002 07:40:21 -0700 (PDT) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g46Esxn31104 for ; Mon, 6 May 2002 07:54:59 -0700 (PDT) X-JNPR-Received-From: outside Received: from web11208.mail.yahoo.com ([216.136.131.190]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 6 May 2002 07:39:50 -0700 Message-ID: <20020506144057.96209.qmail@web11208.mail.yahoo.com> Received: from [203.196.146.243] by web11208.mail.yahoo.com via HTTP; Mon, 06 May 2002 07:40:57 PDT From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-765142342-1020696057=:92657" X-OriginalArrivalTime: 06 May 2002 14:39:50.0171 (UTC) FILETIME=[E06C16B0:01C1F50B] Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 6 May 2002 07:40:57 -0700 (PDT) --0-765142342-1020696057=:92657 Content-Type: text/plain; charset=us-ascii Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid differentchecksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum isincorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --0-765142342-1020696057=:92657 Content-Type: text/html; charset=us-ascii
Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589,
Checksums in LSP entries in SNP packets are also considered while dealing with
LSP confusion. I have some doubts on that
 

If a system has send a LSP on point to point link and is waiting for an acknowledgement
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has installed
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum is
incorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness --0-765142342-1020696057=:92657-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 6 15:43:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04243 for ; Mon, 6 May 2002 15:43:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g46JQht06960; Mon, 6 May 2002 12:26:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g46JL7t06931 for ; Mon, 6 May 2002 12:21:07 -0700 (PDT) (envelope-from jhargest@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g46JZkn39907 for ; Mon, 6 May 2002 12:35:46 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 6 May 2002 12:30:28 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03768; Mon, 6 May 2002 15:31:32 -0400 (EDT) Message-Id: <200205061931.PAA03768@ietf.org> To: IETF-Announce: ; Cc: isis-wg@juniper.net From: The IESG Reply-to: iesg@ietf.org X-OriginalArrivalTime: 06 May 2002 19:30:28.0671 (UTC) FILETIME=[7A9404F0:01C1F534] Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 06 May 2002 15:31:32 -0400 The IESG has received a request from the IS-IS for IP Internets Working Group to consider Three-Way Handshake for IS-IS Point-to-Point Adjacencies as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 6 17:21:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07353 for ; Mon, 6 May 2002 17:21:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g46L50t07506; Mon, 6 May 2002 14:05:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g46L46t07491 for ; Mon, 6 May 2002 14:04:06 -0700 (PDT) (envelope-from scoya@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g46LIjn42681 for ; Mon, 6 May 2002 14:18:45 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 6 May 2002 14:17:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07270; Mon, 6 May 2002 17:18:37 -0400 (EDT) Message-Id: <200205062118.RAA07270@ietf.org> To: IETF-Announce: ; Cc: isis-wg@juniper.net From: The IESG Reply-to: iesg@ietf.org X-OriginalArrivalTime: 06 May 2002 21:17:34.0015 (UTC) FILETIME=[7061B4F0:01C1F543] Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 06 May 2002 17:18:37 -0400 The IESG has received a request from the IS-IS for IP Internets Working Group to consider Three-Way Handshake for IS-IS Point-to-Point Adjacencies as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 7 02:14:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28299 for ; Tue, 7 May 2002 02:14:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g475v0t09687; Mon, 6 May 2002 22:57:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g475uut09675 for ; Mon, 6 May 2002 22:56:56 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g476BYX21917 for ; Mon, 6 May 2002 23:11:38 -0700 (PDT) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 6 May 2002 22:43:49 -0700 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id WAA26997; Mon, 6 May 2002 22:44:59 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G83G21>; Mon, 6 May 2002 22:44:59 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F9DD@avalon.pluris.com> From: Les Ginsberg To: "'Aravind Ravikumar'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F58A.52F34090" X-OriginalArrivalTime: 07 May 2002 05:43:49.0718 (UTC) FILETIME=[29B62760:01C1F58A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 6 May 2002 22:44:58 -0700 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_01C1F58A.52F34090 Content-Type: text/plain; charset="iso-8859-1" As you say, there are three possibilities: 1.The SNP packet itself is corrupted, Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP. NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB. So we are left with 2 and 3: 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. or 3.Local systems memory got corrupted (or perhaps both...) If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that. If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 7:41 AM To: isis-wg@juniper.net Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid different checksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum is incorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind _____ Do You Yahoo!? Yahoo! Health - your guide to health and wellness ------_=_NextPart_001_01C1F58A.52F34090 Content-Type: text/html; charset="iso-8859-1"
As you say, there are three possibilities:
 
1.The SNP packet itself is corrupted,
 
Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP.
NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB.
 
So we are left with 2 and 3:

2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
or
3.Local systems memory got corrupted
 
(or perhaps both...)
 
If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that.
 
If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly.
 
 
   Les
 
-----Original Message-----
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May 06, 2002 7:41 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589,
Checksums in LSP entries in SNP packets are also considered while dealing with
LSP confusion. I have some doubts on that
 

If a system has send a LSP on point to point link and is waiting for an acknowledgement
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has installed
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum is
incorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
------_=_NextPart_001_01C1F58A.52F34090-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 7 03:18:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29280 for ; Tue, 7 May 2002 03:18:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4771ht10051; Tue, 7 May 2002 00:01:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g476vwt10018 for ; Mon, 6 May 2002 23:57:58 -0700 (PDT) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g477CeX22700 for ; Tue, 7 May 2002 00:12:40 -0700 (PDT) X-JNPR-Received-From: outside Received: from web11207.mail.yahoo.com ([216.136.131.189]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 6 May 2002 23:44:35 -0700 Message-ID: <20020507064547.16634.qmail@web11207.mail.yahoo.com> Received: from [203.196.146.243] by web11207.mail.yahoo.com via HTTP; Mon, 06 May 2002 23:45:47 PDT From: Aravind Ravikumar Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP To: Les Ginsberg , isis-wg@juniper.net In-Reply-To: <17C81AD1F1FED411991E006008F6D1CA01B3F9DD@avalon.pluris.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-909009487-1020753947=:16467" X-OriginalArrivalTime: 07 May 2002 06:44:35.0953 (UTC) FILETIME=[A7097610:01C1F592] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 6 May 2002 23:45:47 -0700 (PDT) --0-909009487-1020753947=:16467 Content-Type: text/plain; charset=us-ascii Hi, Does this mean that if a system detects that its memory is corrupted (corrupted LSP in memory)it should purge the LSP ,causing a purge (area wide if its level1 LSP or domain wide in case of L2 LSP)and the regeneration by the originating system in case of non local LSP and regeneration in caser of local LSP? But the section 7.3.18 on database validation says that if a system detects failure the network entity should be disabled until the failure is corrected and also suggests that in the absence of implementation specific methods to deal with the situation, as a minimum we should take action to delete the databasea and reacquire the entire database Your answer seems to suggest that as an implementation specific way we can try to re-acquire the corrupted LSP by purging it.Are we justified in doing this .Won't it be better if we consider the memory corruption as an indication of more serious problems in our system(Atleast trying to find out whether the problem is transient or persistent) if its persistent problem we will keep on corrupting and purging,if we do like that I think dealing with memory corruption is an implemetation specific issue,but shouldn't it be fail stop-manner as suggested in the ISO 10589? Aravind Les Ginsberg wrote: As you say, there are three possibilities: 1.The SNP packet itself is corrupted, Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP.NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB. So we are left with 2 and 3: 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed.or 3.Local systems memory got corrupted (or perhaps both...) If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that. If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 7:41 AM To: isis-wg@juniper.net Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid differentchecksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum isincorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --------------------------------- Do You Yahoo!? Yahoo! Health - your guide to health and wellness --0-909009487-1020753947=:16467 Content-Type: text/html; charset=us-ascii

 Hi,

Does this mean that if a system detects that its memory is corrupted
(corrupted LSP in memory)it should purge the LSP ,causing a purge
(area wide if its level1 LSP or domain wide in case of L2 LSP)and
the regeneration by the originating system in case of non local LSP
and regeneration in caser of local LSP?


But the section 7.3.18 on database validation says that if a system detects failure
the network entity should be disabled until the failure is corrected and also suggests
that in the absence of implementation specific methods to deal with the situation, as a
minimum we should take action to delete the databasea and reacquire the entire database

Your answer seems to suggest that as an implementation specific way we can try to
re-acquire the corrupted LSP by purging it.Are we justified in doing this .Won't it
be better if we consider the memory corruption as an indication
of more serious problems in our system(Atleast trying to find out whether the problem
is transient or persistent)
if its persistent problem we will keep on corrupting and purging,if we do like that

I think dealing with memory corruption is an implemetation specific issue,but shouldn't it be fail stop-manner as suggested
in the ISO 10589?

Aravind

  Les Ginsberg <ginsberg@pluris.com> wrote:

As you say, there are three possibilities:
 
1.The SNP packet itself is corrupted,
 
Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP.
NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB.
 
So we are left with 2 and 3:

2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
or
3.Local systems memory got corrupted
 
(or perhaps both...)
 
If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that.
 
If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly.
 
 
   Les
 
-----Original Message-----
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May 06, 2002 7:41 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the 2001 edition of ISO 10589,
Checksums in LSP entries in SNP packets are also considered while dealing with
LSP confusion. I have some doubts on that
 

If a system has send a LSP on point to point link and is waiting for an acknowledgement
and gets a PSNP,in which the LSPs sequence number is same,but checksum is different,
Why should it try to purge or regenerate as we can be sure that its not a valid different
checksum,but an incorrect checksum?
 
The other system has send an acknowledgement, either because it has installed
the received LSP,or is already having the same LSP
(seqnum,checksum same remaining life time both zero or both non zero).
if we have a different checksum for an LSP with same sequence number
in a PSNP packet received on a point to point circuit,it can be because
 
1.The SNP packet itself is corrupted,
2.The LSP got corrupted in the other systems memory,before the PSNP was
constructed.
3.Local systems memory got corrupted
 
Here there is no LSP confusion as this is not describing copy of the same LSP
with different data(with valid different checksums) .Can't we be sure that the checksum is
incorrect. The last of the 3 cases can be verified and action should be taken in the same way
an implementation handles memory corruption.For the first two cases,how will
the purging of LSP(if the LSP is not in the set of LSP generated by the system)
or regeneration(if its in the setof LSPs generated by the local system)
help? or what does it achieve?
 
I assume that in case of broadcast,while processing CSNPs,if we come across
similar situation where sequence numbers are same and checksums are different,
we cannot make out whether the LSP being described is a corrupted LSP,or its
same LSP with different data or SNP itself is corrupted.In order to work in
any case and get the database synchronized we are purging or regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness


Do You Yahoo!?
Yahoo! Health - your guide to health and wellness --0-909009487-1020753947=:16467-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 7 05:03:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00615 for ; Tue, 7 May 2002 05:03:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g478lPt10624; Tue, 7 May 2002 01:47:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g478dat10579 for ; Tue, 7 May 2002 01:39:36 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g478sIn52999 for ; Tue, 7 May 2002 01:54:18 -0700 (PDT) X-JNPR-Received-From: outside Received: from cisco.com ([144.254.98.48]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 7 May 2002 01:14:14 -0700 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4212.cisco.com [10.50.16.115]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA01917; Tue, 7 May 2002 09:15:07 +0100 (BST) Message-Id: <4.3.2.7.2.20020507090327.042c5be8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Aravind Ravikumar From: mike shand Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP Cc: Les Ginsberg , isis-wg@juniper.net In-Reply-To: <20020507064547.16634.qmail@web11207.mail.yahoo.com> References: <17C81AD1F1FED411991E006008F6D1CA01B3F9DD@avalon.pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 May 2002 08:14:14.0250 (UTC) FILETIME=[2CC074A0:01C1F59F] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 07 May 2002 09:12:49 +0100 Of course an alternative way to deal with "LSP confusion" is not to purge at all, but to treat an otherwise identical LSP which has a numerically HIGHER checksum as being newer. This resolves the situation just as well as a purge in the normal case (and arguably causes less disruption ( if the higher checksum really is the newer then is causes no disruption. If it should really have been the older, then the wrong LSP will be propagated back to the source and it will refresh it. So for this period of time we have the WRONG information, whereas in the 10589 case we have NO information. It is arguable which is better). I think in this case (a wrong xSNP checksum) it would resolve the situation rather more cleanly. This is of course what OSPF does. Note that this will interoperate with purging, and the choice of newer or older is arbitrary but it is CRITICAL that all systems make the same choice (i.e. HIGHER is NEWER - since that is what OSPF does). It will NOT interoperate with systems making the opposite choice. Mike At 23:45 06/05/2002 -0700, Aravind Ravikumar wrote: > Hi, > >Does this mean that if a system detects that its memory is corrupted >(corrupted LSP in memory)it should purge the LSP ,causing a purge >(area wide if its level1 LSP or domain wide in case of L2 LSP)and >the regeneration by the originating system in case of non local LSP >and regeneration in caser of local LSP? > > >But the section 7.3.18 on database validation says that if a system >detects failure >the network entity should be disabled until the failure is corrected and >also suggests >that in the absence of implementation specific methods to deal with the >situation, as a >minimum we should take action to delete the databasea and reacquire the >entire database > >Your answer seems to suggest that as an implementation specific way we can >try to >re-acquire the corrupted LSP by purging it.Are we justified in doing this >.Won't it >be better if we consider the memory corruption as an indication >of more serious problems in our system(Atleast trying to find out whether >the problem >is transient or persistent) >if its persistent problem we will keep on corrupting and purging,if we do >like that > >I think dealing with memory corruption is an implemetation specific >issue,but shouldn't it be fail stop-manner as suggested >in the ISO 10589? > >Aravind > > Les Ginsberg wrote: >>As you say, there are three possibilities: >> >>1.The SNP packet itself is corrupted, >> >>Without the optional SNP checksum and/or HMAC authentication, you will >>not know this is the case. If you do have optional checksum/HMAC and the >>validation fails, you will never process the SNP. >>NOT purging might help you if the checksum reported in the SNP is a >>transient error i.e. the neighbor really has the correct checksum but >>simply reported it incorrectly. The most likely reason for this is SNP >>corruption. The best way to address this is to use optional SNP checksums >>or HMAC authentication. Once you have decided to process the SNP you must >>assume its contents accurately reflect the neighbors DB. >> >>So we are left with 2 and 3: >> >>2.The LSP got corrupted in the other systems memory,before the PSNP was >>constructed. >>or >>3.Local systems memory got corrupted >> >>(or perhaps both...) >> >>If you were certain that neighbor's memory was corrupted you could simply >>keep the SRM flag set and try again. I suppose an implementation could >>recheck the checksum on the local copy of the LSP. If it failed, then we >>know local memory is corrupt and we need to make sure we get a new copy >>of the LSP. Purging it (if non-local) or regenerating it (if local) >>accomplishes that. >> >>If the recheck of the checksum succeeds then you could try resending the >>LSP (keep SRM flag set). However, when the neighbor receives this LSP for >>a second time and compares it to the local copy (sequence #'s match, >>lifetime both non-zero, but checksums don't match) then the neighbor must >>initiate the purge. So we have merely delayed the purge briefly. >> >> >> Les >> >>>-----Original Message----- >>>From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] >>>Sent: Monday, May 06, 2002 7:41 AM >>>To: isis-wg@juniper.net >>>Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP >>> >>>Hi,All >>> >>>In the section 7.3.16.2 of the 2001 edition of ISO 10589, >>>Checksums in LSP entries in SNP packets are also considered while >>>dealing with >>>LSP confusion. I have some doubts on that >>> >>> >>>If a system has send a LSP on point to point link and is waiting for an >>>acknowledgement >>>and gets a PSNP,in which the LSPs sequence number is same,but checksum >>>is different, >>>Why should it try to purge or regenerate as we can be sure that its not >>>a valid different >>>checksum,but an incorrect checksum? >>> >>>The other system has send an acknowledgement, either because it has >>>installed >>>the received LSP,or is already having the same LSP >>>(seqnum,checksum same remaining life time both zero or both non zero). >>>if we have a different checksum for an LSP with same sequence number >>>in a PSNP packet received on a point to point circuit,it can be because >>> >>>1.The SNP packet itself is corrupted, >>>2.The LSP got corrupted in the other systems memory,before the PSNP was >>>constructed. >>>3.Local systems memory got corrupted >>> >>>Here there is no LSP confusion as this is not describing copy of the >>>same LSP >>>with different data(with valid different checksums) .Can't we be sure >>>that the checksum is >>>incorrect. The last of the 3 cases can be verified and action should be >>>taken in the same way >>>an implementation handles memory corruption.For the first two cases,how >>>will >>>the purging of LSP(if the LSP is not in the set of LSP generated by the >>>system) >>>or regeneration(if its in the setof LSPs generated by the local system) >>>help? or what does it achieve? >>> >>>I assume that in case of broadcast,while processing CSNPs,if we come across >>>similar situation where sequence numbers are same and checksums are >>>different, >>>we cannot make out whether the LSP being described is a corrupted LSP,or its >>>same LSP with different data or SNP itself is corrupted.In order to work in >>>any case and get the database synchronized we are purging or regenerating >>>according to the condition >>> >>>Am I right?? >>> >>>Aravind >>> >>> >>> >>>Do You Yahoo!? >>>Yahoo! Health - >>>your guide to health and wellness > > > >Do You Yahoo!? >Yahoo! Health - your >guide to health and wellness _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 7 14:16:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18952 for ; Tue, 7 May 2002 14:16:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g47Hx0t13648; Tue, 7 May 2002 10:59:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g47Hw6t13636 for ; Tue, 7 May 2002 10:58:06 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g47ICpX33845 for ; Tue, 7 May 2002 11:12:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 7 May 2002 10:49:42 -0700 Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA09887; Tue, 7 May 2002 10:50:50 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G83HMG>; Tue, 7 May 2002 10:50:49 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F9DF@avalon.pluris.com> From: Les Ginsberg To: "'Aravind Ravikumar'" , Les Ginsberg , isis-wg@juniper.net Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5EF.B8D15540" X-OriginalArrivalTime: 07 May 2002 17:49:42.0503 (UTC) FILETIME=[9131BF70:01C1F5EF] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 7 May 2002 10:50:48 -0700 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_01C1F5EF.B8D15540 Content-Type: text/plain; charset="iso-8859-1" The notion that a system which detects internal DB corruption should recover by purging an LSP is, of course, wrong, and I apologize for unintentionally suggesting that. The point I was trying to make was that if you receive an SNP and have no reason to know that its contents are corrupt (i.e. no checksum/authentication failure) then you must treat its contents as valid. If you are truly worried about SNP corruption (and certainly that has been a real world problem) then use the optional checksum TLV or HMAC authentication. Don't just ignore information in the hope that the SNP might have been corrupted. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 11:46 PM To: Les Ginsberg; isis-wg@juniper.net Subject: RE: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi, Does this mean that if a system detects that its memory is corrupted (corrupted LSP in memory)it should purge the LSP ,causing a purge (area wide if its level1 LSP or domain wide in case of L2 LSP)and the regeneration by the originating system in case of non local LSP and regeneration in caser of local LSP? But the section 7.3.18 on database validation says that if a system detects failure the network entity should be disabled until the failure is corrected and also suggests that in the absence of implementation specific methods to deal with the situation, as a minimum we should take action to delete the databasea and reacquire the entire database Your answer seems to suggest that as an implementation specific way we can try to re-acquire the corrupted LSP by purging it.Are we justified in doing this .Won't it be better if we consider the memory corruption as an indication of more serious problems in our system(Atleast trying to find out whether the problem is transient or persistent) if its persistent problem we will keep on corrupting and purging,if we do like that I think dealing with memory corruption is an implemetation specific issue,but shouldn't it be fail stop-manner as suggested in the ISO 10589? Aravind Les Ginsberg wrote: As you say, there are three possibilities: 1.The SNP packet itself is corrupted, Without the optional SNP checksum and/or HMAC authentication, you will not know this is the case. If you do have optional checksum/HMAC and the validation fails, you will never process the SNP. NOT purging might help you if the checksum reported in the SNP is a transient error i.e. the neighbor really has the correct checksum but simply reported it incorrectly. The most likely reason for this is SNP corruption. The best way to address this is to use optional SNP checksums or HMAC authentication. Once you have decided to process the SNP you must assume its contents accurately reflect the neighbors DB. So we are left with 2 and 3: 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. or 3.Local systems memory got corrupted (or perhaps both...) If you were certain that neighbor's memory was corrupted you could simply keep the SRM flag set and try again. I suppose an implementation could recheck the checksum on the local copy of the LSP. If it failed, then we know local memory is corrupt and we need to make sure we get a new copy of the LSP. Purging it (if non-local) or regenerating it (if local) accomplishes that. If the recheck of the checksum succeeds then you could try resending the LSP (keep SRM flag set). However, when the neighbor receives this LSP for a second time and compares it to the local copy (sequence #'s match, lifetime both non-zero, but checksums don't match) then the neighbor must initiate the purge. So we have merely delayed the purge briefly. Les -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, May 06, 2002 7:41 AM To: isis-wg@juniper.net Subject: [Isis-wg] Incorrect\Different LSP checksum in SNP Hi,All In the section 7.3.16.2 of the 2001 edition of ISO 10589, Checksums in LSP entries in SNP packets are also considered while dealing with LSP confusion. I have some doubts on that If a system has send a LSP on point to point link and is waiting for an acknowledgement and gets a PSNP,in which the LSPs sequence number is same,but checksum is different, Why should it try to purge or regenerate as we can be sure that its not a valid different checksum,but an incorrect checksum? The other system has send an acknowledgement, either because it has installed the received LSP,or is already having the same LSP (seqnum,checksum same remaining life time both zero or both non zero). if we have a different checksum for an LSP with same sequence number in a PSNP packet received on a point to point circuit,it can be because 1.The SNP packet itself is corrupted, 2.The LSP got corrupted in the other systems memory,before the PSNP was constructed. 3.Local systems memory got corrupted Here there is no LSP confusion as this is not describing copy of the same LSP with different data(with valid different checksums) .Can't we be sure that the checksum is incorrect. The last of the 3 cases can be verified and action should be taken in the same way an implementation handles memory corruption.For the first two cases,how will the purging of LSP(if the LSP is not in the set of LSP generated by the system) or regeneration(if its in the setof LSPs generated by the local system) help? or what does it achieve? I assume that in case of broadcast,while processing CSNPs,if we come across similar situation where sequence numbers are same and checksums are different, we cannot make out whether the LSP being described is a corrupted LSP,or its same LSP with different data or SNP itself is corrupted.In order to work in any case and get the database synchronized we are purging or regenerating according to the condition Am I right?? Aravind _____ Do You Yahoo!? Yahoo! Health - your guide to health and wellness _____ Do You Yahoo!? Yahoo! Health - your guide to health and wellness ------_=_NextPart_001_01C1F5EF.B8D15540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 notion that a system which detects internal DB corruption should = recover by=20 purging an LSP is, of course, wrong, and I apologize for = unintentionally=20 suggesting that. The point I was trying to make was that if you receive = an SNP=20 and have no reason to know that its contents are corrupt (i.e. no=20 checksum/authentication failure) then you must treat its contents as = valid. If=20 you are truly worried about SNP corruption (and certainly that has been = a real=20 world problem) then use the optional checksum TLV or HMAC = authentication. Don't=20 just ignore information in the hope that the SNP might have been = corrupted.=20
 
   Les
 
-----Original Message-----
From: Aravind Ravikumar = [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May 06, = 2002 11:46=20 PM
To: Les Ginsberg; isis-wg@juniper.net
Subject: = RE:=20 [Isis-wg] Incorrect\Different LSP checksum in = SNP

 Hi,

Does this mean that if a system detects that its memory is=20 corrupted
(corrupted LSP in memory)it should purge the LSP = ,causing a=20 purge
(area wide if its level1 LSP or domain wide in case of L2 = LSP)and=20
the regeneration by the originating system in case of non local = LSP
and=20 regeneration in caser of local LSP?


But the section 7.3.18 on database validation says that if a = system=20 detects failure
the network entity should be disabled until the = failure is=20 corrected and also suggests
that in the absence of implementation = specific=20 methods to deal with the situation, as a
minimum we should take = action to=20 delete the databasea and reacquire the entire database=20

Your answer seems to suggest that as an implementation specific = way we can=20 try to
re-acquire the corrupted LSP by purging it.Are we justified = in doing=20 this .Won't it
be better if we consider the memory corruption as = an=20 indication
of more serious problems in our system(Atleast trying = to find=20 out whether the problem
is transient or persistent)
if its = persistent=20 problem we will keep on corrupting and purging,if we do like that=20

I think dealing with memory corruption is an implemetation = specific=20 issue,but shouldn't it be fail stop-manner as suggested
in the = ISO 10589?=20

Aravind=20

  Les Ginsberg <ginsberg@pluris.com> = wrote:=20

As=20 you say, there are three possibilities:
 
1.The SNP packet = itself is=20 corrupted,
 
Without the optional SNP = checksum=20 and/or HMAC authentication, you will not know this is the case. If = you do=20 have optional checksum/HMAC and the validation fails, you will = never process=20 the SNP.
NOT purging might help you if the = checksum reported=20 in the SNP is a transient error i.e. the neighbor really has the = correct=20 checksum but simply reported it incorrectly. The most likely reason = for this=20 is SNP corruption. The best way to address this is to use optional = SNP=20 checksums or HMAC authentication. Once you have decided to = process the=20 SNP you must assume its contents accurately reflect the neighbors=20 DB.
 
So we are left with 2 and = 3:

2.The LSP got corrupted in=20 the other systems memory,before the PSNP was=20
constructed.
or
3.Local = systems memory=20 got corrupted
 
(or perhaps both...)
 
If=20 you were certain that neighbor's memory was corrupted you could = simply keep=20 the SRM flag set and try again. I suppose an implementation = could=20 recheck the checksum on the local copy of the LSP. If it failed, = then we=20 know local memory is corrupt and we need to make sure we get a new = copy of=20 the LSP. Purging it (if non-local) or regenerating it (if local)=20 accomplishes that.
 
If=20 the recheck of the checksum succeeds then you could try resending = the LSP=20 (keep SRM flag set). However, when the neighbor receives this LSP = for a=20 second time and compares it to the local copy (sequence #'s match, = lifetime=20 both non-zero, but checksums don't match) then the neighbor must = initiate=20 the purge. So we have merely delayed the purge = briefly.
 
 
   Les
 
-----Original Message-----
From: Aravind = Ravikumar=20 [mailto:aravindravikumar@yahoo.com]
Sent: Monday, May = 06, 2002=20 7:41 AM
To: isis-wg@juniper.net
Subject: = [Isis-wg]=20 Incorrect\Different LSP checksum in SNP

Hi,All
 
In the section 7.3.16.2 of the = 2001 edition=20 of ISO 10589,
Checksums in LSP entries in SNP = packets are=20 also considered while dealing with
LSP confusion. I have some = doubts=20 on that
 

If a system has send a LSP = on point to=20 point link and is waiting for an acknowledgement
and gets a = PSNP,in=20 which the LSPs sequence number is same,but checksum is = different,
Why=20 should it try to purge or regenerate as we can be sure that its = not a=20 valid different
checksum,but an incorrect=20 checksum?
 
The other system has send an = acknowledgement,=20 either because it has installed
the received LSP,or is = already having=20 the same LSP
(seqnum,checksum same remaining life time both = zero or=20 both non zero).
if we have a different checksum for an LSP = with same=20 sequence number
in a PSNP packet received on a point to = point=20 circuit,it can be because
 
1.The SNP packet itself is=20 corrupted,
2.The LSP got corrupted in the other=20 systems memory,before the PSNP was =
constructed.
3.Local=20 systems memory got corrupted
 
Here there is no LSP confusion as this is not describing = copy of the=20 same LSP
with different data(with valid different checksums) = .Can't we=20 be sure that the checksum is
incorrect. The last of the = 3 cases can=20 be verified and action should be taken in the same way
an=20 implementation handles memory corruption.For the first two = cases,how will=20
the purging of LSP(if the LSP is not in the set of LSP = generated by=20 the system)
or regeneration(if its in the setof LSPs generated = by the=20 local system)
help? or what does it achieve?
 
I assume that in case of = broadcast,while=20 processing CSNPs,if we come across
similar situation where = sequence=20 numbers are same and checksums are different,
we cannot make = out=20 whether the LSP being described is a corrupted LSP,or its
same = LSP with=20 different data or SNP itself is corrupted.In order to work in =
any case=20 and get the database synchronized we are purging or=20 regenerating
according to the condition
 
Am I right??
 
Aravind


Do You Yahoo!?
Yahoo!=20 Health - your guide to health and = wellness


Do You Yahoo!?
Yahoo! = Health=20 - your guide to health and wellness ------_=_NextPart_001_01C1F5EF.B8D15540-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 8 07:41:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01634 for ; Wed, 8 May 2002 07:41:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g48BP5t18829; Wed, 8 May 2002 04:25:05 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g48BOet18795 for ; Wed, 8 May 2002 04:24:40 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g48BdUX52831 for ; Wed, 8 May 2002 04:39:30 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 8 May 2002 04:26:46 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00843; Wed, 8 May 2002 07:27:50 -0400 (EDT) Message-Id: <200205081127.HAA00843@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 X-OriginalArrivalTime: 08 May 2002 11:26:46.0937 (UTC) FILETIME=[3D1A5890:01C1F683] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-08.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 08 May 2002 07:27: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 : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-08.txt Pages : 80 Date : 07-May-02 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-08.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-08.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: <20020507124241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124241.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 8 09:41:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05975 for ; Wed, 8 May 2002 09:41:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g48DP0t19404; Wed, 8 May 2002 06:25:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g48DOmt19389 for ; Wed, 8 May 2002 06:24:48 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-mib-08.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F695.C55E0DC0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 8 May 2002 09:39:26 -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_01C1F695.C55E0DC0 Content-Type: text/plain; charset="iso-8859-1" > Title : Management Information Base for IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-wg-mib-08.txt > Pages : 80 > Date : 07-May-02 From the doc: -- Changes in version 08. -- Changed definiton of isisCircLevelDesIS to hold 7, not 6 bytes -- Moved isisCircLocalID to CircLevel rather than IsisCircEntry -- Remove isisCircIndex from isisIPRAEntry -- Edit description of isisISAdjNeighPriority -- Replace isisISAdjIPAddrAdjIndex with isisISAdjIndex -- Simplified the names of variables which include Adj twice -- isisISAdjAreaAddrAdjIndex, isisISAdjIPAddrAdjIndex, -- and isisISAdjProtSuppAdjIndex. -- Added isisSysMaxAge to control MaxAge for LSPs we generate -- Added isisSysReceiveLSPBufferSize to control LSPs buffers - jeff parker ------_=_NextPart_000_01C1F695.C55E0DC0 Content-Type: message/rfc822 To: Subject: Date: Wed, 8 May 2002 09:39:31 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1F695.C55E0DC0" ------_=_NextPart_002_01C1F695.C55E0DC0 Content-Type: text/plain ------_=_NextPart_002_01C1F695.C55E0DC0 Content-Type: application/octet-stream; name="ATT49495.txt" Content-Disposition: attachment; filename="ATT49495.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020507124241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-08.txt ------_=_NextPart_002_01C1F695.C55E0DC0 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-isis-wg-mib-08.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1F695.C55E0DC0-- ------_=_NextPart_000_01C1F695.C55E0DC0-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 8 16:14:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22411 for ; Wed, 8 May 2002 16:14:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g48Jv0t21030; Wed, 8 May 2002 12:57:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g48Jugt21018 for ; Wed, 8 May 2002 12:56:42 -0700 (PDT) (envelope-from prz@redback.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g48KBYX64859 for ; Wed, 8 May 2002 13:11:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 8 May 2002 13:01:47 -0700 Received: from redback.com ([63.200.51.89]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GVT001566D07V@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Wed, 08 May 2002 13:03:00 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3CD94DE5.858BD755@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 08 May 2002 20:01:48.0046 (UTC) FILETIME=[2F9962E0:01C1F6CB] Subject: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 08 May 2002 09:10:13 -0700 Content-Transfer-Encoding: 7BIT We are starting last call on draft-ietf-isis-ext-lsp-frags-00. The last call will end 5/22/02 thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 9 21:49:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19916 for ; Thu, 9 May 2002 21:49:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4A1W1t28520; Thu, 9 May 2002 18:32:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4A1VFt28508 for ; Thu, 9 May 2002 18:31:15 -0700 (PDT) (envelope-from prz@redback.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4A1kEn34314 for ; Thu, 9 May 2002 18:46:15 -0700 (PDT) X-JNPR-Received-From: outside Received: from mta5.snfc21.pbi.net ([206.13.28.241]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 9 May 2002 18:45:00 -0700 Received: from redback.com ([63.200.53.15]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GVV00GX2GX2UI@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Thu, 09 May 2002 18:46:14 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net Reply-to: prz@redback.com Message-id: <3CDAEFD5.8FD48C74@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-OriginalArrivalTime: 10 May 2002 01:45:00.0718 (UTC) FILETIME=[4C3384E0:01C1F7C4] Subject: [Isis-wg] call for agenda items ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 09 May 2002 14:53:25 -0700 Content-Transfer-Encoding: 7BIT Given enough things on the agenda, we are planning to have a meeting in Japan for ISIS. Since neither Tony L. nor Tony P. will be there, we will have Tony Ward chair the group this time. Please forward requests for agenda slot to dward@cisco.com with cc: to the chairs. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 10 07:36:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15320 for ; Fri, 10 May 2002 07:36:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4ABK1t31338; Fri, 10 May 2002 04:20:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4ABJkt31323 for ; Fri, 10 May 2002 04:19:47 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4ABYmn42569 for ; Fri, 10 May 2002 04:34:49 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Fri, 10 May 2002 04:33:33 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14865; Fri, 10 May 2002 07:34:38 -0400 (EDT) Message-Id: <200205101134.HAA14865@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 X-OriginalArrivalTime: 10 May 2002 11:33:33.0837 (UTC) FILETIME=[8475DBD0:01C1F816] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-12.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 10 May 2002 07:34:38 -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 : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-12.txt Pages : 11 Date : 09-May-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gmpls-extensions-12.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-gmpls-extensions-12.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: <20020509124100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020509124100.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 13 11:41:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16224 for ; Mon, 13 May 2002 11:41:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DFO0t53668; Mon, 13 May 2002 08:24:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DFNot53656 for ; Mon, 13 May 2002 08:23:50 -0700 (PDT) (envelope-from nvbolhu@hzsms01.nl.lucent.com) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4DFdBL22254 for ; Mon, 13 May 2002 11:39:11 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28698; Mon, 13 May 2002 17:39:09 +0200 (MET DST) Cc: nvbolhuis@lucent.com, dkatz@juniper.net, rsaluja@nortelnetworks.com Received: from hzsc076.nl.lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28676; Mon, 13 May 2002 17:39:01 +0200 (MET DST) Message-Id: <200205131539.RAA28676@hzsms01.nl.lucent.com> From: "Norbert v. Bolhuis" Reply-To: "Norbert v. Bolhuis" Subject: Re: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational To: iesg@ietf.org, isis-wg@spider.juniper.net, Internet-Drafts@ietf.org Original-Cc: nvbolhu@hzsms01.nl.lucent.com, dkatz@juniper.net, rsaluja@nortelnetworks.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ujf8BzzwrIffhEgNDYQgMA== Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 13 May 2002 17:39:01 +0200 (MET DST) Am I missing something here ? In my opinion the 3 problems described in this draft (draft-ietf-isis-3way-06.txt) hardly exist. Problem 1 --------- I do not know what exactly is meant with "a cut set of one through the link", but anyway, if a link comes back up a CSNP will be sent *AND* the SRM flag for all LSPs will be set for this link. This means all LSPs will be sent (and the SRM flag won't be reset until explicit acknowledgement). Problem 2 --------- A unidirectional link failure will not be detected by only one system. If a node stops receiving p2p IIHs the adjacency will be down *AND* the node should stop sending IIHs and continue (or restart) sending ISHs. This causes the adjacency to be down at the remote node also. ISO10589 may not be very clear about this, but IS-IS implementations are supposed to work this way. Problem 3 --------- This might be a problem indeed although I would like to see a more extended explanation. If a p2p link is connected to another node the adjacency will be down (because of the different SystemID) and be established with the new node shortly after. The same may apply for a p2p link connected to another link on the same system, the adjacency may go down because the IIH now has a different local circuit ID field (the 1 octet field), but I'm not sure what ISO10589 says about this. If the adjacency stays up (to another link on the same system) no problems will arise as long as the remote system takes into account the 'new' local circuit ID when running SPF. Norbert van Bolhuis -------------------- nvbolhuis@lucent.com > X-JNPR-Received-From: outside > To: IETF-Announce:;@spider.juniper.net@hzsms01.nl.lucent.com > Cc: isis-wg@juniper.net > From: The IESG > X-OriginalArrivalTime: 06 May 2002 21:17:34.0015 (UTC) FILETIME=[7061B4F0:01C1F543] > Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational > X-BeenThere: isis-wg@spider.juniper.net > X-Mailman-Version: 2.0rc1 > List-Help: > List-Post: > List-Subscribe: , > List-Id: IETF IS-IS working group > List-Unsubscribe: , > List-Archive: > > > The IESG has received a request from the IS-IS for IP Internets Working > Group to consider Three-Way Handshake for IS-IS Point-to-Point > Adjacencies as an Informational RFC. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 13 12:27:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18721 for ; Mon, 13 May 2002 12:27:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DGB0t53980; Mon, 13 May 2002 09:11:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DGADt53968 for ; Mon, 13 May 2002 09:10:13 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Norbert v. Bolhuis'" , isis-wg@spider.juniper.net Cc: dkatz@juniper.net, rsaluja@nortelnetworks.com Subject: RE: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-P oint Adjacencies to Informational MIME-Version: 1.0 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@spider.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, 13 May 2002 12:25:19 -0400 > Am I missing something here ? > > In my opinion the 3 problems described in this draft > (draft-ietf-isis-3way-06.txt) hardly exist. > > Problem 1 > --------- > I do not know what exactly is meant with "a cut set of one > through the link", > but anyway, if a link comes back up a CSNP will be sent *AND* the > SRM flag for all LSPs will be set for this link. This means > all LSPs will be > sent (and the SRM flag won't be reset until explicit acknowledgement). "Cut set" is a graph theory term for a set whose removal splits a connected graph into parts. > > Problem 2 > --------- > A unidirectional link failure will not be detected by only one system. > If a node stops receiving p2p IIHs the adjacency will be down > *AND* the > node should stop sending IIHs and continue (or restart) sending ISHs. > This causes the adjacency to be down at the remote node also. > ISO10589 may not be very clear about this, but IS-IS > implementations are > supposed to work this way. Not all link layers are created equal. Some point to point links don't have the smarts to reset. Note that the authors refer to this in their introduction (below). - jeff parker 1.0 Introduction The IS-IS protocol [1] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 13 13:33:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21323 for ; Mon, 13 May 2002 13:33:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DHG0t54288; Mon, 13 May 2002 10:16:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps06s.us.nortel.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DHFFt54276 for ; Mon, 13 May 2002 10:15:16 -0700 (PDT) (envelope-from rsaluja@nortelnetworks.com) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps06s.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DHU4Q16632; Mon, 13 May 2002 13:30:04 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DHQmS03382; Mon, 13 May 2002 13:26:49 -0400 (EDT) Received: from lead.engeast (lead [192.32.226.44]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id NAA28052; Mon, 13 May 2002 13:29:52 -0400 for Received: from nortelnetworks.com (localhost [127.0.0.1]) by lead.engeast (8.9.3+Sun/8.9.1) with ESMTP id NAA09983; Mon, 13 May 2002 13:29:48 -0400 (EDT) Message-ID: <3CDFF80C.B722E2AB@nortelnetworks.com> From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Norbert v. Bolhuis" CC: iesg@ietf.org, isis-wg@spider.juniper.net, Internet-Drafts@ietf.org, dkatz@juniper.net, "Rajesh Saluja" Subject: Re: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies to Informational References: <200205131539.RAA28676@hzsms01.nl.lucent.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@spider.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, 13 May 2002 13:29:48 -0400 Content-Transfer-Encoding: 7bit "Norbert v. Bolhuis" wrote: > Am I missing something here ? > > In my opinion the 3 problems described in this draft > (draft-ietf-isis-3way-06.txt) hardly exist. > > Problem 1 > --------- > I do not know what exactly is meant with "a cut set of one through the link", > but anyway, if a link comes back up a CSNP will be sent *AND* the > SRM flag for all LSPs will be set for this link. This means all LSPs will be > sent (and the SRM flag won't be reset until explicit acknowledgement). What about the other end which could not detect the link going down and hence will never send the full database. The databases will be unsynchronized. > > > Problem 2 > --------- > A unidirectional link failure will not be detected by only one system. > If a node stops receiving p2p IIHs the adjacency will be down *AND* the > node should stop sending IIHs and continue (or restart) sending ISHs. > This causes the adjacency to be down at the remote node also. > ISO10589 may not be very clear about this, but IS-IS implementations are > supposed to work this way. Here we are talking about unreliable point to point links and multiple parallel links between two systems. Please read it carefully. > > > Problem 3 > --------- > This might be a problem indeed although I would like to see a more extended > explanation. > If a p2p link is connected to another node the adjacency will be down (because > of the different SystemID) and be established with the new node shortly after. > The same may apply for a p2p link connected to another link on the same system, > the adjacency may go down because the IIH now has a different local circuit ID > field (the 1 octet field), but I'm not sure what ISO10589 says about this. > If the adjacency stays up (to another link on the same system) no problems > will arise as long as the remote system takes into account the 'new' local > circuit ID when running SPF. Let me just cut and paste from Dave's mail from archive. "several router vendors have implemented a scheme where two routers act together as a SONET ADM for the purposes of implementing Automatic Protection Switching (APS.) The idea is that the trunk circuit comes into a POP, hits an ADM, and out the other side come the APS Working and Protect circuits, which then go into different routers. This is primarily viewed as a way of protecting against router/interface failure or somebody tripping over the last 100 feet of fiber, while keeping the expensive trunk circuit operating. The routers coordinate via a back channel to instigate and react to APS signalling (via the K1/K2 overhead bytes.) In 1+1 Bidirectional mode, the ADM will send the same bit stream to both routers, but only listen to one of them. Without the addition of the ID stuff, it is theoretically possible that the router on the circuit not selected by the ADM can think that it has an adjacency to the guy at the far end of the trunk, which would cause traffic to be poured down a black hole." Hope it helps. Thanks, Rajesh > > > Norbert van Bolhuis > -------------------- > nvbolhuis@lucent.com > > > X-JNPR-Received-From: outside > > To: IETF-Announce:;@spider.juniper.net@hzsms01.nl.lucent.com > > Cc: isis-wg@juniper.net > > From: The IESG > > X-OriginalArrivalTime: 06 May 2002 21:17:34.0015 (UTC) FILETIME=[7061B4F0:01C1F543] > > Subject: [Isis-wg] Last Call: Three-Way Handshake for IS-IS Point-to-Point Adjacencies > to Informational > > X-BeenThere: isis-wg@spider.juniper.net > > X-Mailman-Version: 2.0rc1 > > List-Help: > > List-Post: > > List-Subscribe: , > > > List-Id: IETF IS-IS working group > > List-Unsubscribe: , > > > List-Archive: > > > > > > The IESG has received a request from the IS-IS for IP Internets Working > > Group to consider Three-Way Handshake for IS-IS Point-to-Point > > Adjacencies as an Informational RFC. > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send any comments to the > > iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. > > > > Files can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-06.txt > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 13 16:25:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01262 for ; Mon, 13 May 2002 16:25:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DK81t55045; Mon, 13 May 2002 13:08:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DK7Xt55033 for ; Mon, 13 May 2002 13:07:33 -0700 (PDT) (envelope-from scoya@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4DKMkn01706 for ; Mon, 13 May 2002 13:22:51 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 13 May 2002 13:16:04 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00707; Mon, 13 May 2002 16:16:56 -0400 (EDT) Message-Id: <200205132016.QAA00707@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , isis-wg@juniper.net From: The IESG X-OriginalArrivalTime: 13 May 2002 20:16:04.0187 (UTC) FILETIME=[01F6E2B0:01C1FABB] Subject: [Isis-wg] Document Action: Optional Checksums in ISIS to Informational Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 13 May 2002 16:16:56 -0400 The IESG has approved the Internet-Draft 'Optional Checksums in ISIS' as a Informational. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 13 17:33:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04982 for ; Mon, 13 May 2002 17:33:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DLH1t55436; Mon, 13 May 2002 14:17:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4DLGnt55424 for ; Mon, 13 May 2002 14:16:49 -0700 (PDT) (envelope-from scoya@cnri.reston.va.us) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g4DLWCX66188 for ; Mon, 13 May 2002 14:32:12 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 13 May 2002 14:20:28 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04319; Mon, 13 May 2002 17:21:32 -0400 (EDT) Message-Id: <200205132121.RAA04319@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , isis-wg@juniper.net From: The IESG X-OriginalArrivalTime: 13 May 2002 21:20:28.0796 (UTC) FILETIME=[01736BC0:01C1FAC4] Subject: [Isis-wg] Document Action: Reserved TLV Codepoints in ISIS to Informational Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 13 May 2002 17:21:32 -0400 The IESG has approved the Internet-Draft 'Reserved TLV Codepoints in ISIS' as a Informational. This document is the product of the IS-IS for IP Internets Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 15 11:40:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10239 for ; Wed, 15 May 2002 11:40:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FFM2t67189; Wed, 15 May 2002 08:22:02 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FFL7t67177 for ; Wed, 15 May 2002 08:21:07 -0700 (PDT) (envelope-from sprevidi@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g4FFagX08509 for ; Wed, 15 May 2002 08:36:42 -0700 (PDT) X-JNPR-Received-From: outside Received: from strange-brew.cisco.com ([144.254.15.119]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 May 2002 08:17:11 -0700 Received: from there (dhcp-bru-peg1-vl18-144-254-2-42.cisco.com [144.254.2.42]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA18522; Wed, 15 May 2002 17:18:28 +0200 (MET DST) Message-Id: <200205151518.RAA18522@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: naiming@redback.com X-Mailer: KMail [version 1.3.1] Cc: isis-wg@juniper.net MIME-Version: 1.0 X-OriginalArrivalTime: 15 May 2002 15:17:11.0765 (UTC) FILETIME=[963BF050:01C1FC23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4FFL7t67178 Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 15 May 2002 17:18:22 +0200 Content-Transfer-Encoding: 8bit Naiming, in draft-ietf-isis-wg-multi-topology-03.txt I see: ------------------------------------------------------------------- 8.3. Multi-Topology Reachable IPv4 Prefixes TLV TLV number of this TLV is 235. It is aligned with extended IS reachability TLV type 135 beside an additional two bytes in front. 2 bytes of MT membership 4 bits (most significant) are reserved 12 least significant bits are the MT ID 0-251 octets of structures used in TLV type 135. This TLV can occur multiple times. A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed: Sub-TLV type 117 Length 4 octets Name MT IPv4 Prefix Color The value of 1 of this sub-TLV is reserved for MT Management Prefix color. If the MT Management Prefix color is present in this TLV, a MT based SPF computation MAY also need to install this prefix into the ``standard'' or ``management'' RIB. This MAY be necessary for example in the case of MT based network management. --------------------------------------------------------------------- In draft-martin-neal-policy-isis-admin-tags we specified admin tag sub-TLV for both TLV 135 and 235. Not sure about the real purpose of sub-TLV 117 but I believe we could just reserve an admin tag value of 1 of for "MT Management". s. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 15 13:07:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13578 for ; Wed, 15 May 2002 13:07:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FGo1t67607; Wed, 15 May 2002 09:50:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FGnlt67592 for ; Wed, 15 May 2002 09:49:47 -0700 (PDT) (envelope-from cmartin@gnilink.net) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4FH5Mn44914 for ; Wed, 15 May 2002 10:05:22 -0700 (PDT) X-JNPR-Received-From: outside Received: from entmail.gnilink.net ([199.45.47.10]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 May 2002 09:54:51 -0700 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:56:10 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2E6E@entmail.gnilink.com> From: "Martin, Christian" To: "'stefano previdi'" , naiming@redback.com Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.tx t MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-OriginalArrivalTime: 15 May 2002 16:54:51.0953 (UTC) FILETIME=[3B2DAA10:01C1FC31] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 15 May 2002 12:56:10 -0400 Was this TLV designed to identify a particular MT? I suppose this may be used by an implementation to indicate which MT a prefix belongs to, but it must be consistent across the domain for it to be useful, which means, IMO, that it should be identified _not_ by prefix, but by MT itself. Unless I am reading this incorrectly. Otherwise, there appears to be some overlap between SubTLV 1 and 117 wrt a prefix. chris >-----Original Message----- >From: stefano previdi [mailto:sprevidi@cisco.com] >Sent: Wednesday, May 15, 2002 11:18 AM >To: naiming@redback.com >Cc: isis-wg@juniper.net >Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.txt > > >Naiming, > >in draft-ietf-isis-wg-multi-topology-03.txt I see: > >------------------------------------------------------------------- >8.3. Multi-Topology Reachable IPv4 Prefixes TLV > > TLV number of this TLV is 235. It is aligned with extended IS > reachability TLV type 135 beside an additional two bytes in front. > > 2 bytes of MT membership > 4 bits (most significant) are reserved > 12 least significant bits are the MT ID > 0-251 octets of structures used in TLV type 135. > > This TLV can occur multiple times. > A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed: > > Sub-TLV type 117 > Length 4 octets > Name MT IPv4 Prefix Color > > The value of 1 of this sub-TLV is reserved for MT Management > Prefix color. > > If the MT Management Prefix color is present in this TLV, >a MT based > SPF computation MAY also need to install this prefix into the > ``standard'' or ``management'' RIB. This MAY be necessary for > example in the case of MT based network management. >--------------------------------------------------------------------- > >In draft-martin-neal-policy-isis-admin-tags we specified >admin tag sub-TLV for both TLV 135 and 235. Not sure about >the real purpose of sub-TLV 117 but I believe we could just >reserve an admin tag value of 1 of for "MT Management". > > > > > > >s. > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis>-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 15 15:36:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19530 for ; Wed, 15 May 2002 15:36:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FJJ0t68255; Wed, 15 May 2002 12:19:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FJIEt68243 for ; Wed, 15 May 2002 12:18:14 -0700 (PDT) (envelope-from naiming@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g4FJXoX15167 for ; Wed, 15 May 2002 12:33:50 -0700 (PDT) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 15 May 2002 12:13:35 -0700 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 0CC4639B5BA; Wed, 15 May 2002 12:14:54 -0700 (PDT) To: "Martin, Christian" Cc: "'stefano previdi'" , isis-wg@juniper.net Subject: Re: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.tx t In-reply-to: Mail from "Martin, Christian" dated Wed, 15 May 2002 12:56:10 EDT <94B9091E1149D411A45C00508BACEB35015F2E6E@entmail.gnilink.com> From: Naiming Shen Message-Id: <20020515191454.0CC4639B5BA@prattle.redback.com> X-OriginalArrivalTime: 15 May 2002 19:13:35.0799 (UTC) FILETIME=[9C93C470:01C1FC44] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 15 May 2002 12:14:53 -0700 Stefano and Christian, ] Was this TLV designed to identify a particular MT? I suppose this may be ] used by an implementation to indicate which MT a prefix belongs to, but it ] must be consistent across the domain for it to be useful, which means, IMO, ] that it should be identified _not_ by prefix, but by MT itself. Unless I am ] reading this incorrectly. this should be per prefix based. imagine the network consists of multiple topologies using M-ISIS, and router connected to the management LAN may not be in all those topologies. this particular tlv 117 value of 1 indicate the option of installing this prefix into the "normal" unicast RIB, so the management traffic has a path to reach those routers. ] ] Otherwise, there appears to be some overlap between SubTLV 1 and 117 wrt a ] prefix. I would think there is no need to mention "MT Management" in subtlv 1. the subtlv 1 will be used for general ISIS prefix things. But the subtlv 117 can be used for MT related prefix things. thanks. ] ] chris ] ] >-----Original Message----- ] >From: stefano previdi [mailto:sprevidi@cisco.com] ] >Sent: Wednesday, May 15, 2002 11:18 AM ] >To: naiming@redback.com ] >Cc: isis-wg@juniper.net ] >Subject: [Isis-wg] question on draft-ietf-isis-wg-multi-topology-03.txt ] > ] > ] >Naiming, ] > ] >in draft-ietf-isis-wg-multi-topology-03.txt I see: ] > ] >------------------------------------------------------------------- ] >8.3. Multi-Topology Reachable IPv4 Prefixes TLV ] > ] > TLV number of this TLV is 235. It is aligned with extended IS ] > reachability TLV type 135 beside an additional two bytes in front. ] > ] > 2 bytes of MT membership ] > 4 bits (most significant) are reserved ] > 12 least significant bits are the MT ID ] > 0-251 octets of structures used in TLV type 135. ] > ] > This TLV can occur multiple times. ] > A new sub-TLV for this MT Reachable IPv4 Prefixes TLV is proposed: ] > ] > Sub-TLV type 117 ] > Length 4 octets ] > Name MT IPv4 Prefix Color ] > ] > The value of 1 of this sub-TLV is reserved for MT Management ] > Prefix color. ] > ] > If the MT Management Prefix color is present in this TLV, ] >a MT based ] > SPF computation MAY also need to install this prefix into the ] > ``standard'' or ``management'' RIB. This MAY be necessary for ] > example in the case of MT based network management. ] >--------------------------------------------------------------------- ] > ] >In draft-martin-neal-policy-isis-admin-tags we specified ] >admin tag sub-TLV for both TLV 135 and 235. Not sure about ] >the real purpose of sub-TLV 117 but I believe we could just ] >reserve an admin tag value of 1 of for "MT Management". ] > ] > ] > ] > ] > ] > ] >s. ] > ] > ] >_______________________________________________ ] >Isis-wg mailing list - Isis-wg@spider.juniper.net ] >http://spider.juniper.net/mailman/listinfo/isis>-wg ] > ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 15 17:53:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23428 for ; Wed, 15 May 2002 17:53:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FLa0t68882; Wed, 15 May 2002 14:36:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4FLZ1t68870 for ; Wed, 15 May 2002 14:35:01 -0700 (PDT) (envelope-from tli@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 0656F23C38 for ; Wed, 15 May 2002 14:52:34 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4FLoSvM007033 for ; Wed, 15 May 2002 14:50:28 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g4FLoSBo008997; Wed, 15 May 2002 14:50:28 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15586.55332.355645.614362@alpha-tli.procket.com> To: isis-wg@spider.juniper.net X-Mailer: VM 6.92 under Emacs 20.5.1 Subject: [Isis-wg] Message from the ITU Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 15 May 2002 14:50:28 -0700 Content-Transfer-Encoding: 7bit Hi Folks, I'm forwarding the following message from the ITU. I've reformatted it to IETF-normal ASCII, so any subsequent noise is my fault. Tony ---------------------------------------------------------------------- ITU - Telecommunication Standardization Sector Annex S Geneva, 10th May 2002 QUESTIONS: Q.14/15 SOURCE: Rapporteur TITLE: Communication Statement to IETF IS-IS Working Group on work on Integrated IS-IS on the DCN in Q.14/15 _____________ COMMUNICATION STATEMENT TO: IETF IS-IS Working Group APPROVAL: Agreed to at 29 April - 10 May 2002 SG15 meeting FOR: Information DEADLINE: None CONTACT: Hing-Kam Lam Tel: +1-732-949-8338 101 Crawfords Corner Road Fax: +1-732-949-5055 Holmdel, NJ 07733, USA Email: hklam@lucent.com As requested by the chairman of the IETF IS-IS working group, Q.14/15 would like to inform the IETF of the current work that Q.14/15 is doing on recommendation G.7712 "Architecture and Specification of Data Communication Network". This contains the draft revision of G.7712 and is intended to be consented at the next SG15 plenary in January 2003. The particular sections that IS-IS WG may be interested for further developments on IS-IS are: - Section 7.1.8 Network Layer PDU Encapsulation Function as well as Annex B for the Description of the Automatic Encapsulation Procedures - Section 7.1.10.1.1 Network-layer Protocol Aware Adjacency Creation - Section 7.1.10.1 Integrated IS-IS requirements as well as Annex A on Requirements for Three-Way Handshaking - Appendix III Commissioning guide for SDH NEs in dual RFC 1195 environment and impact of automatic Encapsulation option - Appendix II Implementation Example of Automatic Encapsulation The document is available as version 1.1 of G.7712 at the ITU-T public ftp site for your information. The document may be obtained from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 12:06:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00220 for ; Thu, 16 May 2002 12:06:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GFn1t74007; Thu, 16 May 2002 08:49:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GFm8t73994 for ; Thu, 16 May 2002 08:48:08 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4GG3fZ10157; Thu, 16 May 2002 18:03:41 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4GG2r203634; Thu, 16 May 2002 17:02:54 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 17:03:43 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB6B4@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Tony Li'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Message from the ITU MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FCF3.3EBA9AD6" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 16 May 2002 17:03:40 +0100 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_01C1FCF3.3EBA9AD6 Content-Type: text/plain; charset="iso-8859-1" Please note that there is now a version 1.2 also at the same URL. Version 1.1 is text that was agreed from the last ITU-T SG15 meeting, whilst version 1.2 has no official status. That said, I believe that version 1.2 is considerably easier to read. The technical content is exactly the same across the two versions. I would personally advice anyone interested in this work to head straight for v1.2. Philip -----Original Message----- From: Tony Li [mailto:tli@procket.com] Sent: Wednesday, May 15, 2002 10:50 PM To: isis-wg@spider.juniper.net Subject: [Isis-wg] Message from the ITU Hi Folks, I'm forwarding the following message from the ITU. I've reformatted it to IETF-normal ASCII, so any subsequent noise is my fault. Tony ---------------------------------------------------------------------- ITU - Telecommunication Standardization Sector Annex S Geneva, 10th May 2002 QUESTIONS: Q.14/15 SOURCE: Rapporteur TITLE: Communication Statement to IETF IS-IS Working Group on work on Integrated IS-IS on the DCN in Q.14/15 _____________ COMMUNICATION STATEMENT TO: IETF IS-IS Working Group APPROVAL: Agreed to at 29 April - 10 May 2002 SG15 meeting FOR: Information DEADLINE: None CONTACT: Hing-Kam Lam Tel: +1-732-949-8338 101 Crawfords Corner Road Fax: +1-732-949-5055 Holmdel, NJ 07733, USA Email: hklam@lucent.com As requested by the chairman of the IETF IS-IS working group, Q.14/15 would like to inform the IETF of the current work that Q.14/15 is doing on recommendation G.7712 "Architecture and Specification of Data Communication Network". This contains the draft revision of G.7712 and is intended to be consented at the next SG15 plenary in January 2003. The particular sections that IS-IS WG may be interested for further developments on IS-IS are: - Section 7.1.8 Network Layer PDU Encapsulation Function as well as Annex B for the Description of the Automatic Encapsulation Procedures - Section 7.1.10.1.1 Network-layer Protocol Aware Adjacency Creation - Section 7.1.10.1 Integrated IS-IS requirements as well as Annex A on Requirements for Three-Way Handshaking - Appendix III Commissioning guide for SDH NEs in dual RFC 1195 environment and impact of automatic Encapsulation option - Appendix II Implementation Example of Automatic Encapsulation The document is available as version 1.1 of G.7712 at the ITU-T public ftp site for your information. The document may be obtained from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATION S/index.html. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1FCF3.3EBA9AD6 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] Message from the ITU

Please note that there is now a version 1.2 also at the same URL.

Version 1.1 is text that was agreed from the last ITU-T SG15 meeting, whilst version 1.2 has no official status.
That said, I believe that version 1.2 is considerably easier to read.
The technical content is exactly the same across the two versions.

I would personally advice anyone interested in this work to head straight for v1.2.

Philip

-----Original Message-----
From: Tony Li [mailto:tli@procket.com]
Sent: Wednesday, May 15, 2002 10:50 PM
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] Message from the ITU



Hi Folks,

I'm forwarding the following message from the ITU.  I've reformatted it to
IETF-normal ASCII, so any subsequent noise is my fault.

Tony

----------------------------------------------------------------------

ITU - Telecommunication Standardization Sector  Annex S
Geneva, 10th May 2002

QUESTIONS:      Q.14/15
SOURCE: Rapporteur
TITLE:  Communication Statement to IETF IS-IS Working Group on work on
        Integrated IS-IS on the DCN in Q.14/15
_____________
COMMUNICATION STATEMENT
TO:     IETF IS-IS Working Group
APPROVAL:       Agreed to at 29 April - 10 May 2002 SG15 meeting
FOR:    Information
DEADLINE:       None

CONTACT:        Hing-Kam Lam    Tel:    +1-732-949-8338
101 Crawfords Corner Road       Fax:    +1-732-949-5055
Holmdel, NJ 07733, USA  Email:  hklam@lucent.com

As requested by the chairman of the IETF IS-IS working group, Q.14/15 would
like to inform the IETF of the current work that Q.14/15 is doing on
recommendation G.7712 "Architecture and Specification of Data Communication
Network".  This contains the draft revision of G.7712 and is intended to be
consented at the next SG15 plenary in January 2003.

The particular sections that IS-IS WG may be interested for further
developments on IS-IS are:

- Section 7.1.8 Network Layer PDU Encapsulation Function as well as Annex B
  for the Description of the Automatic Encapsulation Procedures
- Section 7.1.10.1.1 Network-layer Protocol Aware Adjacency Creation
- Section 7.1.10.1 Integrated IS-IS requirements as well as Annex A on
  Requirements for Three-Way Handshaking
- Appendix III Commissioning guide for SDH NEs in dual RFC 1195 environment
  and impact of automatic Encapsulation option
- Appendix II Implementation Example of Automatic Encapsulation

The document is available as version 1.1 of G.7712 at the ITU-T public ftp
site for your information. The document may be obtained from
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html.
_______________________________________________
Isis-wg mailing list  -  Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C1FCF3.3EBA9AD6-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 16:28:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09876 for ; Thu, 16 May 2002 16:28:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GKB0t75150; Thu, 16 May 2002 13:11:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GKANt75138 for ; Thu, 16 May 2002 13:10:23 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Message from the ITU MIME-Version: 1.0 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@spider.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, 16 May 2002 16:25:59 -0400 > The document is available as version 1.1 of G.7712 at the > ITU-T public ftp site for your information. The document > may be obtained from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATION S/index.html. I've had a brief look at Version 2. I've noted some minor typos below, and have a couple of comments. This is the wrong forum to reach the ITU, so perhaps these are misplaced. Appendix A includes a description of the 3-way handshake. The document refers to RFCs elsewhere, so I assume that when the 3way handshake is an RFC, this Appendix will be replaced with a reference. The ideas on auto-encapsulation of traffic to bridge between OSI and IP networks seems frightfully clever, and I'm happy to point all further discussion of this topic to the ITU. This looks like a fruitful source of future problems and networking PhDs. - jeff parker Nits: p 37/38 This describes generation a ProtocolSupportedMismatch if there -is- and adjacency, but there is no match, when a change in protocols supported forces a tear-down. This won't happen often. Should there also be provisions for an event if there isn't an adjacency yet? p. 38 'Manor' should be 'manner' in section 7.1.10.1.2.2. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 16:58:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10764 for ; Thu, 16 May 2002 16:58:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GKf1t75297; Thu, 16 May 2002 13:41:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GKeAt75285 for ; Thu, 16 May 2002 13:40:10 -0700 (PDT) (envelope-from jonathan.sadler@tellabs.com) Received: from mailw02.hq.tellabs.com (mailw02.lisle.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint) with ESMTP id AGX67844; Thu, 16 May 2002 15:55:51 -0500 (CDT) Received: from tellabs.com (dhcp-172-23-111-24.lisle.tellabs.com [172.23.111.24]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id PAA22185; Thu, 16 May 2002 15:55:53 -0500 (CDT) Message-ID: <3CE41CA5.74BBDEB0@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU References: 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@spider.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, 16 May 2002 15:55:01 -0500 Content-Transfer-Encoding: 7bit Hi Jeff - I'm a participant in the Q14/15 stuff, and can provide some insight on your first comment. > Appendix A includes a description of the 3-way handshake. > The document refers to RFCs elsewhere, so I > assume that when the 3way handshake is an RFC, this > Appendix will be replaced with a reference. Since the work in the IETF on IS-IS is limited to achiving Informational status, the ITU will never be able to use an IETF RFC as a normative reference. This is the reason why Sec. 7.1.10.1.2 goes into such excruciating detail describing how to do what is in RFC 2966. The mention of RFC 2966 in Sec 7.1.10.1.2 is purely informative, not normative. To be honest, I would prefer to see the ITU reference IETF RFCs instead of including reworded text that implements the same thing that is in an RFC. Not only does it keep from efforts to rewrite all of the RFC (to get past copyright issues), but it also makes certain that implementations will interoperate. Unfortunately, this issue will not go away until the IETF and JTC1 resolve how extensions to IS-IS should be progressed. Jonathan Sadler ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 18:08:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12132 for ; Thu, 16 May 2002 18:08:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GLp1t75601; Thu, 16 May 2002 14:51:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz1.procket.com (dmz1.procket.com [65.174.124.36]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GLo0t75589 for ; Thu, 16 May 2002 14:50:01 -0700 (PDT) (envelope-from tli@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 37E6323C36; Thu, 16 May 2002 15:07:07 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4GM5YvM012633; Thu, 16 May 2002 15:05:34 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g4GM5YHN011252; Thu, 16 May 2002 15:05:34 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15588.11566.114030.664703@alpha-tli.procket.com> To: Cc: "Jeff Parker" , Subject: Re: [Isis-wg] Message from the ITU In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 16 May 2002 15:05:34 -0700 Content-Transfer-Encoding: 7bit Hi Jonathan, | Since the work in the IETF on IS-IS is limited to achiving Informational | status, the ITU will never be able to use an IETF RFC as a normative | reference. This comment struck me as curious. Are you saying that if IETF claimed to pass standards on IS-IS and put these RFCs on the standards track, that the ITU would be willing to reference them as Normative? What is the reason for not referencing Informational RFC's as normative? They are fixed, published documents. Would it help if the IETF (and the authors of the RFC's) granted ITU rights of replication? Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 18:19:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12287 for ; Thu, 16 May 2002 18:19:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GM20t75664; Thu, 16 May 2002 15:02:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GM1bt75652 for ; Thu, 16 May 2002 15:01:37 -0700 (PDT) (envelope-from truskows@cisco.com) Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id PAA03095; Thu, 16 May 2002 15:16:46 -0700 (PDT) From: Mike Truskowski Message-Id: <200205162216.PAA03095@wells.cisco.com> Subject: Re: [Isis-wg] Message from the ITU To: tli@procket.com Cc: jonathan.sadler@tellabs.com, jparker@axiowave.com, isis-wg@spider.juniper.net In-Reply-To: <15588.11566.114030.664703@alpha-tli.procket.com> from Tony Li at May "16," 2002 "03:05:34" pm X-Mailer: ELM [] MIME-Version: 1.0 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@spider.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, 16 May 2002 15:16:44 -0700 (PDT) Content-Transfer-Encoding: 7bit Tony, This is why I requested Q14 to send a liaison to you. You have it correct.... In order to get the 3way handshake pointed at.. it must be on standard track or a STD. Same with everything else. I thought there was an agreement between the IETF and ITU so we didn't have to duplicate... but it seems it's only good at the STD level. Mike > > > Hi Jonathan, > > > | Since the work in the IETF on IS-IS is limited to achiving Informational > | status, the ITU will never be able to use an IETF RFC as a normative > | reference. > > > This comment struck me as curious. Are you saying that if IETF claimed to > pass standards on IS-IS and put these RFCs on the standards track, that the > ITU would be willing to reference them as Normative? > > What is the reason for not referencing Informational RFC's as normative? > They are fixed, published documents. > > Would it help if the IETF (and the authors of the RFC's) granted ITU > rights of replication? > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 19:04:11 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13408 for ; Thu, 16 May 2002 19:04:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GMl1t75879; Thu, 16 May 2002 15:47:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GMket75867 for ; Thu, 16 May 2002 15:46:40 -0700 (PDT) (envelope-from jonathan.sadler@tellabs.com) Received: from mailw02.hq.tellabs.com (mailw02.lisle.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint) with ESMTP id AGX71078; Thu, 16 May 2002 18:02:22 -0500 (CDT) Received: from tellabs.com (dhcp-172-23-111-24.lisle.tellabs.com [172.23.111.24]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id SAA23122; Thu, 16 May 2002 18:02:24 -0500 (CDT) Message-ID: <3CE43A44.C3123A0B@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li CC: Jeff Parker , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU References: 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@spider.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, 16 May 2002 18:01:24 -0500 Content-Transfer-Encoding: 7bit Tony - > | Since the work in the IETF on IS-IS is limited to achiving Informational > | status, the ITU will never be able to use an IETF RFC as a normative > | reference. > > This comment struck me as curious. Are you saying that if IETF claimed to > pass standards on IS-IS and put these RFCs on the standards track, that the > ITU would be willing to reference them as Normative? Correct. Per RFC 2026, Informational documents are not considered normative in the IETF. Witness the following: "Specifications that are intended to become Internet Standards evolve through a set of maturity levels known as the 'standards track'. These maturity levels -- 'Proposed Standard', 'Draft Standard', and 'Standard' -- are defined and discussed in section 4.1." --- (RFC2026, sec. 4) "Specifications that are not on the standards track are labeled with one of three 'off-track' maturity levels: 'Experimental', 'Informational', or 'Historic'. The documents bearing these labels are not Internet Standards in any sense." --- (RFC2026, sec. 4.2) > What is the reason for not referencing Informational RFC's as normative? > They are fixed, published documents. This is the policy specified by the IESG. The ITU is only respecting it. This is why I wish that the IS-IS working group could have its drafts achive Standards track. Then they would be available as normative references to other bodies, such as the ITU. Unfortunately, as I understand it, the IETF is sensative to JTC1's "ownership" of IS-IS and therefore the RFCs are limited to Informational status at best. > Would it help if the IETF (and the authors of the RFC's) granted ITU > rights of replication? That question would be best answered by the governing bodies in the ITU, not by me. However, it may provide a short-term work around as the text of an RFC could possibly be incorporated into an ITU recommendation. Personally, I'd rather see the long term problem solved -- specifically that IETF and JTC1 (and maybe also the ITU given G.7712v1.2 Appendix I and II) reach agreement on how extensions to IS-IS should be progressed. Jonathan Sadler ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 19:34:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14146 for ; Thu, 16 May 2002 19:34:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GNH0t76019; Thu, 16 May 2002 16:17:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4GNGRt76007 for ; Thu, 16 May 2002 16:16:27 -0700 (PDT) (envelope-from rja@extremenetworks.com) Received: from mosquito.inet.org (unknown [10.0.7.244]) by gnat.inet.org (Postfix) with ESMTP id 7D73C67103; Thu, 16 May 2002 20:03:09 -0400 (EDT) Subject: Re: [Isis-wg] Message from the ITU Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: isis-wg@spider.juniper.net To: jonathan.sadler@tellabs.com From: RJ Atkinson In-Reply-To: <3CE43A44.C3123A0B@tellabs.com> Message-Id: <209AF4B2-6925-11D6-AF0A-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 16 May 2002 19:32:03 -0400 Content-Transfer-Encoding: 7bit On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > This is why I wish that the IS-IS working group could have its drafts > achive Standards track. Then they would be available as normative > references to other bodies, such as the ITU. > > Unfortunately, as I understand it, the IETF is sensative to JTC1's > "ownership" of IS-IS and therefore the RFCs are limited to Informational > status at best. IETF has asked (formally) ANSI, who apparently really are the standards body for IS-IS under ISO (ANSI rather than JTC1) about handing over change control to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) reports that I hear are that ANSI either didn't respond or said "no we don't want to do that". IETF is not publishing IS-IS stuff as standards-track because change-control hasn't been handed over to IETF from ANSI. Consequently, I find this whole thread a bit confusing. Perhaps others also do. A fantasy that occurs to me right now would be to get the IETF IS-IS chairs, the applicable ANSI folks, the applicable JTC1 folks, and the applicable ITU-T folks all in the same room -- with a goal of trying to find some more productive process and path forwards for all of us. Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 16 21:36:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16627 for ; Thu, 16 May 2002 21:36:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H1J1t76555; Thu, 16 May 2002 18:19:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H1Ivt76543 for ; Thu, 16 May 2002 18:18:57 -0700 (PDT) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id SAA20637; Thu, 16 May 2002 18:34:35 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <25G836DG>; Thu, 16 May 2002 18:34:35 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3FA09@avalon.pluris.com> From: Les Ginsberg To: "'RJ Atkinson'" , jonathan.sadler@tellabs.com Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Message from the ITU 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@spider.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, 16 May 2002 18:34:30 -0700 Having worked on the ISO 10589:2001 draft within ISO, I would be very surprised to learn that ANSI thinks it owns the IS-IS spec. As far as I know it is owned by JTC1/SC6/WG7. More importantly, your mail states that the reason IS-IS WG drafts are on the Informational track is because the IETF does not own the IS-IS specification and therefore does not feel it in its purview to define extensions to the protocol which are "standards". If true, this would suggest that it is necessary that either: a)ISO have procedures to incorporate IS-IS WG RFCs into ISO documents b)IETF be empowered to issue IS-IS extensions which are standards c)IETF take ownership of the IS-IS standard Having spoken to both IETF and ISO leadership on this issue, I have no reason to think that any solution to this impasse acceptable to both sides has been offered. Given that we have even more compelling reasons now to want to fix this, I would hope that leadership on "all sides of the aisle" would find a way to make Ran's fantasy come true. Les > > > On Thursday, May 16, 2002, at 07:01 , Jonathan Sadler wrote: > > This is why I wish that the IS-IS working group could have > its drafts > > achive Standards track. Then they would be available as normative > > references to other bodies, such as the ITU. > > > > Unfortunately, as I understand it, the IETF is sensative to JTC1's > > "ownership" of IS-IS and therefore the RFCs are limited to > Informational > > status at best. > > IETF has asked (formally) ANSI, who apparently really are the > standards > body for IS-IS under ISO (ANSI rather than JTC1) about handing over > change control > to IETF. Anecdotal (i.e. unconfirmed, possibly wrong) reports that I > hear are > that ANSI either didn't respond or said "no we don't want to do that". > > IETF is not publishing IS-IS stuff as standards-track because > change-control hasn't been handed over to IETF from ANSI. > > Consequently, I find this whole thread a bit confusing. > Perhaps others > also do. > > A fantasy that occurs to me right now would be to get the IETF IS-IS > chairs, the applicable ANSI folks, the applicable JTC1 folks, and > the applicable ITU-T folks all in the same room -- with a goal of > trying to find some more productive process and path forwards > for all of us. > > Ran > rja@extremenetworks.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 06:10:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07000 for ; Fri, 17 May 2002 06:10:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H9r0t78766; Fri, 17 May 2002 02:53:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4H9qKt78754 for ; Fri, 17 May 2002 02:52:20 -0700 (PDT) (envelope-from christi@nortelnetworks.com) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HA7vZ04014; Fri, 17 May 2002 12:07:57 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HA7A222228; Fri, 17 May 2002 11:07:11 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 11:08:02 +0100 Message-ID: <4103264BC8D3D51180B7002048400C454FB6B7@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Mike Truskowski'" , tli@procket.com Cc: jonathan.sadler@tellabs.com, jparker@axiowave.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Message from the ITU MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FD8A.B9092CE8" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 17 May 2002 11:08:00 +0100 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_01C1FD8A.B9092CE8 Content-Type: text/plain; charset="iso-8859-1" Mike is quite right. In order to refer in a normative way to an RFC, it must be a standards track RFC. The ITU-T can make non-normative references to Informationals, such as "For more information see RFC..." But 3-way-handshake doesn't even have an RFC number. I don't think that an ITU-T document can refer to an Internet Draft at all, after all, six months later the the doc will deleted off of the server and it will be a dead URL. You cannot just take the text from an IETF doc and paste it in, as that would be against copyright laws. So that left me with just one option: I had to re-write the thing in my own words, and what a pain it was. That is the reason why I had to go through a major learning curve a few months back to understand extactly how the 3-way-handshake worked. Some of you will probably remember the stupid questions I kept asking about it :) I will certainly propose to put the RFC number in when 3-way gets one. In the mean time, yes, I suggest people have a good read of the 3-way-handshake and make sure I didn't mess up. Philip -----Original Message----- From: Mike Truskowski [mailto:truskows@cisco.com] Sent: Thursday, May 16, 2002 11:17 PM To: tli@procket.com Cc: jonathan.sadler@tellabs.com; jparker@axiowave.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU Tony, This is why I requested Q14 to send a liaison to you. You have it correct.... In order to get the 3way handshake pointed at.. it must be on standard track or a STD. Same with everything else. I thought there was an agreement between the IETF and ITU so we didn't have to duplicate... but it seems it's only good at the STD level. Mike > > > Hi Jonathan, > > > | Since the work in the IETF on IS-IS is limited to achiving Informational > | status, the ITU will never be able to use an IETF RFC as a normative > | reference. > > > This comment struck me as curious. Are you saying that if IETF claimed to > pass standards on IS-IS and put these RFCs on the standards track, that the > ITU would be willing to reference them as Normative? > > What is the reason for not referencing Informational RFC's as normative? > They are fixed, published documents. > > Would it help if the IETF (and the authors of the RFC's) granted ITU > rights of replication? > > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1FD8A.B9092CE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] Message from the ITU

Mike is quite right.

In order to refer in a normative way to an RFC, it = must be a standards track RFC.
The ITU-T can make non-normative references to = Informationals, such as "For more information see = RFC..."
But 3-way-handshake doesn't even have an RFC = number.
I don't think that an ITU-T document can refer to an = Internet Draft at all, after all, six months later the the doc will = deleted off of the server and it will be a dead URL.

You cannot just take the text from an IETF doc and = paste it in, as that would be against copyright laws.

So that left me with just one option: I had to = re-write the thing in my own words, and what a pain it was.

That is the reason why I had to go through a major = learning curve a few months back to understand extactly how the = 3-way-handshake worked. Some of you will probably remember the stupid = questions I kept asking about it :)

I will certainly propose to put the RFC number in = when 3-way gets one.
In the mean time, yes, I suggest people have a good = read of the 3-way-handshake and make sure I didn't mess up.

Philip




-----Original Message-----
From: Mike Truskowski [mailto:truskows@cisco.com]=
Sent: Thursday, May 16, 2002 11:17 PM
To: tli@procket.com
Cc: jonathan.sadler@tellabs.com; = jparker@axiowave.com;
isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Message from the ITU


Tony,
This is why I requested Q14 to send a liaison to = you. 

You have it correct....  In order to get the = 3way handshake
pointed at.. it must be on standard track or a = STD.  Same
with everything else.

I thought there was an agreement between the IETF and = ITU so
we didn't have to duplicate... but it seems it's = only good at
the STD level.

Mike

>
>
> Hi Jonathan,
>
>
>  | Since the work in the IETF on IS-IS is = limited to achiving Informational
>  | status, the ITU will never be able to = use an IETF RFC as a normative
>  | reference. 
>
>
> This comment struck me as curious.  Are = you saying that if IETF claimed to
> pass standards on IS-IS and put these RFCs on = the standards track, that the
> ITU would be willing to reference them as = Normative?
>
> What is the reason for not referencing = Informational RFC's as normative?
> They are fixed, published documents.
>
> Would it help if the IETF (and the authors of = the RFC's) granted ITU
> rights of replication?
>
> Tony
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>

_______________________________________________
Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg=

------_=_NextPart_001_01C1FD8A.B9092CE8-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 10:00:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14268 for ; Fri, 17 May 2002 10:00:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HDc4t80216; Fri, 17 May 2002 06:38:04 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HDbSt80204 for ; Fri, 17 May 2002 06:37:28 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Les Ginsberg'" Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Message from the ITU MIME-Version: 1.0 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@spider.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, 17 May 2002 09:52:31 -0400 Having had none of the experience that Les has had, and none of the insight that the Tony's have into the IETF inner workings, here is a proposal unencumbered by any information. 1) IETF 'owns' (we need a better term, but I think we know what this means) IP issues, such as 2966. 2) JTC1 'owns' all pure OSI issues, and some (most?) of the link layer. 3) Issues such as 3-way handshake need to be worked by both sides. This could involve working through the document in IETF (ITU) and then forwarding it -before- it is frozen, to the ITU (IETF) for further massaging. 4) Some rules on who is working on what, and some oversight is needed to bang the pipes when something gets wedged and cannot advance. Some method must be provided to fast track documents that all agree upon. - jeff parker > Having worked on the ISO 10589:2001 draft within ISO, I would be very > surprised to learn that ANSI thinks it owns the IS-IS spec. > As far as I know it is owned by JTC1/SC6/WG7. > ... > Les _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 10:47:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16206 for ; Fri, 17 May 2002 10:47:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HEU1t80448; Fri, 17 May 2002 07:30:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HET4t80433 for ; Fri, 17 May 2002 07:29:04 -0700 (PDT) (envelope-from truskows@cisco.com) Received: (truskows@localhost) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id HAA26414; Fri, 17 May 2002 07:44:14 -0700 (PDT) From: Mike Truskowski Message-Id: <200205171444.HAA26414@wells.cisco.com> Subject: Re: [Isis-wg] Message from the ITU To: jparker@axiowave.com Cc: ginsberg@pluris.com, isis-wg@spider.juniper.net In-Reply-To: from Jeff Parker at May "17," 2002 "09:52:31" am X-Mailer: ELM [] MIME-Version: 1.0 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@spider.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, 17 May 2002 07:44:14 -0700 (PDT) Content-Transfer-Encoding: 7bit Jeff, It's a good "start". But it doesn't nail the door open. Mike > Having had none of the experience that Les has had, and > none of the insight that the Tony's have into the IETF > inner workings, here is a proposal unencumbered by > any information. > > 1) IETF 'owns' (we need a better term, but I think > we know what this means) IP issues, such as 2966. > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > of the link layer. > > 3) Issues such as 3-way handshake need to be worked > by both sides. This could involve working through > the document in IETF (ITU) and then forwarding it > -before- it is frozen, to the ITU (IETF) for further > massaging. > > 4) Some rules on who is working on what, and some > oversight is needed to bang the pipes when something > gets wedged and cannot advance. Some method must be > provided to fast track documents that all agree upon. > > - jeff parker > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > As far as I know it is owned by JTC1/SC6/WG7. > > ... > > Les > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 12:40:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20086 for ; Fri, 17 May 2002 12:40:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HGM6t80917; Fri, 17 May 2002 09:22:06 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HGLIt80905 for ; Fri, 17 May 2002 09:21:18 -0700 (PDT) (envelope-from jonathan.sadler@tellabs.com) Received: from mailw02.hq.tellabs.com (mailw02.lisle.tellabs.com [172.23.207.12]) by mx4.tellabs.com (Mirapoint) with ESMTP id AGX93792; Fri, 17 May 2002 11:37:04 -0500 (CDT) Received: from tellabs.com (dhcp-172-23-111-24.lisle.tellabs.com [172.23.111.24]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id LAA08494; Fri, 17 May 2002 11:37:04 -0500 (CDT) Message-ID: <3CE531AF.990A3C9F@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "'Les Ginsberg'" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU References: 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@spider.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, 17 May 2002 11:37:03 -0500 Content-Transfer-Encoding: 7bit Jeff - Comments inline... Jonathan Sadler Jeff Parker wrote: > > Having had none of the experience that Les has had, and > none of the insight that the Tony's have into the IETF > inner workings, here is a proposal unencumbered by > any information. > > 1) IETF 'owns' (we need a better term, but I think > we know what this means) IP issues, such as 2966. > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > of the link layer. > > 3) Issues such as 3-way handshake need to be worked > by both sides. This could involve working through > the document in IETF (ITU) and then forwarding it > -before- it is frozen, to the ITU (IETF) for further > massaging. Actually, it is three-sides, not both sides. JTC1 and the ITU are not related, just as ITU and the IETF are not related. JTC1 is a joint committee of ISO and IEC. Even if the IETF and ITU work things out (which I think is quite possible -- there is enough open-minded thinking in both groups), we need JTC1 to also be a party to the agreement. > 4) Some rules on who is working on what, and some > oversight is needed to bang the pipes when something > gets wedged and cannot advance. Some method must be > provided to fast track documents that all agree upon. > > - jeff parker > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > As far as I know it is owned by JTC1/SC6/WG7. > > ... > > Les > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 12:55:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20706 for ; Fri, 17 May 2002 12:55:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HGc1t81003; Fri, 17 May 2002 09:38:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HGbht80991 for ; Fri, 17 May 2002 09:37:43 -0700 (PDT) (envelope-from jharper@cisco.com) Received: from JHARPER-W2K1.cisco.com (dhcp-128-107-211-99.cisco.com [128.107.211.99]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA12156; Fri, 17 May 2002 17:52:21 +0100 (BST) Message-Id: <4.3.2.7.2.20020517094705.03da18f8@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: jonathan.sadler@tellabs.com From: John Harper Subject: Re: [Isis-wg] Message from the ITU Cc: Jeff Parker , "'Les Ginsberg'" , isis-wg@spider.juniper.net In-Reply-To: <3CE531AF.990A3C9F@tellabs.com> References: 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@spider.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, 17 May 2002 09:52:32 -0700 I've been following this and trying to resist jumping in, but I guess I just failed... I don't understand why this matters. Regardless of what ITU or JTC1 think, the handful of vendors who are supplying this protocol all know where the action is. Maybe there are some marginal vendors or wannabes who believe they can influence things through the ITU, but I'd be pretty surprised if they were to succeed. I don't believe JTC1 will ever give this up, for the simple reason that it is just about the only thing that gives WG7 any reason to continue to exist. (When I quit as chair of WG2, the predecessor of WG7, in 1992, it was because I really didn't see that there was anything useful left to be done in that forum. 10 years later, I don't see any reason to believe I was wrong). John At 11:37 17/05/2002 -0500, Jonathan Sadler wrote: >Jeff - > >Comments inline... > >Jonathan Sadler > >Jeff Parker wrote: > > > > Having had none of the experience that Les has had, and > > none of the insight that the Tony's have into the IETF > > inner workings, here is a proposal unencumbered by > > any information. > > > > 1) IETF 'owns' (we need a better term, but I think > > we know what this means) IP issues, such as 2966. > > > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > > of the link layer. > > > > 3) Issues such as 3-way handshake need to be worked > > by both sides. This could involve working through > > the document in IETF (ITU) and then forwarding it > > -before- it is frozen, to the ITU (IETF) for further > > massaging. > >Actually, it is three-sides, not both sides. JTC1 and the ITU are not >related, just as ITU and the IETF are not related. JTC1 is a joint >committee of ISO and IEC. > >Even if the IETF and ITU work things out (which I think is quite >possible -- there is enough open-minded thinking in both groups), we >need JTC1 to also be a party to the agreement. > > > 4) Some rules on who is working on what, and some > > oversight is needed to bang the pipes when something > > gets wedged and cannot advance. Some method must be > > provided to fast track documents that all agree upon. > > > > - jeff parker > > > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > > As far as I know it is owned by JTC1/SC6/WG7. > > > ... > > > Les > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > http://spider.juniper.net/mailman/listinfo/isis-wg >============================================================ >The information contained in this message may be privileged >and confidential and protected from disclosure. If the >reader of this message is not the intended recipient, or an >employee or agent responsible for delivering this message to >the intended recipient, you are hereby notified that any >reproduction, dissemination or distribution of this >communication is strictly prohibited. If you have received >this communication in error, please notify us immediately by >replying to the message and deleting it from your computer. > >Thank you. >Tellabs >============================================================ >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 13:07:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21295 for ; Fri, 17 May 2002 13:07:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HGo1t81076; Fri, 17 May 2002 09:50:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HGnJt81061 for ; Fri, 17 May 2002 09:49:19 -0700 (PDT) (envelope-from prz@redback.com) Received: from redback.com ([63.200.50.2]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GW900HS1M4JW3@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Fri, 17 May 2002 10:05:07 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Message from the ITU To: Philip Christian Cc: "'Mike Truskowski'" , tli@procket.com, jonathan.sadler@tellabs.com, jparker@axiowave.com, isis-wg@spider.juniper.net Reply-to: prz@redback.com Message-id: <3CE501A2.4D6E656C@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <4103264BC8D3D51180B7002048400C454FB6B7@zhard0jd.europe.nortel.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 17 May 2002 06:12:02 -0700 Content-Transfer-Encoding: 7BIT Philip Christian wrote: > > > Mike is quite right. > > In order to refer in a normative way to an RFC, it must be a standards track RFC. > The ITU-T can make non-normative references to Informationals, such as "For more information > see RFC..." > But 3-way-handshake doesn't even have an RFC number. will have, things are on their way fine ... > The IESG has received a request from the IS-IS for IP Internets Working > Group to consider Three-Way Handshake for IS-IS Point-to-Point > Adjacencies as an Informational RFC. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by May 20, 2002. > > You cannot just take the text from an IETF doc and paste it in, as that would be against > copyright laws. touchy point thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 13:18:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21843 for ; Fri, 17 May 2002 13:18:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HH11t81152; Fri, 17 May 2002 10:01:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HH04t81139 for ; Fri, 17 May 2002 10:00:04 -0700 (PDT) (envelope-from prz@redback.com) Received: from redback.com ([63.200.50.2]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GW90042NMMCFZ@mta7.pltn13.pbi.net> for isis-wg@spider.juniper.net; Fri, 17 May 2002 10:15:48 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Message from the ITU To: John Harper Cc: jonathan.sadler@tellabs.com, Jeff Parker , "'Les Ginsberg'" , isis-wg@spider.juniper.net Reply-to: prz@redback.com Message-id: <3CE50423.9CC8DECB@redback.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <4.3.2.7.2.20020517094705.03da18f8@jaws.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 17 May 2002 06:22:43 -0700 Content-Transfer-Encoding: 7BIT John Harper wrote: > I've been following this and trying to resist jumping in, but I guess > I just failed... > > I don't understand why this matters. Regardless of what ITU or JTC1 > think, the handful of vendors who are supplying this protocol all know > where the action is. Maybe there are some marginal vendors or > wannabes who believe they can influence things through the ITU, > but I'd be pretty surprised if they were to succeed. > > I don't believe JTC1 will ever give this up, for the simple reason > that it is just about the only thing that gives WG7 any reason to > continue to exist. (When I quit as chair of WG2, the predecessor > of WG7, in 1992, it was because I really didn't see that there > was anything useful left to be done in that forum. 10 years later, I don't see > any reason to believe I was wrong). All those are interesting points to be taken and I appreciate some of the light these mails shed on the history of things and inner clockworks. _Nevertheless_ 1) please this should not become any kind of flames & jell-o-throwing thread from hell. Any derogatory or pejorative comments vs. IETF workings, WG7, JTC1 or whatever other entity involved is probably uncalled for. I do not want to be 'soup-nazi' but airing dirty laundry on such lists never did anything good to anyone. This things are better solved in constructive ways behind and not in front of the peanut-gallery. That leads me to a more important reason 2) this is a _technical_ mailing list. We are here to get _work done_, not get sucked into petty politics. If ITU wants to reference those documents, some constructive way may or may not be found but these should not congest these mailing list with 99.9% political/subjective mails. this said, nose to the grindstone of technical issues or please constructive proposals as of how to accomodate all the parties involved (a la Jeff Parker) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 13:34:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22873 for ; Fri, 17 May 2002 13:34:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHH1t81243; Fri, 17 May 2002 10:17:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHGQt81226 for ; Fri, 17 May 2002 10:16:26 -0700 (PDT) (envelope-from prz@net4u.ch) Received: from net4u.ch ([63.200.50.2]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GW900H5GNDPY9@mta5.snfc21.pbi.net> for isis-wg@spider.juniper.net; Fri, 17 May 2002 10:32:14 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] Message from the ITU To: prz@redback.com Cc: John Harper , jonathan.sadler@tellabs.com, Jeff Parker , "'Les Ginsberg'" , isis-wg@spider.juniper.net Message-id: <3CE547B2.3010401@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <4.3.2.7.2.20020517094705.03da18f8@jaws.cisco.com> <3CE50423.9CC8DECB@redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 17 May 2002 11:10:58 -0700 Content-Transfer-Encoding: 7BIT Tony Przygienda wrote: >John Harper wrote: > >>I've been following this and trying to resist jumping in, but I guess >>I just failed... >> >>I don't understand why this matters. Regardless of what ITU or JTC1 >>think, the handful of vendors who are supplying this protocol all know >>where the action is. Maybe there are some marginal vendors or >>wannabes who believe they can influence things through the ITU, >>but I'd be pretty surprised if they were to succeed. >> >>I don't believe JTC1 will ever give this up, for the simple reason >>that it is just about the only thing that gives WG7 any reason to >>continue to exist. (When I quit as chair of WG2, the predecessor >>of WG7, in 1992, it was because I really didn't see that there >>was anything useful left to be done in that forum. 10 years later, I don't see >>any reason to believe I was wrong). >> > >All those are interesting points to be taken and I appreciate some >of the light these mails shed on the history of things and inner >clockworks. _Nevertheless_ > >1) please this should not become any kind of flames & jell-o-throwing > thread from hell. Any derogatory or pejorative comments vs. IETF > workings, WG7, JTC1 or whatever other entity involved is probably > uncalled for. I do not want to be 'soup-nazi' but airing dirty laundry > on such lists never did anything good to anyone. This things are better > solved in constructive ways behind and not in front of the peanut-gallery. > That leads me to a more important reason >2) this is a _technical_ mailing list. We are here to get _work done_, not > get sucked into petty politics. If ITU wants to reference those documents, > some constructive way may or may not be found but these should not > congest these mailing list with 99.9% political/subjective mails. > >this said, nose to the grindstone of technical issues or please constructive >proposals as of how to accomodate all the parties involved (a la Jeff Parker) > On a lighter note and a 2nd reading of my answer: I have a bout with flu here and that seems to have affected my ability to distinguish 'this' and 'these' seriously beside hitting the area of the brain governing the use of prepositions sorry for that -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 13:36:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23003 for ; Fri, 17 May 2002 13:36:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHI1t81271; Fri, 17 May 2002 10:18:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mx3.tellabs.com (mx3.tellabs.com [204.68.180.53]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHHFt81249 for ; Fri, 17 May 2002 10:17:15 -0700 (PDT) (envelope-from jonathan.sadler@tellabs.com) Received: from mailw02.hq.tellabs.com (mailw02.lisle.tellabs.com [172.23.207.12]) by mx3.tellabs.com (Mirapoint) with ESMTP id AFR59699; Fri, 17 May 2002 12:31:45 -0500 (CDT) Received: from tellabs.com (dhcp-172-23-111-24.lisle.tellabs.com [172.23.111.24]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id MAA23535; Fri, 17 May 2002 12:31:33 -0500 (CDT) Message-ID: <3CE53E74.2ABF4DEF@tellabs.com> From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Harper CC: Jeff Parker , "'Les Ginsberg'" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU References: 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@spider.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, 17 May 2002 12:31:32 -0500 Content-Transfer-Encoding: 7bit John - Let me step back and put this all into perspective. I agree that there is valuable work going on in the IETF IS-IS WG. And because of this valuable work, other standards bodies (such as ITU) want to be able to reference the work. However, because the policy of the IESG is that RFCs with Informational status are not normative, these other standards bodies are unable to reference them. So what can be done? I can see a few options, some of which Les already mentioned: 1) Make Informational status normative. This would allow the ITU to reference IS-IS WG RFCs. However, this is not likely to happen as it basically allows anyone to write an Internet Standard without the IETF development process being involved. (Informational status documents are not required to go through the same rigor as Standards track documents.) 2) Move for IS-IS WG RFCs to be Standards track without rectifying the situation with JTC1. This also would allow the ITU to reference IS-IS WG RFCs. However, this has thorny side effects due to the fact that in the eyes of the IESG, JTC1 owns IS-IS, not the IETF. 3) Reach agreement with JTC1 on how IETF developed IS-IS extensions are handled. This could be: a) JTC1 progresses them to standard b) JTC1 allows IETF to progess them to standard, but retains IS-IS ownership and therefore may have "veto power" c) JTC1 gets out of the IS-IS business allowing the IETF to progress them to standard. I understand your sentament about how JTC1 is only relevant in the area of IS-IS if we allow them to be relevant. However, that issue is one for the IESG to handle. If they determine that JTC1 is no longer relevant, then option 2 above would be possible. Jonathan Sadler John Harper wrote: > > I've been following this and trying to resist jumping in, but I guess > I just failed... > > I don't understand why this matters. Regardless of what ITU or JTC1 > think, the handful of vendors who are supplying this protocol all know > where the action is. Maybe there are some marginal vendors or > wannabes who believe they can influence things through the ITU, > but I'd be pretty surprised if they were to succeed. > > I don't believe JTC1 will ever give this up, for the simple reason > that it is just about the only thing that gives WG7 any reason to > continue to exist. (When I quit as chair of WG2, the predecessor > of WG7, in 1992, it was because I really didn't see that there > was anything useful left to be done in that forum. 10 years later, I don't see > any reason to believe I was wrong). > > John > > At 11:37 17/05/2002 -0500, Jonathan Sadler wrote: > >Jeff - > > > >Comments inline... > > > >Jonathan Sadler > > > >Jeff Parker wrote: > > > > > > Having had none of the experience that Les has had, and > > > none of the insight that the Tony's have into the IETF > > > inner workings, here is a proposal unencumbered by > > > any information. > > > > > > 1) IETF 'owns' (we need a better term, but I think > > > we know what this means) IP issues, such as 2966. > > > > > > 2) JTC1 'owns' all pure OSI issues, and some (most?) > > > of the link layer. > > > > > > 3) Issues such as 3-way handshake need to be worked > > > by both sides. This could involve working through > > > the document in IETF (ITU) and then forwarding it > > > -before- it is frozen, to the ITU (IETF) for further > > > massaging. > > > >Actually, it is three-sides, not both sides. JTC1 and the ITU are not > >related, just as ITU and the IETF are not related. JTC1 is a joint > >committee of ISO and IEC. > > > >Even if the IETF and ITU work things out (which I think is quite > >possible -- there is enough open-minded thinking in both groups), we > >need JTC1 to also be a party to the agreement. > > > > > 4) Some rules on who is working on what, and some > > > oversight is needed to bang the pipes when something > > > gets wedged and cannot advance. Some method must be > > > provided to fast track documents that all agree upon. > > > > > > - jeff parker > > > > > > > Having worked on the ISO 10589:2001 draft within ISO, I would be very > > > > surprised to learn that ANSI thinks it owns the IS-IS spec. > > > > As far as I know it is owned by JTC1/SC6/WG7. > > > > ... > > > > Les > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@spider.juniper.net > > > http://spider.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@spider.juniper.net > >http://spider.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 13:39:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23170 for ; Fri, 17 May 2002 13:39:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHM1t81307; Fri, 17 May 2002 10:22:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from psg.com (psg.com [147.28.0.62]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHLVt81295 for ; Fri, 17 May 2002 10:21:31 -0700 (PDT) (envelope-from zinin@psg.com) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 178lfL-0003Mg-00 for isis-wg@spider.juniper.net; Fri, 17 May 2002 10:37:19 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <984354416.20020517103606@psg.com> To: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Message from the ITU In-Reply-To: <3CE531AF.990A3C9F@tellabs.com> References: <3CE531AF.990A3C9F@tellabs.com> MIME-Version: 1.0 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@spider.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, 17 May 2002 10:36:06 -0700 Content-Transfer-Encoding: 7bit Folks, Some clarifications on the formal version of the current situation here. Whether we like it or not: 1. ISO does own the IS-IS spec. 2. The IETF ISIS WG produces protocol mechanisms as recommendations to ISO that are also published in the IETF as informational to let the community know what has been recommended. 3. Other standards bodies cannot have a normative reference to IETF informational documents in their standards as this could easily be used to end-run around the standards process. The question of working out an agreement between IETF and ISO to have a clear and documented understanding on what IETF can and cannot do is on the plate that Bill and I share. Alex Zinin _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 14:19:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25380 for ; Fri, 17 May 2002 14:19:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HI06t81545; Fri, 17 May 2002 11:00:06 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from dmz2.procket.com (dmz2.procket.com [65.174.124.37]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HHxct81527 for ; Fri, 17 May 2002 10:59:38 -0700 (PDT) (envelope-from tli@procket.com) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 0C6C334430 for ; Fri, 17 May 2002 11:20:28 -0700 (PDT) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g4HIFKvM026988 for ; Fri, 17 May 2002 11:15:20 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g4HIFKYg013460; Fri, 17 May 2002 11:15:20 -0700 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15589.18616.724037.654205@alpha-tli.procket.com> To: isis-wg@spider.juniper.net X-Mailer: VM 6.92 under Emacs 20.5.1 Subject: [Isis-wg] A thought... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 17 May 2002 11:15:20 -0700 Content-Transfer-Encoding: 7bit Would anyone object if we started simply moving documents forward as standards track? This would mean being 'rude' to ISO, but since being 'nice' seems to be backfiring... Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 15:09:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28325 for ; Fri, 17 May 2002 15:09:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HIp6t81872; Fri, 17 May 2002 11:51:06 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HIoPt81860 for ; Fri, 17 May 2002 11:50:26 -0700 (PDT) (envelope-from jharper@cisco.com) Received: from JHARPER-W2K1.cisco.com (sj-dial-1-129.cisco.com [171.68.179.130]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA17415; Fri, 17 May 2002 20:05:45 +0100 (BST) Message-Id: <4.3.2.7.2.20020517120524.03db8ee8@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Li From: John Harper Subject: Re: [Isis-wg] A thought... Cc: isis-wg@spider.juniper.net In-Reply-To: <15589.18616.724037.654205@alpha-tli.procket.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@spider.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, 17 May 2002 12:05:33 -0700 Sure makes sense to me... John At 11:15 17/05/2002 -0700, Tony Li wrote: >Would anyone object if we started simply moving documents forward as >standards track? This would mean being 'rude' to ISO, but since being >'nice' seems to be backfiring... > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 16:18:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02625 for ; Fri, 17 May 2002 16:18:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HJq0t82200; Fri, 17 May 2002 12:52:00 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from psg.com (psg.com [147.28.0.62]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4HJput82188 for ; Fri, 17 May 2002 12:51:56 -0700 (PDT) (envelope-from zinin@psg.com) Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 178o0u-00062S-00; Fri, 17 May 2002 13:07:44 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <4713380106.20020517130630@psg.com> To: Tony Li CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] A thought... In-Reply-To: <15589.18616.724037.654205@alpha-tli.procket.com> References: <15589.18616.724037.654205@alpha-tli.procket.com> MIME-Version: 1.0 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@spider.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, 17 May 2002 13:06:30 -0700 Content-Transfer-Encoding: 7bit Tony, I have reasons to suspect that this will not fly by the IESG. As IETF wouldn't like any other standards body to modify IETF standards, the IESG would unlikely support putting a document affecting another body's standard on the IETF standards track. We could consider standardizing IP-specific extensions (as in the case of 1195), but I would suggest that we stick with the current scheme until we have had a conversation with ISO. After that we can reevaluate the WG documents (including Informational RFCs) and see if we want to push some of them to standards. -- Alex Friday, May 17, 2002, 11:15:20 AM, you wrote: > Would anyone object if we started simply moving documents forward as > standards track? This would mean being 'rude' to ISO, but since being > 'nice' seems to be backfiring... > Tony > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri May 17 21:43:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17358 for ; Fri, 17 May 2002 21:43:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4I1Q1t83540; Fri, 17 May 2002 18:26:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4I1P6t83528 for ; Fri, 17 May 2002 18:25:06 -0700 (PDT) (envelope-from rja@extremenetworks.com) Received: from mosquito.inet.org (unknown [10.0.8.129]) by gnat.inet.org (Postfix) with ESMTP id E2A4767103; Fri, 17 May 2002 22:11:48 -0400 (EDT) Subject: Re: [Isis-wg] Message from the ITU Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: John Harper , Jeff Parker , "'Les Ginsberg'" , isis-wg@spider.juniper.net To: jonathan.sadler@tellabs.com From: RJ Atkinson In-Reply-To: <3CE53E74.2ABF4DEF@tellabs.com> Message-Id: <3E4551DE-6A00-11D6-85CC-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 17 May 2002 21:40:33 -0400 Content-Transfer-Encoding: 7bit On Friday, May 17, 2002, at 01:31 , Jonathan Sadler wrote: > However, because the policy of the IESG is that RFCs with Informational > status are not normative, these other standards bodies are unable to > reference them. Actually, that puts the cart in front of the horse. Some standards bodies have no problem referencing Informational RFCs as normative (realising that they aren't IETF standards) in their own contexts. So it isn't IESG policy, but the policies of (ITU, JTC1, ISO, or whoever) about what they will adopt by reference that is the hindrance here. Ran _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 21 07:50:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05595 for ; Tue, 21 May 2002 07:50:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4LBT4t07906; Tue, 21 May 2002 04:29:04 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4LBSOt07894 for ; Tue, 21 May 2002 04:28:24 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g4LBiZX25173 for ; Tue, 21 May 2002 04:44:36 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 21 May 2002 04:30:30 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05088; Tue, 21 May 2002 07:31:36 -0400 (EDT) Message-Id: <200205211131.HAA05088@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 X-OriginalArrivalTime: 21 May 2002 11:30:30.0905 (UTC) FILETIME=[E9F7E690:01C200BA] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 21 May 2002 07:31:36 -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 : Recommendations for Interoperable IP Networks using IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-interoperable-00.txt Pages : 19 Date : 20-May-02 'The difference between theory and practice is greater in practice than it is in theory.' (Author unknown) This document discusses a number of differences between the IS-IS protocol as described in ISO 10589 [1] and RFC 1195 [3] and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-interoperable-00.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-interoperable-00.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: <20020520150743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-interoperable-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-interoperable-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020520150743.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 21 10:12:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11263 for ; Tue, 21 May 2002 10:12:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4LDpht08607; Tue, 21 May 2002 06:51:43 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4LDkht08578 for ; Tue, 21 May 2002 06:46:43 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "IS-IS-WG (E-mail)" Subject: FW: [Isis-wg] I-D ACTION:draft-ietf-isis-interoperable-00.txt MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C200D0.30303B20" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 21 May 2002 10:02:48 -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_01C200D0.30303B20 Content-Type: text/plain; charset="iso-8859-1" A small, but very active, subgroup of the WG has been working on this document for the last month. We considered a larger set of issues, and decided not to pursue some. A brief description of those issues is included in the attached document, remaining.dos. Suggestions and edits always welcome: we are still actively revising the last section, on checking the Source ID on point-to-point IIH packets. - jeff parker > 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 : Recommendations for Interoperable IP > Networks using > IS-IS > Author(s) : J. Parker > Filename : draft-ietf-isis-interoperable-00.txt > Pages : 19 > Date : 20-May-02 > > 'The difference between theory and practice is greater in > practice than it is in theory.' (Author unknown) > This document discusses a number of differences between the IS-IS > protocol as described in ISO 10589 [1] and RFC 1195 [3] and the > protocol as it is deployed today. These differences are discussed as > a service to those implementing, testing, and deploying the IS-IS > Protocol to route IP traffic. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-00.txt ------_=_NextPart_000_01C200D0.30303B20 Content-Type: text/plain; name="remaining.dos.txt" Content-Disposition: attachment; filename="remaining.dos.txt" Remaining issues 1) 1195 says you set the aggregated metric to the max. metric of aggregated prefixes. There are different algorithms to decide the metric for a summary route. We could use the max, min, or a configured metric. As long as more specific routes are visible and everyone has the same information, the choice of policy will not affect network stability. 2) Documentation of "alternate forms" of route selection (?) The original topic was the "8 bit" metric. Discussion has suggested that this was a bug that has been fixed, and does not need to be further documented. Note that RFC 2966 has a good discussion about how to compare different metrics. 3) Rules for advertising reachability information Redistributed routes (deprecate external metric) Directly attached routes The redistibution of routes from one protocol to another is often controlled by policy. As long as routers don't originate routes that they don't use, the network should be able to produce consistent routing tables. 4) A description of flooding the new way (with per circuit flooding parameters, inter-LSP gaps, etc). Originally LSP transmission throttling was only defined for LAN circuits, but most implementation now provide it for pt-pt circuits as well. The throttling is to do with the total LSP transmission rate of all LSPs (new or re-transmissions) over a particular circuit. minLSPtransInt is to do with the re-transmission rate of a particular LSP. Mike [Shand] ------_=_NextPart_000_01C200D0.30303B20-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 23 14:17:48 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21547 for ; Thu, 23 May 2002 14:17:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NHuQt24605; Thu, 23 May 2002 10:56:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NHlnt24559 for ; Thu, 23 May 2002 10:47:49 -0700 (PDT) (envelope-from joyal@lucent.com) Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4NI4E722750 for ; Thu, 23 May 2002 14:04:14 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 14:04:13 -0400 Message-ID: From: "Joyal, Daniel R (Daniel)" To: "IS-IS-WG (E-mail)" 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 MIB Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 23 May 2002 14:04:08 -0400 Hi Jeff, There's a couple things I couldn't find in the IS-IS MIB. I don't know if I overlooked them or whether they are defined in some other MIB. Specifically, I couldn't find a System ID to Hostname mapping table per RFC 2763 and I couldn't find tables for the L1 and L2 LSP databases (analagous to the OSPF LSDB tables). Can you point me in the right direction? Thanks. -Dan _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 23 14:51:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22816 for ; Thu, 23 May 2002 14:51:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NIV8t24788; Thu, 23 May 2002 11:31:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NILTt24730 for ; Thu, 23 May 2002 11:21:29 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Joyal, Daniel R (Daniel)'" , "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB MIME-Version: 1.0 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@spider.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, 23 May 2002 14:37:38 -0400 > Hi Jeff, > > There's a couple things I couldn't find in the > IS-IS MIB. I don't know if I overlooked them or > whether they are defined in some other MIB. Specifically, > I couldn't find a System ID to Hostname mapping table > per RFC 2763 and I couldn't find tables for the L1 > and L2 LSP databases (analagous to the OSPF LSDB tables). > Can you point me in the right direction? > > Thanks. > -Dan Dan - Neither of those have been implemented in the ISIS mib as it exists today. I will put this on my mib to-do list. Any objectors, speak up now. The mib was recently rev'd, but there is other pending work to reorganize the system and circuit counters. In your work on the OSPF mib, did you find access to the LSAs to be useful? Those are big uninterpreted octet strings, much longer than the usual 255 bytes. It is good to have an SNMP maven looking things over. Please let me know about issues you see, and problems we might have moving through the official wickets. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 23 16:58:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27030 for ; Thu, 23 May 2002 16:58:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NK28t25272; Thu, 23 May 2002 13:02:08 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NJlwt25191 for ; Thu, 23 May 2002 12:47:58 -0700 (PDT) (envelope-from joyal@lucent.com) Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4NK4Nw09314 for ; Thu, 23 May 2002 16:04:24 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 16:04:23 -0400 Message-ID: From: "Joyal, Daniel R (Daniel)" To: "'Jeff Parker'" , "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB 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@spider.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, 23 May 2002 16:04:20 -0400 -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Thursday, May 23, 2002 2:38 PM To: 'Joyal, Daniel R (Daniel)'; IS-IS-WG (E-mail) Subject: RE: [Isis-wg] IS-IS MIB >> Hi Jeff, >> >> There's a couple things I couldn't find in the >> IS-IS MIB. I don't know if I overlooked them or >> whether they are defined in some other MIB. Specifically, >> I couldn't find a System ID to Hostname mapping table >> per RFC 2763 and I couldn't find tables for the L1 >> and L2 LSP databases (analagous to the OSPF LSDB tables). >> Can you point me in the right direction? >> >> Thanks. >> -Dan > >Dan - > Neither of those have been implemented in >the ISIS mib as it exists today. I will put >this on my mib to-do list. Any objectors, >speak up now. > > The mib was recently rev'd, but there >is other pending work to reorganize the >system and circuit counters. > In your work on the OSPF mib, did you find >access to the LSAs to be useful? Those are >big uninterpreted octet strings, much longer >than the usual 255 bytes. The OSPF LSDB table structure has been around a long time. The tables break out the header information into separate objects and define a single object for the entire LSA (header and contents). If the LSA gets 'too big', an SNMP agent may not be able to satisfy a get/getnext request for the LSA object. It's probably reasonable to at least define L1 and L2 LSP Header tables. A more complex implementation could break out LSPs' TLVs into separate per LSP TLV tables to enable the entire LSP to be retrieved in pieces. -Dan > > It is good to have an SNMP maven looking >things over. Please let me know about issues >you see, and problems we might have moving through >the official wickets. > >- jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 23 17:19:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27705 for ; Thu, 23 May 2002 17:19:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NKwWt25528; Thu, 23 May 2002 13:58:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4NK0Bt25257 for ; Thu, 23 May 2002 13:00:11 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Joyal, Daniel R (Daniel)'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB MIME-Version: 1.0 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@spider.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, 23 May 2002 16:16:31 -0400 > > In your work on the OSPF mib, did you find > >access to the LSAs to be useful? Those are > >big uninterpreted octet strings, much longer > >than the usual 255 bytes. > > The OSPF LSDB table structure has been around a long time. > The tables break out the header information > into separate objects and define a single object > for the entire LSA (header and contents). If the > LSA gets 'too big', an SNMP agent may not be able to > satisfy a get/getnext request for the LSA object. > > It's probably reasonable to at least define L1 and L2 > LSP Header tables. A more complex implementation could > break out LSPs' TLVs into separate per LSP TLV tables > to enable the entire LSP to be retrieved in pieces. > > -Dan Dan - Can we rewind that, please? I think you are reminding me of why this was a problem in the first place. An agent may not be able to satisfy a get request for the LSA object? Is this due to a small SNMP buffer size and the lack of a defined way to fragment payload? If an IS has two non-pnode LSPs, one of them is bound to be over 1K. If this is too big, we have a problem. We could split this into globs in the mib, but there is no natural way to do this, other than "first glob, second glob" etc. I am uncomfortable with splitting this into tables based on the type, as I suspect this will mask issues that we might see. I admit that the order shouldn't matter, as long as we know which fragment a TLV sat in. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 27 02:50:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13105 for ; Mon, 27 May 2002 02:50:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R6R1t51235; Sun, 26 May 2002 23:27:01 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail.lge.co.kr (mail.lge.co.kr [156.147.1.150]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R6JCt51194 for ; Sun, 26 May 2002 23:19:13 -0700 (PDT) (envelope-from yjim@lge.com) Received: from lgekrhqmh01.lge.com (lgekrhqmh01.lge.com [156.147.51.51]) by mail.lge.co.kr (8.11.3/8.11.3) with ESMTP id g4R6W4E29642 for ; Mon, 27 May 2002 15:32:05 +0900 (KST) Received: from yongjuni ([150.150.140.59]) by lgekrhqmh01.lge.com (Lotus Domino Release 5.07a) with SMTP id 2002052715071055:1696321 ; Mon, 27 May 2002 15:07:10 +0900 Message-ID: <025301c20544$fce905c0$3b8c9696@lge.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: Organization: LG Electronics, Inc. MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MIMETrack: Itemize by SMTP Server on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 03:07:10 PM, Serialize by Router on LGEKRHQMH01/LGE/LG Group(Release 5.07a |May 14, 2001) at 05/27/2002 03:37:42 PM, Serialize complete at 05/27/2002 03:37:42 PM Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g4R6JDt51195 Subject: [Isis-wg] IS-IS over IPv4 encapsulation Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 27 May 2002 15:08:57 +0900 Content-Transfer-Encoding: 8bit I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow routers or switches supporting an IS-IS over IPv4 encapsulation as well as a data link layer encapsulation ? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? 4. Is there any internet draft that defines the IS-IS over IPv4 encapsulation, or just a prorietary encapsulation? Any response will be greatly appreciated. Yongjun. --- Yongjun Im System Software Gr., Core Network Research Lab. LG Electronics, Inc. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon May 27 03:28:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13437 for ; Mon, 27 May 2002 03:28:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R764t51433; Mon, 27 May 2002 00:06:04 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4R6kit51330 for ; Sun, 26 May 2002 23:46:44 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 02:59:42 -0400 Message-ID: From: "Manral, Vishwas" To: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] IS-IS over IPv4 encapsulation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 27 May 2002 03:03:18 -0400 Hi Yogjun, A draft for ISIS over IPv4 exists at http://www.watersprings.org/pub/id/draft-ietf-isis-wg-over-ip-02.txt, it has long expired though. From the archives it seems there wasn't much traction behind the draft, check the links http://external.juniper.net/pipermail/isis- wg/2000/000156.html http://external.juniper.net/pipermail/isis-wg/2000/000159.html Thanks, Vishwas -----Original Message----- From: Yongjun Im [mailto:yjim@lge.com] Sent: Monday, May 27, 2002 11:39 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] IS-IS over IPv4 encapsulation I would like to ask a couple of questions regarding IS-IS protocol encapsulation. 1. Does anyone kwow routers or switches supporting an IS-IS over IPv4 encapsulation as well as a data link layer encapsulation ? 2. Does Cisco router support an IS-IS over IPv4 encapsulation? If it support only data link layer encapsulation, does it support IS-IS over Ethernet, IS-IS over AAL5 or IS-IS over POS? 3. I was told that GateD routing module supports the IS-IS over IPv4 encapsulation. Is that right? 4. Is there any internet draft that defines the IS-IS over IPv4 encapsulation, or just a prorietary encapsulation? Any response will be greatly appreciated. Yongjun. --- Yongjun Im System Software Gr., Core Network Research Lab. LG Electronics, Inc. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 28 16:47:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00808 for ; Tue, 28 May 2002 16:47:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4SKOCt62230; Tue, 28 May 2002 13:24:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (rojo.juniper.net [207.17.137.28]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4O2A1t26977 for ; Thu, 23 May 2002 19:10:01 -0700 (PDT) (envelope-from zinin@psg.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g4O2QTn47061 for ; Thu, 23 May 2002 19:26:29 -0700 (PDT) X-JNPR-Received-From: outside Received: from psg.com ([147.28.0.62]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 23 May 2002 19:25:03 -0700 Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with esmtp (Exim 3.36 #1) id 17B4mj-0007bj-00 for isis-wg@juniper.net; Thu, 23 May 2002 19:26:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <7730861020.20020523192501@psg.com> To: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 May 2002 02:25:03.0599 (UTC) FILETIME=[36368FF0:01C202CA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 23 May 2002 19:25:01 -0700 Content-Transfer-Encoding: 7bit Sorry I'm one day late with the comments. > Status ... > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [BCP14]. Pls, move this somewhere within the document (not the Abstract, though, probably the Intro). Also, please go through the text and make sure all occurrences of must/should/may/etc are capitalized when used to express the requirements level. > 1. Introduction > ... > A number of factors can contribute to exceeding this limit: ... > - The growing size of route tables and AS topologies. The size of the RT contributes to the LSP size in case of redistribution and inter-level propagation mentioned in the following item. Here you probably mean the increasing number of destinations (amount of reachability info) to be distributed. > 1.1 Definitions of Commonly Used Terms > > This section provides definitions for terms that are used throughout > the text. > > Originating System > A router running the IS-IS protocol. The term hints there should be some words about LSP origination here. > Original system-id > The system-id of an Originating System. Isn't this supposed to be the "normal" system-id (as opposed to the additional ones)? I mean you should explain what is "original" about it. > Extended system-id Sounds like we're stretching out the normal system-id. Maybe "Virtual system-id" would be a better choice? ... > > Extended LSP > An LSP using an extended system-id in its LSP ID. Same comment about "extended". > 1.2 Operation Modes > > Two administrative operation modes are provided: .. > > These modes may be configured per level. There is no restriction > that an L1/L2 IS operates in the same mode, for both L1 and L2. Shouldn't the modes be on a per-level & area basis. This text also sounds like all routers within a level (or an area if corrected) need to work in the same mode, which is not true, since modified SPF is a requirement regardless of the LSP origination mode. > 2.0 IS Alias ID TLV (IS-A) > > The proposed IS-A TLV allows extension-capable ISs to recognize all > LSPs of an Originating System, and combine the original and extended > LSPs for the purpose of SPF computation. > > The IS Alias ID TLV is type 24, and contains a new data structure, > consisting of: > 7 octets of system Id and pseudonode number > 1 octet of length of sub-TLVs > 0-247 octets of sub-TLVs, > where each sub-TLV consists of a sequence of > 1 octet of sub-type > 1 octet of length > 0-245 octets of value > > Without sub-TLVs, this structure consumes 8 octets per LSP set. This > TLV MUST be included in fragment 0 of every LSP set belonging to an > Originating System. Couldn't find any info on how to put S' and S'' in the TLV. Couldn't find description of any sub-TLVs that would be used to do the above. Couldn't find any rules about sub-TLV handling, i.e., padding and length calculation with it. The format description above should use the illustration style from 1195. > 3.1 Both Operation Modes > > Under both modes, the Originating System MUST include information > binding the Original LSP and the Extended ones. It can do this since > it is trivially an extension-capable IS. This is to ensure other > routers correctly process the extra information in their SPF ^ "implementing this specification" or something like this > 3.1.1 The Attached Bits ... > 3.1.2 The Partition Repair Bit What about the OL bit? > 3.2 Operation Mode 1 Additions ... > When an extended LSP belonging to extended system-id S' is first > created, the original LSP MUST specify S' as a neighbor, with metric > set to zero. This in order to satisfy the two-way connectivity check > on other routers, as well as to consider the cost of reaching the I thought that the S'->S link would be needed to satisfy the TWC check for the S->S' one, not the other way around... > 4. Purging Extended LSP Fragments ... > However, an extended LSP fragment zero should not > be purged until all of the fragments in its set (i.e. belonging to a > particular extended system-id), are empty as well. This is to ensure > implementations consider the fragments in their SPF computations, as > specified in section 7.2.5. Given what section 5 says about ignoring non-0 fragments when fragment zero is missing, what does the above rule give us? > 5. Modifications to LSP handling in SPF ... > If LSP fragment 0 of the original LSP set is missing, all of the LSPs > generated by that Originating System (extended as well) MUST NOT be > considered in the SPF. That is, the large logical LSP isn't > considered in the SPF. If an LSP fragment 0 of an extended LSP set > is missing, only that LSP set MUST NOT be considered in the SPF. This text should also say that fragment 0's RemainingLifetime should be > 0 > 7. Interoperating between extension-capable and non-extension-capable > ISs. ... > It is possible to transition a live network, using the following > steps: > - Upgrade the routers, one-by-one, to run this extension in > Operation Mode 1. The other non-extension-capable routers will > interoperate correctly. > - When all routers are extension-capable, configure them one-by-one > to run in Operation Mode 2. All extension-capable routers > interoperate correctly, regardless of what mode they're run in. We don't have to go through mode-1 to get to mode-2. An upgrade of SW does not necessarily mean changing the LSP origination process. In fact, I would argue that the default setting MUST be the standard one, i.e., neither mode 1 nor mode 2, and it would be really great if this was spelled out. > 9. Acknowledgments > > The author would like to thank Tony Li and Radia Perlman for helpful ^"s" > comments and suggestions on the subject. > 10. References ... > > [ISIS-CODES] Work in progress, "Reserved TLV Codepoints in ISIS", T. > Przygienda Unused ref. Check if you have others. > 11. Authors' Address ^"es" Alex _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue May 28 17:57:37 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02399 for ; Tue, 28 May 2002 17:57:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4SLZEt62685; Tue, 28 May 2002 14:35:14 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4O84wt28629 for ; Fri, 24 May 2002 01:04:58 -0700 (PDT) (envelope-from mshand@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g4O8LSX03014 for ; Fri, 24 May 2002 01:21:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from cisco.com ([144.254.98.48]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Fri, 24 May 2002 01:20:01 -0700 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4244.cisco.com [10.50.16.147]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA16618 for ; Fri, 24 May 2002 09:21:26 +0100 (BST) Message-Id: <4.3.2.7.2.20020524091256.04406478@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@juniper.net From: mike shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 May 2002 08:20:01.0806 (UTC) FILETIME=[CCEF0AE0:01C202FB] Subject: [Isis-wg] draft-ietf-isis-restart-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 24 May 2002 09:20:07 +0100 Folks, I have submitted a revised version of the restart draft. It should be appearing in the usual place soon. I THINK I have addressed all the comments received on the list. I have retained the non-timer resetting behavior of the RR IIH because I think it is useful in some cases but have noted that if you want the resetting behavior you can easily get this by sending a normal IIH once you have acquired the necessary circuit IDs etc. So the way it would work is that you would re-start and get back the remaining time on each adjacency. If this is plenty of time you just carry on as normal. If you feel you need more time (and you are configured to allow that), then you send an IIH with the required holding time. Similarly, I have retained the retries, but said that you may configure a retry count of zero. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 08:05:42 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12689 for ; Wed, 29 May 2002 08:05:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TBhvt67091; Wed, 29 May 2002 04:43:57 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4OFWQt31196 for ; Fri, 24 May 2002 08:32:26 -0700 (PDT) (envelope-from joyal@lucent.com) Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4OFmvl18132 for ; Fri, 24 May 2002 11:48:57 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 11:48:56 -0400 Message-ID: From: "Joyal, Daniel R (Daniel)" To: "'Jeff Parker'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB 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@spider.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, 24 May 2002 11:48:56 -0400 -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Thursday, May 23, 2002 4:17 PM To: 'Joyal, Daniel R (Daniel)' Cc: IS-IS-WG (E-mail) Subject: RE: [Isis-wg] IS-IS MIB >> > In your work on the OSPF mib, did you find >> >access to the LSAs to be useful? Those are >> >big uninterpreted octet strings, much longer >> >than the usual 255 bytes. >> >> The OSPF LSDB table structure has been around a long time. >> The tables break out the header information >> into separate objects and define a single object >> for the entire LSA (header and contents). If the >> LSA gets 'too big', an SNMP agent may not be able to >> satisfy a get/getnext request for the LSA object. >> >> It's probably reasonable to at least define L1 and L2 >> LSP Header tables. A more complex implementation could >> break out LSPs' TLVs into separate per LSP TLV tables >> to enable the entire LSP to be retrieved in pieces. >> >> -Dan > >Dan - > Can we rewind that, please? I think you are >reminding me of why this was a problem in the first >place. > An agent may not be able to satisfy a get request >for the LSA object? Is this due to a small SNMP buffer >size and the lack of a defined way to fragment payload? Yes. > > If an IS has two non-pnode LSPs, one of them >is bound to be over 1K. If this is too big, we have >a problem. We could split this into globs in the mib, >but there is no natural way to do this, other than >"first glob, second glob" etc. One thought is to define L1 and L2 LSP Header tables indexed by LSPID. These tables would contain only LSP header information in small, fixed-sized objects and provide a summary of the LSP database. I think this, by itself, is useful. For viewing the contents of LSPs, a second set of tables is defined which contains, as row entries, the TLVs belonging to an LSP. If TLV order is not important, the table index could be LSPID, TLV Type, Index where Index is the instance of the TLV type in the LSP. TLV entries should be manageable by SNMP. The drawback is that you don't get a snapshot of the complete LSP contents in one SNMP request, so it is possible that the collection of TLVs returned reflect some transitional state between an old and new LSP instance. Does this scheme sound reasonable? -Dan > I am uncomfortable with splitting this into tables >based on the type, as I suspect this will mask issues >that we might see. I admit that the order shouldn't >matter, as long as we know which fragment a TLV sat in. > >- jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 08:24:34 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13479 for ; Wed, 29 May 2002 08:24:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TC3Yt67251; Wed, 29 May 2002 05:03:34 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4OHhat31796 for ; Fri, 24 May 2002 10:43:36 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Joyal, Daniel R (Daniel)'" , Jeff Parker Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB MIME-Version: 1.0 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@spider.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, 24 May 2002 13:59:56 -0400 > > An agent may not be able to satisfy a get request > >for the LSA object? Is this due to a small SNMP buffer > >size and the lack of a defined way to fragment payload? > > Yes. > One thought is to define L1 and L2 LSP Header tables > indexed by LSPID. These tables would contain only LSP header > information in small, fixed-sized objects and provide a > summary of the LSP > database. I think this, by itself, is useful. An index of the 8 byte LSPID and the sequence number should do the trick. The sequence number addresses the issue you raise below in almost all cases. (the corner case is when a router reboots, and issues a new version of an LSP that is still in circulation. This is a transitory event) > For viewing the contents of LSPs, a second set of tables is > defined which > contains, as row entries, the TLVs belonging to an LSP. If TLV > order is not important, the table index could be LSPID, TLV > Type, Index > where Index is the instance of the TLV type in the LSP. > > TLV entries should be manageable by SNMP. The drawback is that > you don't get a snapshot of the complete LSP contents in one > SNMP request, > so it is possible that the collection of TLVs returned reflect some > transitional state between an old and new LSP instance. > Does this scheme sound reasonable? > > -Dan I'm uncomfortable with splitting an LSP into unordered components, though I don't have a compelling argument. - jeff _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 08:51:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14543 for ; Wed, 29 May 2002 08:51:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TCUQt67416; Wed, 29 May 2002 05:30:26 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TCOMt67370 for ; Wed, 29 May 2002 05:24:23 -0700 (PDT) (envelope-from VishwasM@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 08:36:59 -0400 Message-ID: From: "Manral, Vishwas" To: "'Jeff Parker'" , "'Joyal, Daniel R (Daniel)'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB 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@spider.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, 29 May 2002 08:40:48 -0400 Jeff, A couple of comments inline prefixed by a "VM>". -----Original Message----- From: Jeff Parker [mailto:jparker@axiowave.com] Sent: Friday, May 24, 2002 11:30 PM To: 'Joyal, Daniel R (Daniel)'; Jeff Parker Cc: IS-IS-WG (E-mail) Subject: RE: [Isis-wg] IS-IS MIB > > An agent may not be able to satisfy a get request > >for the LSA object? Is this due to a small SNMP buffer > >size and the lack of a defined way to fragment payload? > > Yes. > One thought is to define L1 and L2 LSP Header tables > indexed by LSPID. These tables would contain only LSP header > information in small, fixed-sized objects and provide a > summary of the LSP > database. I think this, by itself, is useful. An index of the 8 byte LSPID and the sequence number should do the trick. The sequence number addresses the issue you raise below in almost all cases. (the corner case is when a router reboots, and issues a new version of an LSP that is still in circulation. This is a transitory event) VM> Maybe the remaining lifetime could be given too. Remaining lifetime is used to identify an instance too, one with 0 Remaininglifetime and one without are different instances. > For viewing the contents of LSPs, a second set of tables is > defined which > contains, as row entries, the TLVs belonging to an LSP. If TLV > order is not important, the table index could be LSPID, TLV > Type, Index > where Index is the instance of the TLV type in the LSP. > > TLV entries should be manageable by SNMP. The drawback is that > you don't get a snapshot of the complete LSP contents in one > SNMP request, > so it is possible that the collection of TLVs returned reflect some > transitional state between an old and new LSP instance. > Does this scheme sound reasonable? > > -Dan I'm uncomfortable with splitting an LSP into unordered components, though I don't have a compelling argument. VM> May be we could have a count of individual TLV's too, which would be equivalent to the number of lsa's of each type. This could help in knowing how many prefixes etc have been injected from other domain/other areas etc. Thanks, Vishwas _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 15:24:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29991 for ; Wed, 29 May 2002 15:24:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TJ2Pt69484; Wed, 29 May 2002 12:02:25 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TIjvt69387 for ; Wed, 29 May 2002 11:45:57 -0700 (PDT) (envelope-from satish@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA10208; Wed, 29 May 2002 12:02:11 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 12:02:11 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA029E8300@avalon.pluris.com> From: Satish Dattatri To: "'Jeff Parker'" , "'Joyal, Daniel R (Daniel)'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB 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@spider.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, 29 May 2002 12:02:10 -0700 Hi, Please see inline ... Thanks, Satish > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Friday, May 24, 2002 11:00 AM > To: 'Joyal, Daniel R (Daniel)'; Jeff Parker > Cc: IS-IS-WG (E-mail) > Subject: RE: [Isis-wg] IS-IS MIB > > > > > An agent may not be able to satisfy a get request > > >for the LSA object? Is this due to a small SNMP buffer > > >size and the lack of a defined way to fragment payload? > > > > Yes. > > > One thought is to define L1 and L2 LSP Header tables > > indexed by LSPID. These tables would contain only LSP header > > information in small, fixed-sized objects and provide a > > summary of the LSP > > database. I think this, by itself, is useful. > > An index of the 8 byte LSPID and the sequence number > should do the trick. The sequence number addresses > the issue you raise below in almost all cases. (the > corner case is when a router reboots, and issues > a new version of an LSP that is still in circulation. > This is a transitory event) > I am not sure why we need the sequence number to be in the index? As far as outside is concerned there is either LSPID A with seq s1 or s2 is part of the LSDB but not *both* s1 and s2. The table needs to have a level-index and the LSPID. The entry that we get will have the LSP header and for display/analysis purposes that can be used. > > For viewing the contents of LSPs, a second set of tables is > > defined which > > contains, as row entries, the TLVs belonging to an LSP. If TLV > > order is not important, the table index could be LSPID, TLV > > Type, Index > > where Index is the instance of the TLV type in the LSP. > > > > TLV entries should be manageable by SNMP. The drawback is that ^^^^^ Apart from being able to do a get is there something more this reqd ? > > you don't get a snapshot of the complete LSP contents in one > > SNMP request, > > so it is possible that the collection of TLVs returned reflect some > > transitional state between an old and new LSP instance. > > Does this scheme sound reasonable? > > > > -Dan > > I'm uncomfortable with splitting an LSP into unordered > components, though I don't have a compelling argument. > too much of housekeeping, depending on how an implementation stores an LSP. On the other hand most implementations have a way to display the LSP in detail, which needs the above table. Is there a way to specify in MIB terms saying optional so that an implementation can be conforming to standard yet not have this table implemented ;-). > - jeff > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 15:29:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00182 for ; Wed, 29 May 2002 15:29:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TJ8Ct69522; Wed, 29 May 2002 12:08:12 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TIp6t69417 for ; Wed, 29 May 2002 11:51:06 -0700 (PDT) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Satish Dattatri'" , Jeff Parker , "'Joyal, Daniel R (Daniel)'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB MIME-Version: 1.0 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@spider.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, 29 May 2002 15:07:53 -0400 > > > One thought is to define L1 and L2 LSP Header tables > > > indexed by LSPID. These tables would contain only LSP header > > > information in small, fixed-sized objects and provide a > > > summary of the LSP > > > database. I think this, by itself, is useful. > > > > An index of the 8 byte LSPID and the sequence number > > should do the trick. The sequence number addresses > > the issue you raise below in almost all cases. (the > > corner case is when a router reboots, and issues > > a new version of an LSP that is still in circulation. > > This is a transitory event) > > I am not sure why we need the sequence number to be in the index? > As far as outside is concerned there is either LSPID A with seq > s1 or s2 is part of the LSDB but not *both* s1 and s2. The table > needs to have a level-index and the LSPID. The entry that we get > will have the LSP header and for display/analysis purposes that > can be used. Satish - You are right. There is no need for the sequence number to be in the index. If we return the seq #, we can avoid Dan's issue of mixing parts from different versions of LSP frag X. > > > TLV entries should be manageable by SNMP. The drawback is that > ^^^^^ > Apart from being able to do a get is there something more this reqd ? I agree that it wuold be a mistake for anything other than get. > > I'm uncomfortable with splitting an LSP into unordered > > components, though I don't have a compelling argument. > > too much of housekeeping, depending on how an implementation stores > an LSP. On the other hand most implementations have a way to display > the LSP in detail, which needs the above table. Is there a way to > specify in MIB terms saying optional so that an implementation can > be conforming to standard yet not have this table implemented ;-). Yes, there is a way to mark some things as optional. The MIB today has required tables and optional tables. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 16:07:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01561 for ; Wed, 29 May 2002 16:07:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TJjWt69746; Wed, 29 May 2002 12:45:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TJJDt69579 for ; Wed, 29 May 2002 12:19:13 -0700 (PDT) (envelope-from joyal@lucent.com) Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4TJaGH22447 for ; Wed, 29 May 2002 15:36:17 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 15:36:16 -0400 Message-ID: From: "Joyal, Daniel R (Daniel)" To: "'Jeff Parker'" , "'Satish Dattatri'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] IS-IS MIB 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@spider.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, 29 May 2002 15:36:14 -0400 >> > > One thought is to define L1 and L2 LSP Header tables >> > > indexed by LSPID. These tables would contain only LSP header >> > > information in small, fixed-sized objects and provide a >> > > summary of the LSP >> > > database. I think this, by itself, is useful. >> > >> > An index of the 8 byte LSPID and the sequence number >> > should do the trick. The sequence number addresses >> > the issue you raise below in almost all cases. (the >> > corner case is when a router reboots, and issues >> > a new version of an LSP that is still in circulation. >> > This is a transitory event) >> >> I am not sure why we need the sequence number to be in the index? >> As far as outside is concerned there is either LSPID A with seq >> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table >> needs to have a level-index and the LSPID. The entry that we get >> will have the LSP header and for display/analysis purposes that >> can be used. > >Satish - > You are right. There is no need for the sequence number >to be in the index. If we return the seq #, we can avoid Dan's >issue of mixing parts from different versions of LSP frag X. > > >> > > TLV entries should be manageable by SNMP. The drawback is that >> ^^^^^ >> Apart from being able to do a get is there something more this reqd ? > >I agree that it wuold be a mistake for anything other than get. Bad word choice on my part. I meant the *size* of TLVs should be small enough to fit into SNMP buffers as opposed to the entire LSP fragment. These should be read-only tables. > > >> > I'm uncomfortable with splitting an LSP into unordered >> > components, though I don't have a compelling argument. >> >> too much of housekeeping, depending on how an implementation stores >> an LSP. On the other hand most implementations have a way to display >> the LSP in detail, which needs the above table. Is there a way to >> specify in MIB terms saying optional so that an implementation can >> be conforming to standard yet not have this table implemented ;-). > >Yes, there is a way to mark some things as optional. The MIB >today has required tables and optional tables. I agree that these tables should be optional. -Dan > >- jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed May 29 18:55:57 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06457 for ; Wed, 29 May 2002 18:55:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TMXpt70574; Wed, 29 May 2002 15:33:51 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xmxpita.excite.com (nat1.excitenetwork.com [63.236.75.3]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4TM76t70434 for ; Wed, 29 May 2002 15:07:06 -0700 (PDT) (envelope-from dgoodspe@excite.com) Received: by xmxpita.excite.com (Postfix, from userid 110) id E0825B6D7; Wed, 29 May 2002 18:24:05 -0400 (EDT) To: joyal@lucent.com, jparker@axiowave.com, satish@pluris.com Subject: RE: [Isis-wg] IS-IS MIB Received: from [63.104.212.252] by xprdmailfe20.nwk.excite.com via HTTP; Wed, 29 May 2002 18:24:05 EST Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc"; Content-Transfer-Encoding: 7bit Cc: isis-wg@spider.juniper.net Message-Id: <20020529222405.E0825B6D7@xmxpita.excite.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 29 May 2002 18:24:05 -0400 (EDT) --EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My 2 cents, Index by the level and the LSP ID. Have an attribute for each of the fixed fields. Have an OCTET-STRING defined attribute as the last entry in the table that contains either: a. The hex dump of the entire LSP, or b. The hex dump of just the variable length fields. The upper bound on the size probably needs to be 65535. Don't worry, SNMP can fragment SNMP replies for the large one. This is essentially how ospfLsdbAdvertisement is defined (it includes the entire header, incidentally). It is up to the management application to do the parsing of the TLVs to get out the needed info, so it's less work on the SNMP agent to track all this info. Cheers, Don --- On Wed 05/29, Joyal, Daniel R (Daniel) wrote: From: Joyal, Daniel R (Daniel) [mailto: joyal@lucent.com] To: jparker@axiowave.com,satish@pluris.com Cc: isis-wg@spider.juniper.net Date: Wed 05/29 Subject: RE: [Isis-wg] IS-IS MIB > > > > > >> > > One thought is to define L1 and L2 LSP Header tables > >> > > indexed by LSPID. These tables would contain only LSP > header > >> > > information in small, fixed-sized objects and provide a > > >> > > summary of the LSP > >> > > database. I think this, by itself, is useful. > >> > > >> > An index of the 8 byte LSPID and the sequence number > >> > should do the trick. The sequence number addresses > >> > the issue you raise below in almost all cases. (the > >> > corner case is when a router reboots, and issues > >> > a new version of an LSP that is still in circulation. > >> > This is a transitory event) > >> > >> I am not sure why we need the sequence number to be in the > index? > >> As far as outside is concerned there is either LSPID A with seq > >> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table > >> needs to have a level-index and the LSPID. The entry that we get > >> will have the LSP header and for display/analysis purposes that > >> can be used. > > > >Satish - > > You are right. There is no need for the sequence number > >to be in the index. If we return the seq #, we can avoid Dan's > >issue of mixing parts from different versions of LSP frag X. > > > > > >> > > TLV entries should be manageable by SNMP. The drawback > is that > >> ^^^^^ > >> Apart from being able to do a get is there something more this > reqd ? > > > >I agree that it wuold be a mistake for anything other than get. > > Bad word choice on my part. I meant the *size* of TLVs should be small > enough to fit into SNMP buffers as opposed to the entire LSP fragment. > These should be read-only tables. > > > > > > >> > I'm uncomfortable with splitting an LSP into unordered > >> > components, though I don't have a compelling argument. > >> > >> too much of housekeeping, depending on how an implementation > stores > >> an LSP. On the other hand most implementations have a way to > display > >> the LSP in detail, which needs the above table. Is there a way > to > >> specify in MIB terms saying optional so that an implementation > can > >> be conforming to standard yet not have this table implemented > ;-). > > > >Yes, there is a way to mark some things as optional. The MIB > >today has required tables and optional tables. > > I agree that these tables should be optional. > > -Dan > > > >- jeff parker > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit My 2 cents,

Index by the level and the LSP ID. Have an attribute for each
of the fixed fields. Have an OCTET-STRING defined attribute
as the last entry in the table that contains either:
a. The hex dump of the entire LSP, or
b. The hex dump of just the variable length fields.

The upper bound on the size probably needs to be 65535. Don't
worry, SNMP can fragment SNMP replies for the large one.

This is essentially how ospfLsdbAdvertisement is defined
(it includes the entire header, incidentally). It is up
to the management application to do the parsing of the
TLVs to get out the needed info, so it's less work on
the SNMP agent to track all this info.

Cheers,
Don

--- On Wed 05/29, Joyal, Daniel R (Daniel) < joyal@lucent.com > wrote:
From: Joyal, Daniel R (Daniel) [mailto: joyal@lucent.com]
To: jparker@axiowave.com,satish@pluris.com
Cc: isis-wg@spider.juniper.net
Date: Wed 05/29
Subject: RE: [Isis-wg] IS-IS MIB
>
>
>
>
> >> > > One thought is to define L1 and L2 LSP Header tables
> >> > > indexed by LSPID. These tables would contain only LSP
> header
> >> > > information in small, fixed-sized objects and provide a
>
> >> > > summary of the LSP
> >> > > database. I think this, by itself, is useful.
> >> >
> >> > An index of the 8 byte LSPID and the sequence number
> >> > should do the trick. The sequence number addresses
> >> > the issue you raise below in almost all cases. (the
> >> > corner case is when a router reboots, and issues
> >> > a new version of an LSP that is still in circulation.
> >> > This is a transitory event)
> >>
> >> I am not sure why we need the sequence number to be in the
> index?
> >> As far as outside is concerned there is either LSPID A with seq
> >> s1 or s2 is part of the LSDB but not *both* s1 and s2. The table
> >> needs to have a level-index and the LSPID. The entry that we get
> >> will have the LSP header and for display/analysis purposes that
> >> can be used.
> >
> >Satish -
> > You are right. There is no need for the sequence number
> >to be in the index. If we return the seq #, we can avoid Dan's
> >issue of mixing parts from different versions of LSP frag X.
> >
> >
> >> > > TLV entries should be manageable by SNMP. The drawback
> is that
> >> ^^^^^
> >> Apart from being able to do a get is there something more this
> reqd ?
> >
> >I agree that it wuold be a mistake for anything other than get.
>
> Bad word choice on my part. I meant the *size* of TLVs should be small
> enough to fit into SNMP buffers as opposed to the entire LSP fragment.
> These should be read-only tables.
>
> >
> >
> >> > I'm uncomfortable with splitting an LSP into unordered
> >> > components, though I don't have a compelling argument.
> >>
> >> too much of housekeeping, depending on how an implementation
> stores
> >> an LSP. On the other hand most implementations have a way to
> display
> >> the LSP in detail, which needs the above table. Is there a way
> to
> >> specify in MIB terms saying optional so that an implementation
> can
> >> be conforming to standard yet not have this table implemented
> ;-).
> >
> >Yes, there is a way to mark some things as optional. The MIB
> >today has required tables and optional tables.
>
> I agree that these tables should be optional.
>
> -Dan
> >
> >- jeff parker
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>

Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__3536ca3fc140443cd83c35edf41070cc-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu May 30 11:41:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09581 for ; Thu, 30 May 2002 11:41:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4UFJWt75839; Thu, 30 May 2002 08:19:32 -0700 (PDT) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g4UEqgt75707 for ; Thu, 30 May 2002 07:52:42 -0700 (PDT) (envelope-from amir@cwnt.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g4UF9qX22698 for ; Thu, 30 May 2002 08:09:52 -0700 (PDT) X-JNPR-Received-From: outside Received: from bart.cwnt.com ([192.116.246.129]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 30 May 2002 08:08:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Message-ID: Thread-Topic: [Isis-wg] last call on draft draft-ietf-isis-ext-lsp-frags-00 ... Thread-Index: AcIGiaI62c+x7AaDQveXtb6coBkaaAAivwHg From: "Amir Hermelin" To: "Alex Zinin" , Cc: "Amir Hermelin" X-OriginalArrivalTime: 30 May 2002 15:08:20.0015 (UTC) FILETIME=[D57B93F0:01C207EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g4UEqgt75708 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.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, 30 May 2002 18:09:47 +0300 Content-Transfer-Encoding: 8bit Alex, comments inline. Thanks very much for the helpful comments and suggestions. As always, other suggetions, especially for terminology, are more than welcomed. -- Amir Hermelin < mailto:amir@cwnt.com> Charlotte's Web Networks Inc. < http://www.cwnt.com> > -----Original Message----- > From: Alex Zinin [mailto:zinin@psg.com] > Sent: Friday, May 24, 2002 5:25 AM > To: isis-wg@juniper.net > Subject: Re: [Isis-wg] last call on draft > draft-ietf-isis-ext-lsp-frags-00 ... > > > Sorry I'm one day late with the comments. > > > Status > ... > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [BCP14]. > > Pls, move this somewhere within the document (not the Abstract, > though, probably the Intro). > right. I'll put this into a subsection of the Introduction section. > Also, please go through the text and make sure all occurrences of > must/should/may/etc are capitalized when used to express the > requirements level. > > > 1. Introduction > > > ... > > A number of factors can contribute to exceeding this limit: > ... > > - The growing size of route tables and AS topologies. > > The size of the RT contributes to the LSP size in case > of redistribution and inter-level propagation mentioned > in the following item. Here you probably mean the increasing > number of destinations (amount of reachability info) to > be distributed. agreed. Will re-word. > > > 1.1 Definitions of Commonly Used Terms > > > > This section provides definitions for terms that are > used throughout > > the text. > > > > Originating System > > A router running the IS-IS protocol. > > The term hints there should be some words about LSP origination here. I agree it might be a little ambigous here, although when terming "LSP origination", it does appear to routers as if Extended (or Virtual) systems also originate LSPs. I'll think of an additional desciprtion here. > > > Original system-id > > The system-id of an Originating System. > > Isn't this supposed to be the "normal" system-id (as opposed > to the additional ones)? I mean you should explain what > is "original" about it. > probably bad naming on my behalf. I'll confer the other authors for a better term. I agree it's important, not only because of the document, but also because this will probably be the term presented to users of routers. > > Extended system-id > > Sounds like we're stretching out the normal system-id. > Maybe "Virtual system-id" would be a better choice? > again, could be bad naming. However, I originally thought "Virtual" to be a little confusing, as a "virtual link" term is already used in the IS-IS spec, for a completely different purpose. The draft uses "extended" for LSPs, since they really extend the original LS information an IS could advertise, as opposed to "Virtual System", which doesn't really add any additional info. Does that make sense? > ... > > > > Extended LSP > > An LSP using an extended system-id in its LSP ID. > > Same comment about "extended". > > > 1.2 Operation Modes > > > > Two administrative operation modes are provided: > .. > > > > These modes may be configured per level. There is no restriction > > that an L1/L2 IS operates in the same mode, for both L1 and L2. > > Shouldn't the modes be on a per-level & area basis. This > text also sounds like all routers within a level (or an area > if corrected) need to work in the same mode, which is not true, > since modified SPF is a requirement regardless of the LSP > origination mode. agreed, that's the original intent. I'll add "per area". The actual requirement is "per spf", but I think it will confuse more than it will clarify. > > > 2.0 IS Alias ID TLV (IS-A) > > > > The proposed IS-A TLV allows extension-capable ISs to > recognize all > > LSPs of an Originating System, and combine the original > and extended > > LSPs for the purpose of SPF computation. > > > > The IS Alias ID TLV is type 24, and contains a new data > structure, > > consisting of: > > 7 octets of system Id and pseudonode number > > 1 octet of length of sub-TLVs > > 0-247 octets of sub-TLVs, > > where each sub-TLV consists of a sequence of > > 1 octet of sub-type > > 1 octet of length > > 0-245 octets of value > > > > Without sub-TLVs, this structure consumes 8 octets per > LSP set. This > > TLV MUST be included in fragment 0 of every LSP set > belonging to an > > Originating System. > > Couldn't find any info on how to put S' and S'' in the TLV. > Actually, what you need to put here is S (or the is-alias-id, which could be different). The S' and S'' (and also S) appear in the LSP header. > Couldn't find description of any sub-TLVs that would be > used to do the above. It's just put there for future or proprietary use - doesn't take up any space, I think we should keep it. > > Couldn't find any rules about sub-TLV handling, i.e., padding > and length calculation with it. > > The format description above should use the illustration > style from 1195. I don't fully understand what's missing, but I will add an example. I've used the format from the TE-extensions draft, which I think to be clear and well-discussed. Please clarify what you'd like to see here. > > > 3.1 Both Operation Modes > > > > Under both modes, the Originating System MUST include information > > binding the Original LSP and the Extended ones. It can > do this since > > it is trivially an extension-capable IS. This is to ensure other > > routers correctly process the extra information in their SPF > ^ > "implementing this specification" or something like this added. > > > 3.1.1 The Attached Bits > ... > > 3.1.2 The Partition Repair Bit > > What about the OL bit? The 3.1.* sections are exceptions. The OL bit should be set/unset in original and extended LSPs the same as before. > > > 3.2 Operation Mode 1 Additions > ... > > When an extended LSP belonging to extended system-id S' is first > > created, the original LSP MUST specify S' as a neighbor, > with metric > > set to zero. This in order to satisfy the two-way > connectivity check > > on other routers, as well as to consider the cost of reaching the > > I thought that the S'->S link would be needed to satisfy > the TWC check for the S->S' one, not the other way around... > Depends on which node (S or S') was first considered in SPF. In Mode 1, it's true that always S will be reached first, but this isn't guaranteed in mode 2. > > > 4. Purging Extended LSP Fragments > ... > > However, an extended LSP fragment > zero should not > > be purged until all of the fragments in its set (i.e. > belonging to a > > particular extended system-id), are empty as well. This > is to ensure > > implementations consider the fragments in their SPF > computations, as > > specified in section 7.2.5. > > Given what section 5 says about ignoring non-0 fragments when > fragment zero is missing, what does the above rule give us? > the above rule is specifically to ensure section 5 works well: if we have info in other fragments, but the zero-fragment is empty (and we don't re-arrange information, as we shouldn't), we still need to keep that fragment so other fragments are considered. I guess this is true regardless of this draft or not - we just wanted to clarify it. > > 5. Modifications to LSP handling in SPF > ... > > If LSP fragment 0 of the original LSP set is missing, > all of the LSPs > > generated by that Originating System (extended as well) > MUST NOT be > > considered in the SPF. That is, the large logical LSP isn't > > considered in the SPF. If an LSP fragment 0 of an > extended LSP set > > is missing, only that LSP set MUST NOT be considered in the SPF. > > This text should also say that fragment 0's RemainingLifetime > should be > 0 > right you are! > > 7. Interoperating between extension-capable and > non-extension-capable > > ISs. > ... > > It is possible to transition a live network, using the following > > steps: > > - Upgrade the routers, one-by-one, to run this extension in > > Operation Mode 1. The other non-extension-capable routers will > > interoperate correctly. > > - When all routers are extension-capable, configure > them one-by-one > > to run in Operation Mode 2. All extension-capable routers > > interoperate correctly, regardless of what mode they're run in. > > We don't have to go through mode-1 to get to mode-2. An upgrade of > SW does not necessarily mean changing the LSP origination process. > In fact, I would argue that the default setting MUST be the standard > one, i.e., neither mode 1 nor mode 2, and it would be really great > if this was spelled out. > Your upgrade option is identical to what the draft suggests - since "standard one" is really Mode 1 (you can either have mode-1 or mode-2). The difference between mode-1 and the "standard" way, is that the standard way asserts when the maximum fragments are reached ;-) There's also the additional tlv, but there's no harm in advertising it. > > 9. Acknowledgments > > > > The author would like to thank Tony Li and Radia Perlman > for helpful > ^"s" > whoops... > > comments and suggestions on the subject. > > > > 10. References > ... > > > > [ISIS-CODES] Work in progress, "Reserved TLV Codepoints > in ISIS", T. > > Przygienda > > Unused ref. Check if you have others. > > > 11. Authors' Address > ^"es" > whoops again... > Alex > Thanks! very helpful comments! > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg