From isis-wg-admin@spider.juniper.net Wed Aug 1 00:25:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25983 for ; Wed, 1 Aug 2001 00:25:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA41298; Tue, 31 Jul 2001 21:32:18 -0700 (PDT) Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA41286 for ; Tue, 31 Jul 2001 21:31:47 -0700 (PDT) Received: from nexthop.com ([64.211.218.17]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f714PAJ69529; Wed, 1 Aug 2001 00:25:10 -0400 (EDT) (envelope-from naamato@nexthop.com) Received: (from naamato@localhost) by nexthop.com (8.11.0/8.11.0) id f714P9i25518; Wed, 1 Aug 2001 00:25:09 -0400 (EDT) From: Nick Amato To: Naiming Shen Cc: Nick Amato , isis-wg@spider.juniper.net, prz@redback.com Subject: Re: [isis-wg] comment on hmac-03 Message-ID: <20010801002407.B25225@wooj.nexthop.com> References: <20010801035002.A155A1DCC63@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010801035002.A155A1DCC63@prattle.redback.com>; from naiming@redback.com on Tue, Jul 31, 2001 at 08:50:02PM -0700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 1 Aug 2001 00:24:07 -0400 On Tue, Jul 31, 2001 at 08:50:02PM -0700, Naiming Shen wrote: > ] > ]At time X, both A and B switches auth key from key1 into key2, and A's > ]ISIS process restarted. A and B then re-establish the adjacency with > ]the key2, they can also exchange the SNPs using the key2, there is no > ]problem of that. A now has a LSP starts from seq# of 1. when A sends > ]this LSP to B, B rejects this, and send the A's old LSP back to A(with > ]the key1). If B does not have multiple-key implemented or B timedout > > typo here ^ (should be A) ^ ( A also ) > > ]the key1 too soon, then the old LSP with key1 is rejected because of > ]failing authentication. B will not get A's new LSP until this old LSP > ]of A timed out. > I agree with this example (LSPs use the authentication of the originator rather than the transmitter of the LSP PDU). Section 2.1 should probably indicate, like your example, the problem exists if the router does not implement multiple keys or the old key is timed out too quickly or forgotten rather than after the router restarts, just for clarity. The router may remember its old key if the configuration was in non-volatile storage. :) Nick _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 01:35:15 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02085 for ; Wed, 1 Aug 2001 01:35:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA41651; Tue, 31 Jul 2001 22:41:19 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA41639 for ; Tue, 31 Jul 2001 22:40:14 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id D68EF4BA215; Tue, 31 Jul 2001 22:33:38 -0700 (PDT) To: Nick Amato Cc: isis-wg@spider.juniper.net, prz@redback.com Subject: Re: [isis-wg] comment on hmac-03 In-reply-to: Mail from Nick Amato dated Wed, 01 Aug 2001 00:24:07 EDT <20010801002407.B25225@wooj.nexthop.com> From: Naiming Shen Message-Id: <20010801053338.D68EF4BA215@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 22:33:38 -0700 ] ]I agree with this example (LSPs use the authentication of the originator ]rather than the transmitter of the LSP PDU). ] ]Section 2.1 should probably indicate, like your example, the problem ]exists if the router does not implement multiple keys or the old ]key is timed out too quickly or forgotten rather than after the ]router restarts, just for clarity. Agreed. It would be nice to spell it out. Anyway, it should be taken care of at the protocol implementation level. Use one key or multiple keys, how long to keep the keys, those are configuration issues. ]The router may remember its old ]key if the configuration was in non-volatile storage. :) I said "ISIS process restarted", not router restarted, so nvram is not needed here:-) thanks. ] ]Nick - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 02:49:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19100 for ; Wed, 1 Aug 2001 02:49:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA42002; Tue, 31 Jul 2001 23:55:19 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA41987 for ; Tue, 31 Jul 2001 23:54:43 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 01 Aug 2001 12:27:04 +0530 Received: from amrendras (amrendras.future.futsoft.com [192.168.5.26]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f716m2L05756 for ; Wed, 1 Aug 2001 12:18:02 +0530 Reply-To: From: "andy" To: Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="----=_NextPart_000_0015_01C11A86.0FE4FE90" Subject: [Isis-wg] query Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 1 Aug 2001 12:32:43 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C11A86.0FE4FE90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi list, I have encountered a peculiar behaviour in Cisco-2600 series router. When i enable authentication at domain level or area level, the LSPs generated have authentication information in them . However the CSNP packets and PSNP packets generated by CISCO do not have this authentication information. This is causing authentication failure. Due to which the routes are not learnt by cisco router and test router. However even if one CSNP packet is allowed to be processed by the test router then the routes are exchanged and installed in both Cisco's and the test router's main routing table. My question is should there be authentication information in CSNP as well as PSNP packets when i have enabled authentication at the domain or the Area level? please reply as soon as possible thanks and regards amrendras sharma ( Future software ltd, Chennai, India) ------=_NextPart_000_0015_01C11A86.0FE4FE90 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IisHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAABAAwAGAAAAAMACAEB A5AGAIAGAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAABgAAAHF1ZXJ5AAAAAgFxAAEAAAAWAAAAAcEaVuCMUdqZgIY3EdWN/wAQWob+ogAAAgEdDAEA AAAiAAAAU01UUDpBTVJFTkRSQVNARlVUVVJFLkZVVFNPRlQuQ09NAAAACwABDgAAAABAAAYOAPT7 vVYawQECAQoOAQAAABgAAAAAAAAAtObTPAuA1BGNVQAQWob+osKAAAALAB8OAQAAAAIBCRABAAAA 1wIAANMCAACIBAAATFpGdZcEeMADAAoAcmNwZzEyNRYyAPgLYG4OEDAzM08B9wKkA+MCAGNoCsBz 8GV0MCAHEwKDAFADVV8HbQKDDlAD1RF1fQqBdkkIkHdrC4BkNAxgYwcAUAsDC7UgaGkgbFkEAHQs CqIKgEkWwGHYdmUgCfAFoHUCMASQoQmAIGEgcAWQdRcAqQrBYmUX0WkIYSALgAwgQwQABaAtMjYw XxFQESAIgQQgA2B1GIEu8wrjCoBXaAnwGiAYEQGgWmwYAGEboBxxdA3gYe8doAIgGNAFQGQDcRox HRBvF/ADIAWxCsBlGOAe0yxCIB1hIExTUAQgIP5nCfAEkB3QGLEX0x1NC4AdAhByAMAiVSASbSAu cRdUSG93HuEFwCAiQ9hTTlAY8ADQaxEwBCCbAHAYwFAlKiDIYnkaUBBJU0NPHlEgbm9/BUAX0x1g BAAhryK4G+BUdyjyKQEdwHUAkA8gHT5m7wtwCkAJcCPlRApQIBAoMP53FtAQ4CATG4MlwQlwKEPv HRAKwAIwJ4JjGnIbdSXTvy8BBUAbhiRWHuEckWYfIP8g4CUKKzIHQAkAJHAxUSgw9xmQGPADYGMH kBEgJ3MgIs8xeSASI3MuymV4EOEPIP8YsiXxC4AXIDRxGLEaMQbg+x1gGlQnJcQ2LTqxHoMbgl8r sgGRHRAj5RdUTSegcU8KUBcgImMEIHNoCGBsvzsDL1E1ISk/IsslE2EEIP8kcDSAQkImKy4wHIMX 1Rzy/xjBHV8gIh5lBbEgIgcQH4a+PxdUC1AfgBEgG3BlC1AzJ6BCUXNvHgIEIHBvvQQQaR0BF1Qd YABwayXEnQlwZwsRELA9iWFtCXA/FYAhAD8CCsAAwBdUKCBeRhugLSFJUQGAdy9CbGx0ZBdFIKBD HHEc4GnbIABPZkkVgAcwKSCgG/X/PXgWMRIRC/AVoD2EE9MMARdR+lPlFOEAVXAACwAAgAggBgAA AAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMA B4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUA AAEAAAAEAAAAOS4wAAsADYAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwARgAggBgAAAAAA wAAAAAAAAEYAAAAABoUAAAAAAAADABKACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsAG4AI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAcgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA AAADAB6ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAIB+A8BAAAAEAAAALTm0zwLgNQRjVUA EFqG/qICAfoPAQAAABAAAAC05tM8C4DUEY1VABBahv6iAgH7DwEAAABNAAAAAAAAADihuxAF5RAa obsIACsqVsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcbWFpbFxtYWls Ym94LnBzdAAAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAA8AAAAPE5FQkJJTkZGTEVQR0lKTEtQ RkNDSUVCQUlMQUEuYW1yZW5kcmFzQGZ1dHVyZS5mdXRzb2Z0LmNvbT4AAwAGECHtIpYDAAcQyQIA AAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABISUxJU1QsSUhBVkVFTkNPVU5URVJFREFQRUNV TElBUkJFSEFWSU9VUklOQ0lTQ08tMjYwMFNFUklFU1JPVVRFUldIRU5JRU5BQkxFQVVUSEVOVElD QVRJT05BVERPTUFJTkxFAAAAAKd7 ------=_NextPart_000_0015_01C11A86.0FE4FE90-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 05:03:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23097 for ; Wed, 1 Aug 2001 05:03:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA42759; Wed, 1 Aug 2001 02:09:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA42747 for ; Wed, 1 Aug 2001 02:08:18 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f718wTw65851 for ; Wed, 1 Aug 2001 01:58:29 -0700 (PDT) X-JNPR-Received-From: outside content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: hmac-md5 interoperability in ISIS Thread-Index: AcEaaJCN+y/oz2nGTLSQ1OcQ8XB2QA== From: "Omer Sali" To: "isis-wg (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id CAA42748 Subject: [Isis-wg] hmac-md5 interoperability in ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 1 Aug 2001 12:01:34 +0300 Content-Transfer-Encoding: 8bit Hi, RFC 2104 (HMAC: Keyed-Hashing for Message Authentication) says : "The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). However, less than L bytes is strongly discouraged as it would decrease the security strength of the function." Note that L is 16 for MD5. My questions are: 1) Is there a common padding of passwords less than 16 bytes to be used by all ISIS implementors? Avoiding to use a common padding clearly prevents interoperability between vendors. 2) Do all vendors use the same procedure for authenticating the PDUs? Are there any known implementations not using the procedure as described in draft-ietf-isis-hmac-03? Thanks, Omer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 08:50:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00245 for ; Wed, 1 Aug 2001 08:50:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA43785; Wed, 1 Aug 2001 05:56:20 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA43773 for ; Wed, 1 Aug 2001 05:56:00 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (bru-pegas1-vlan24-dhcp06.cisco.com [144.254.7.208]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA12443; Wed, 1 Aug 2001 14:49:16 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010801144457.00b61af8@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: From: stefano previdi Subject: Re: [Isis-wg] query Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 01 Aug 2001 14:46:43 +0200 At 09:02 01/08/2001, andy wrote: >hi list, >I have encountered a peculiar behaviour in Cisco-2600 series router. >When i enable authentication at domain level or area level, the LSPs >generated have authentication information in them . >However the CSNP packets and PSNP packets generated by CISCO do not have >this authentication information. This is causing authentication failure. >Due to which the routes are not learnt by cisco router and test router. >However even if one CSNP packet is allowed to be processed by the test >router then the routes are exchanged and installed in both Cisco's and the >test router's main routing table. > >My question is should there be authentication information in CSNP as well as >PSNP packets when i have enabled authentication at the domain or the Area >level? it's a cisco specific issue...not ietf one... I'll take it offline. s. >please reply as soon as possible >thanks and regards > >amrendras sharma >( Future software ltd, > Chennai, > India) > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 10:13:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04468 for ; Wed, 1 Aug 2001 10:13:34 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA44199; Wed, 1 Aug 2001 07:18:20 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA44187 for ; Wed, 1 Aug 2001 07:17:12 -0700 (PDT) Message-ID: From: Jeff Parker To: "'amrendras@future.futsoft.com'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] query 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 1 Aug 2001 10:10:24 -0400 > I have encountered a peculiar behaviour in (Company C) series router. > When i enable authentication at domain level or area level, the LSPs > generated have authentication information in them . To quote Claude Raines: "I'm shocked: shocked to hear that there is a missmatch between specifications and implementations." Since the behavior by company C is long standing and well know, you may find there is a setting in vendor T's equipment that will cut a bit of slack to routers from company C. There may not be such a setting yet, but any test which flunks the majority of boxes deployed may need to be modified to include a "reality" setting. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 12:13:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19514 for ; Wed, 1 Aug 2001 12:13:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA44724; Wed, 1 Aug 2001 09:19:19 -0700 (PDT) Received: from compton.nixc.net (cesium.nixc.net [208.185.25.24]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA44712 for ; Wed, 1 Aug 2001 09:18:53 -0700 (PDT) Received: (from darrinw@localhost) by compton.nixc.net (8.11.3/8.11.3) id f71GBa631232; Wed, 1 Aug 2001 16:11:36 GMT From: Darrin Walton To: andy Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] query Message-ID: <20010801161136.N9871@nixc.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from amrendras@future.futsoft.com on Wed, Aug 01, 2001 at 12:32:43PM +0530 Phone: +1 703 744 8700 Organization: NIXC, Inc. X-Operating-System: SecureBSD darrinw@mfnx.net Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 1 Aug 2001 16:11:36 +0000 On Wed, Aug 01, 2001 at 12:32:43PM +0530, andy wrote: |+ hi list, |+ I have encountered a peculiar behaviour in Cisco-2600 series router. |+ When i enable authentication at domain level or area level, the LSPs |+ generated have authentication information in them . |+ However the CSNP packets and PSNP packets generated by CISCO do not have |+ this authentication information. This is causing authentication failure. I thought the RFC stated this was optional, not mandatory. Cisco's webpage however does say the PSNP packets should have authentication. I ran into this awhile ago, and Cisco has said they have fixed this issue, as it was causing us other problems. I'm not sure what the other router vendor you're using, but what you could do is disable the domain or area authentication, and enable hello-authentication on each interface. -- darrin walton, darrinw@nixc.net _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 13:53:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24931 for ; Wed, 1 Aug 2001 13:53:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA45176; Wed, 1 Aug 2001 11:00:19 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA45158 for ; Wed, 1 Aug 2001 10:59:32 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA11514; Wed, 1 Aug 2001 19:52:43 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010801194858.01a40ed8@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Darrin Walton From: stefano previdi Subject: Re: [Isis-wg] query Cc: andy , isis-wg@spider.juniper.net In-Reply-To: <20010801161136.N9871@nixc.net> 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 01 Aug 2001 19:50:10 +0200 At 18:11 01/08/2001, Darrin Walton wrote: >On Wed, Aug 01, 2001 at 12:32:43PM +0530, andy wrote: > |+ hi list, > |+ I have encountered a peculiar behaviour in Cisco-2600 series router. > |+ When i enable authentication at domain level or area level, the LSPs > |+ generated have authentication information in them . > |+ However the CSNP packets and PSNP packets generated by CISCO do not have > |+ this authentication information. This is causing authentication failure. > >I thought the RFC stated this was optional, not mandatory. Cisco's >webpage however does say the PSNP packets should have authentication. > >I ran into this awhile ago, and Cisco has said they have fixed this issue, >as it was causing us other problems. > >I'm not sure what the other router vendor you're using, but what you >could do is disable the domain or area authentication, and enable >hello-authentication on each interface. I replied offline to this problem but since other people seems to be interested...yes, the problem has been fixed. Get in touch with me for details. s. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 16:03:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02019 for ; Wed, 1 Aug 2001 16:03:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA45750; Wed, 1 Aug 2001 13:10:19 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA45735 for ; Wed, 1 Aug 2001 13:09:36 -0700 (PDT) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 40BC51DCC7E; Wed, 1 Aug 2001 13:02:56 -0700 (PDT) Message-ID: <3B685C0C.EC03AA96@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: stefano previdi Cc: Darrin Walton , andy , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] query References: <4.3.2.7.2.20010801194858.01a40ed8@brussels.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 01 Aug 2001 12:44:12 -0700 Content-Transfer-Encoding: 7bit stefano previdi wrote: > >I'm not sure what the other router vendor you're using, but what you > >could do is disable the domain or area authentication, and enable > >hello-authentication on each interface. > > I replied offline to this problem but since other people seems to > be interested...yes, the problem has been fixed. Get in touch with > me for details. > Stefano, thanks for clearing it up. Original reaction has been correct, this is not the forum to wash dirty laundries or praise specific implementations unless it affects the protocol specs ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 20:38:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13280 for ; Wed, 1 Aug 2001 20:38:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA46851; Wed, 1 Aug 2001 17:45:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA46836 for ; Wed, 1 Aug 2001 17:44:42 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f720Ynw00526 for ; Wed, 1 Aug 2001 17:34:49 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id C7E011DCC6B; Wed, 1 Aug 2001 17:37:59 -0700 (PDT) Message-ID: <3B689C83.9B895DDE@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org Cc: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] agenda for London ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 01 Aug 2001 17:19:15 -0700 Content-Transfer-Encoding: 7bit 10min Administrativa x draft status x new RFCs 15min draft-hermelin-ext-lsp-frags Amir 15min draft-ietf-isis-transient Danny 20min draft-shand-isis-restart Mike 20min draft-ietf-isis-wg-multi-topology Naiming 15min draft-ietf-isis-auth-anti-replay Alex 5min draft-ietf-isis-wg-tlv-codepoints Tony P. Any other open issues to be discussed at the end after this agenda thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 1 20:42:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13410 for ; Wed, 1 Aug 2001 20:42:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA46896; Wed, 1 Aug 2001 17:49:19 -0700 (PDT) Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA46883 for ; Wed, 1 Aug 2001 17:48:15 -0700 (PDT) Received: from nexthop.com ([64.211.218.17]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f720fXJ12304 for ; Wed, 1 Aug 2001 20:41:34 -0400 (EDT) (envelope-from naamato@nexthop.com) Received: (from naamato@localhost) by nexthop.com (8.11.0/8.11.0) id f720fYc07139 for isis-wg@external.juniper.net; Wed, 1 Aug 2001 20:41:34 -0400 (EDT) From: Nick Amato To: isis-wg@spider.juniper.net Message-ID: <20010801204019.A323@wooj.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [Isis-wg] minor conflict between cksum and hmac Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 1 Aug 2001 20:40:19 -0400 Just a minor thing: draft-ietf-isis-wg-snp-checksum-02.txt states that an implementation MUST either omit the optional checksum or set it to zero when also including, for example, an MD5 signature in an SN PDU. The hmac draft states that the implementation MUST "not include" the checksum TLV. Either will work. The latter is a bit ambiguous; it would be nice to make them consistent. Nick _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 2 22:31:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13320 for ; Thu, 2 Aug 2001 22:31:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA53060; Thu, 2 Aug 2001 19:36:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA53048 for ; Thu, 2 Aug 2001 19:35:00 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f732Ouw45873 for ; Thu, 2 Aug 2001 19:24:56 -0700 (PDT) X-JNPR-Received-From: outside Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ8D00.2DC for ; Thu, 2 Aug 2001 22:07:25 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5URC00.KIL; Fri, 27 Jul 2001 21:57:12 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA09393; Tue, 24 Jul 2001 08:20:56 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA14198 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12619 for ; Tue, 24 Jul 2001 06:29:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05870; Tue, 24 Jul 2001 06:29:25 -0400 (EDT) Message-Id: <200107241029.GAA05870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Jul 2001 06:29:25 -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 : Reserved TLV Codepoints in ISIS Author(s) : T. Przygienda Filename : draft-ietf-isis-wg-tlv-codepoints-00.txt Pages : Date : 23-Jul-01 This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-tlv-codepoints-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-wg-tlv-codepoints-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: <20010723140425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 04:58:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09761 for ; Fri, 3 Aug 2001 04:58:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA54779; Fri, 3 Aug 2001 02:05:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA54764 for ; Fri, 3 Aug 2001 02:04:32 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f738sPw52712 for ; Fri, 3 Aug 2001 01:54:25 -0700 (PDT) X-JNPR-Received-From: outside Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFHE00.GPI for ; Fri, 3 Aug 2001 03:58:26 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5URC00.KIL; Fri, 27 Jul 2001 21:57:12 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA09393; Tue, 24 Jul 2001 08:20:56 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA14198 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12619 for ; Tue, 24 Jul 2001 06:29:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05870; Tue, 24 Jul 2001 06:29:25 -0400 (EDT) Message-Id: <200107241029.GAA05870@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-tlv-codepoints-00.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 24 Jul 2001 06:29:25 -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 : Reserved TLV Codepoints in ISIS Author(s) : T. Przygienda Filename : draft-ietf-isis-wg-tlv-codepoints-00.txt Pages : Date : 23-Jul-01 This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-tlv-codepoints-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-wg-tlv-codepoints-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: <20010723140425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-tlv-codepoints-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-tlv-codepoints-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140425.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 05:57:14 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11544 for ; Fri, 3 Aug 2001 05:57:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA55081; Fri, 3 Aug 2001 03:04:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA55069 for ; Fri, 3 Aug 2001 03:03:41 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f739rYw54227 for ; Fri, 3 Aug 2001 02:53:34 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A04631DCC62; Fri, 3 Aug 2001 02:56:49 -0700 (PDT) To: isis-wg@juniper.net Cc: acee@redback.com, jenny@redback.com, Russ White , Alex Zinin , stefano previdi In-reply-to: Mail from Alex Zinin dated Sat, 28 Jul 2001 02:51:54 PDT <12140487778.20010728025154@nexsi.com> From: Naiming Shen Message-Id: <20010803095649.A04631DCC62@prattle.redback.com> Subject: [Isis-wg] new version of draft-shen-isis-ospf-p2p-over-lan-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 02:56:49 -0700 Here is a newer version of p2p-over-lan draft, missed ietf submission, the text has not been formatted correctly. Please review and comment. thanks. - Naiming Network Working Group Naiming Shen Internet Draft Acee Lindem Expiration Date: February 2001 Jenny Yuan File name: draft-shen-isis-ospf-p2p-over-lan-01.txt Redback Networks Alex Zinin Nexsi Systems Russ White Stefano Previdi Cisco Systems August 2001 Point-to-point operation over LAN in link-state routing protocols draft-shen-isis-ospf-p2p-over-lan-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. Shen, Zinin, et al Expires February 2001 [Page 1] INTERNET DRAFT P2P OVER LAN August 2001 1. Introduction Point-to-point and broadcast are the two predominant circuit types used by link state routing protocols such as IS-IS [ref1] [ref2] and OSPF [ref3]. They are treated differently with respect to establishing neighbor adjacencies, flooding of link-state information, representation of the topology, SPF calculation and protocol packets. The most important differences are that broadcast circuits utilize the concept of a designated router and are represented topologically as virtual nodes in the network topology graph. Compared with broadcast circuits, point-to-point circuits afford more straightforward IGP operation. There is no designated router involved and there is no representation of the pseudo-node or network LSA in the link state database. For ISIS, there also is no periodic database synchronization. Conversely, if there are more than two routers on the LAN media, the traditional view of the broadcast circuit will reduce the routing information in the network. When there are only two routers on the LAN, it makes more sense to treat the connection between the two routers as a point-to-point circuit. This document describes the mechanism to allow link state routing protocols to operate using point-to-point connections over a LAN under this condition. Some implications related to forwarding IP packets on this type of circuit are also discussed. We will refer to this as a p2p-over-lan circuit in this document. 2. Motivation Even though a broadcast circuit is meant to handle more than two devices, there are cases where only two routers are connected over either the physical or logical LAN segment: 1. The media itself is being used for point-to-point operation between two routers. This is mainly for long-haul operation. 2. There are only two routers on the physical LAN. 3. There are only two routers on a virtual LAN (vLAN). In any of the above cases, the link state routing protocols will normally still treat the media as a broadcast circuit. Hence, they will have the overhead involved with protocol LAN operation without the benefits of reducing routing information and optimized flooding. Being able to treat a LAN as a point-to-point circuit provides the benefit of reduction in the amount of information routing protocols must carry and manage. DR/DIS election can be omitted. Flooding can be done as in p2p links without the need of using "LSA reflection" by the DR in OSPF or periodic CSNPs in ISIS. Also, if a broadcast segment wired as a point-to-point link can be treated as a point-to-point link, only the connection between the two routers would need to be advertised as a topological entity. Even when there are multiple routers on the LAN an ISP may want to sub-group the routers into multiple vLANs since this allows them to assign different costs to IGP neighbors. When there are only two routers in some of the vLANs, this LAN can be viewed by the IGP as a mesh of point-to-point connections. As a side benefit, unnumbered interface can also be applied over p2p-over-lan circuits. The advantages of unnumbered point-to-point links are obvious in the current IP addressing environment where addresses are a scarce resource. Separating the concept of network type from media type will allow LANs, e.g. ethernet, to be unnumbered and realize the IP address space savings. Another advantage is in simpler network management and configuration. Shen, Zinin, et al Expires February 2001 [Page 2] INTERNET DRAFT P2P OVER LAN August 2001 3. IP multi-access subnets When an IP network includes multi-access segments, each segment is usually assigned a separate subnet and each router connected to it is assigned a distinct IP address within that subnet. The role of the IP address assigned to a multi-access interface can be outlined as follows: 1. Source IP address - The interface address can be used by the router as the source IP address in locally originated IP packets destined for that subnet or having a best path next hop on that subnet. 2. Destination IP address - The interface address can be used by other devices in the network as a destination address for packets to router applications (examples include telnet, SMTP, TFTP, OSPF, BGP, etc). 3. Next-hop identifier - If other routers connected to the same segment need to forward traffic through the router, the corresponding routes in their routing tables will include the router's interface IP address. This address will be used to find the router's MAC address using the ARP protocol. Effectively, the interface IP addresses help other routers find the data-link layer details that are required to specify the destination of the encapsulating data-link frame when it is sent on the segment. The IP addressing scheme includes an option that allows the administrators to not assign any subnets to point-to-point links (links connecting only two devices and using protocols like PPP, SLIP or HDLC for IP encapsulation). This is possible, because the routers do not need next-hop identifiers on point-to-point links (there is only one destination for any transmission), and an interface independent IP address can be used as the source and destination. Using the unnumbered option for a point-to-point link essentially makes it a purely topological entity used only to reach other destinations. 4. Point-to-point connection over LAN media The idea is very simple: provide a configuration mechanism to inform the IGP that the circuit is type point-to-point irrespective of the physical media type. For the IGP, this implies that it will send protocol packets with the appropriate point-to-point information and expects to receive protocol packets as they would be received on a point-to-point circuit. Over LAN media, the MAC header must contain the correct multicast MAC address to be received by the other side of the connection. For vLAN environments, the MAC header must also contain the proper vLAN ID. In order to allow LAN links used to connect only two routers to be treated as unnumbered point-to-point interfaces, the MAC address resolution and nexthop IP address issues need to be addressed. 4.1 Operation of IS-IS This p2p-over-lan circuit extension for IS-IS is only concerned in pure IP routing and forwarding operation. Since the physically circuit is a broadcast one, the IS-IS protocol packets need to have MAC addresses for this p2p-over-lan circuit. From link layer point of view, those packets are IS-IS LAN packets. The Multi-destination address including AllISs, AllL1ISs and AllL2ISs defined in [ref1] can be used for link layer encapsulation, the use of AllISs is recommended. The circuit needs to have IP address(es) and the p2p IIH over this circuit MUST include the IP interface address(es) as defined in [ref2]. The IP address(es) can be numbered or unnumbered. 4.2 Operation of OSPF OSPF routers supporting the capabilities described herein should support an additional interface configuration parameter specifying the interface topology type. For a LAN (i.e., broadcast capable) interface, the interface may be viewed as a point-to-point interface. Both routers on the LAN will simply join the AllSPFRouters (224.0.0.5) multicast group and send all OSPF packets to 224.0.0.5. This is identical to operation over a physical point-to-point link as described in sections 8.1 and 8.2 of [ref3]. Shen, Zinin, et al Expires February 2001 [Page 3] INTERNET DRAFT P2P OVER LAN August 2001 4.3 IP forwarding and ARP Unlike normal point-to-point IGP circuit, the IP nexthop for the routes using this p2p-over-lan circuit as an outbound interface is not optional. The IP nexthop address has to be a valid interface or internal address on the adjacent router. This address is used by local router to obtain the MAC address for IP packet forwarding. Proxy ARP has to be enabled if the address is not the adjacent interface IP address. In the case where unnumbered IP addresses are used for p2p-over-lan circuit, the source IP address of ARP request and the target interface IP address are usually on different subnets. The ARP should reply only if this is a p2p-over-lan circuit and the source IP address of the ARP request is the same as the neighbor's interface IP address at the other end. The neighbor's address is learned from IGP hello exchanges over this circuit. 4.4 Other MAC address resolution mechanisms In more general cases while p2p-over-lan circuit is used as an unnumbered link, other MAC address resolution mechanisms are needed for IP packet forwarding. For example, if link-state IGP is not configured over this p2p-over-lan link, or Proxy ARP is not enabled on the circuit. The following techniques can be used to acquire the MAC address and/or the next-hop IP address of the remote device on an unnumbered point-to-point LAN link. 1. Static configuration. A router can be statically configured with the MAC address that should be used as the destination MAC address when sending data out of the interface. 2. MAC address gleaning. If a dynamic routing protocol is running between the routers connected to the link, the MAC address of the remote device can be taken from a data-link frame carrying a packet of the corresponding routing protocol. 3. ARP for reference IP address. When a point-to-point link is configured as unnumbered, the router usually associates with it a "reference IP address", that is used as the source IP address in the packets originated for the unnumbered interface. When such an address is known to a router, the router may announce its MAC address by sending a gratuitous ARP message. This solution will also help in the situations where routers calculate the next-hop addresses for the routes through point-to-point interfaces. Since the source IP address in the received routing protocol packet is used as the next- hop address in the route, forwarding an IP packet along such a route will lead to an ARP request submission on the LAN link that will be answered by the remote device. 4. Broadcast/multicast/proprietary. 4.5 Detection of mis-configuration With this p2p-over-lan extension, the difference between a LAN and a point-to-point circuit can be made purely by configuration. It is important to implement the mechanisms for early detection of mis-configuration. If the circuit is configured as point-to-point type and receives LAN hello packets, the router MUST discard the incoming packets; If the circuit is a LAN type and receive point-to-point hello packets, it MUST discard the incoming packets. If the system ID or the router ID of incoming hello packet does not match the system ID or the router ID of already established adjacency over this p2p-over-lan circuit, it MUST discard the packet. The implementation should offer logging and debugging information of the above events. 5. Compatibility considerations Both routers on a LAN must support the p2p-over-lan extension and both must have the LAN segment configured as a p2p-over-lan circuit for successful operation. Both routers MAY also support one of the above listed methods for mapping ip addresses on the link to MAC address, and MUST support proxy ARP on the link. If a proprietary method of IP address to MAC address resolution is used by one router, both routers must be capable of using the same method. Otherwise, the link should be configured as a standard LAN link, with traditional IGP LAN models used. 6. Scalability and deployment considerations There is obvious advantage to use this extension on the LANs that are connected back-to-back or only contain two routers. However, there are tradeoffs when modeling a LAN as multiple vLANs and using this extension since one does sacrifice the inherent scalability benefits of multi-access networks. In general, it will increase the link-state database size, the amount of packets flooded and the route calculation overhead. Network design engineers should carefully balance between the associated overhead. The scalability impact is less of a concern if all the vLANs are within a single OSPF area or ISIS level. Deployment of the described technique brings noticeable benefits from the perspective of IP address usage, the network management and the router configuration. Note, however, that use of the IP unnumbered option for point-to-point LAN links inherits the same problems as those present for serial links, i.e., not being able to ping or monitor a specific interface between routers. 7. Security Issues This document does not introduce any new security issues to ISIS or OSPF. For ARP to support unnumbered IP interface addresses, it needs to verify the p2p-over-lan circuit type described in this document and to verify the ARP packet source interface address to match the IGP adjacency interface IP address. This is due to normal ARP sanity check for common subnet can not be applied in this case. Shen, Zinin, et al Expires February 2001 [Page 4] INTERNET DRAFT P2P OVER LAN August 2001 8. Acknowledgments TBA. 9. References [ref1] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet Engineering Task Force, 1998. 10. Authors' Addresses Naiming Shen Redback Networks 350 Holger Way San Jose, CA, 95134 USA naiming@redback.com Acee Lindem Redback Networks 102 Carric Bend Court Apex, NC 27502 USA acee@redback.com Jenny Yuan Redback Networks 350 Holger Way San Jose, CA, 95134 USA jenny@redback.com Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose, CA 95131 azinin@nexsi.com Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 e-mail: riw@cisco.com Stefano Previdi Cisco Systems, Inc. De Kleetlaan 6A 1831 Diegem - Belgium email: sprevidi@cisco.com Shen, Zinin, et al Expires February 2001 [Page 5] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 06:10:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11850 for ; Fri, 3 Aug 2001 06:10:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA55178; Fri, 3 Aug 2001 03:17:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA55166 for ; Fri, 3 Aug 2001 03:16:46 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f73A6cw54433 for ; Fri, 3 Aug 2001 03:06:39 -0700 (PDT) X-JNPR-Received-From: outside Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp22.cisco.com [144.254.108.89]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA24986 for ; Fri, 3 Aug 2001 11:09:53 +0100 (BST) Message-Id: <4.3.2.7.2.20010803110538.01e24170@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 Subject: [Isis-wg] draft-shand-isis-restart-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 11:06:53 +0100 I haven't seen the announcement go by on IETF-announce yet, but the updated version of isis-restart is there now. http://www.ietf.org/internet-drafts/draft-shand-isis-restart-01.txt Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 07:13:55 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13203 for ; Fri, 3 Aug 2001 07:13:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA55515; Fri, 3 Aug 2001 04:20:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA55500 for ; Fri, 3 Aug 2001 04:19:54 -0700 (PDT) Received: from mail.nexsi.com ([66.35.212.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f73B9kw55520 for ; Fri, 3 Aug 2001 04:09:47 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynam140.sw.nexsi.com [172.17.14.140]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id EAA18647 for ; Fri, 3 Aug 2001 04:14:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <70401748293.20010803041241@nexsi.com> To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] New version of the anti-replay draft. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 04:12:41 -0700 Content-Transfer-Encoding: 7bit Folks, Below is the new version of the document. This includes type-133 sub-TLV format as suggested by Hannes and Tony, the CSN sub-TLV (GenID + SN), separate for each packet type, the Key ID sub-TLV, and using link-level keys for SNPs. This seems to be a good enough approximation to start the discussion. I'll also do some slides in London. -- Alex Zinin Network Working Group Alex Zinin Internet Draft Nexsi Systems Expiration Date: February 2002 August 2001 File name: draft-zinin-isis-auth-anti-replay-00.txt Protecting ISIS from replay attacks draft-zinin-isis-auth-anti-replay-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an additional mechanism for ISIS cryptographic authentication that protects ISIS networks from simple packet replay attacks. 1 Motivation The cryptographic authentication mechanism for [ISIS], described in [HMAC] provides basic authentication functionality sufficient for the majority of situations. However, this mechanism does not protect ISIS networks from the replay attacks that can be performed by the attacker if it has direct access to a broadcast segment within an ISIS domain. Zinin [Page 1] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 Because the mechanism described in [HMAC] does not include the notion of "cryptographic sequence number", an attacker can easily replay previously recorded ISIS packets. Examples of these attacks include replaying an empty (listing no neighbor IS) IIH packets and thus causing routers on the segment to destroy the adjacencies with a specific router, replaying CSNP packets and thus artificially attracting ISIS traffic (LSPs) to the segment's DIS, and so on. When used periodically, these attacks can cause global instability in an ISIS domain. This document defines a simple mechanism, similar to the one proposed for the OSPF protocol in [ETIENNE], to protect an ISIS network from the replay attacks by introducing Cryptographic Sequence Number and Generation ID into ISIS packets. The method is compatible with the existing implementations of [HMAC]. In addition to the Cryptographic Sequence Numbers, the document defines transmission of the cryptographic Key IDs that help routers identify the key to be used for authentication when multiple keys are active during the key transition period. It must be noted that the described mechanism does not attempt to increase purely cryptographic strength of the ISIS authentication mechanism, but rather addresses the problems inside [HMAC]. 2 Proposed Solution Both the Cryptographic Sequence Number and the key ID are introduced into the ISIS packets as sub-TLVs of the TLV type-133. The type-133 TLV is considered to be a part of text T while calculating the HMAC- MD5 digest as defined in [HMAC] (i.e., the type-133 TLV is covered by the digest to prevent spoofing of the values inside the TLV). Sub- TLVs are formatted as described in [ISIS-TE]. This document defines the following sub-TLVs: Type Length (octets) Name 1 8 Cryptographic Sequence Number (CSN) 2 2 Cryptographic Key ID (CKID) [HMAC] specifies that ISIS Sequence Number Packets should be authenticated using the area-level authentication key. In order to prevent attacks based on replaying packets recorded on a different network segment, the implementations are encouraged to support SNP authentication using the link-level key. Note that this requires proper configuration on all routers attached to a network segment. This version of the document does not specify the use of the CSN sub- TLV in ISIS LSPs. Instead, the existing LSP Sequence Number and Zinin [Page 2] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 associated LSP processing procedures are used, with the reservations described in [HMAC]. Note, however, that CKID sub-TLV can be used in all ISIS packets, including LSPs. Implementations not supporting described extensions should ignore the TLVs defined herein. 2.1 Cryptographic Sequence Number sub-TLV. The CSN sub-TLV contains the following data: 2 octets of Generation ID 4 octets of Sequence Number A single instance of the Generation ID is maintained by each ISIS process, initially set to zero, and incremented each time the ISIS module is restarted (e.g., when the router reboots). The Generation ID prevents replay attacks using recorded packets from the previous incarnation of the ISIS process. This document does not specify the exact method of storing the value of the Generation ID across the ISIS module or router restarts, however, it is anticipated that the implementations will use some type of non-volatile memory (flash memory, hard disk, etc.) for this purpose. Each ISIS module also maintains a single instance of the Sequence Number for each {interface, packet-type} combination. The Sequence Number is initially set to zero, and incremented each time a packet of the associated type is sent on the associated interface. Maintaining separate Sequence Numbers for different packet types allows the receiving router to diverge the packet processing paths without affecting the authentication properties of the protocol. The document does not specify the procedure for the situations where the Sequence Number for a specific {interface, packet-type} combination reaches its maximum. A possible approach would be to increase the Generation ID on the router and reset Sequence Number values on all interfaces. 2.1.1 Sending ISIS Packets with CSN sub-TLV When constructing an ISIS packet authenticated using [HMAC], the router may include the CSN sub-TLV in the type-133 TLV. If the TLV is included, it should be considered a part of the text for the digest calculation. After the packet has been sent, the implementation must increase the associated Sequence Number. 2.1.2 Receiving ISIS Packets with CSN sub-TLV Zinin [Page 3] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 ISIS implementations supporting described extensions should maintain the received Generation ID and Sequence Number for each {interface, neighbor, packet-type} combination. These values should be set to zero when a new neighbor data structure is created. When receiving an HMAC-authenticated ISIS packet with a type-133 TLV, the router performs the following checks (if the packet is not HMAC- authenticated, but contains the type-133 TLV, the type-133 TLV should be ignored). 1. If the CSN sub-TLV is present, compare the values found in the TLV with the values in the neighbor data structure (for a specific packet type) as described below. a) If the received Generation ID is less than the locally recorded value, the packet should be ignored. b) Otherwise, if the received Generation ID is greater than the locally recorded value, the Sequence Number should not be checked and step d) should be performed. c) Otherwise, if the received Generation ID is equal to the locally recorded value and the received Sequence Number is not greater than the locally recorded value, the packet should be ignored. d) Perform the packet verification procedure as described in [HMAC] and update the neighbor data structure with the received Generation ID and Sequence Number. 2. If the ISIS packet is authenticated using [HMAC], does not contain the CSN sub-TLV, and the router is configured to perform CSN verification on the receiving interface, the ISIS packet should be ignored. Otherwise (the router is not configured to perform CSN verification), the packet should be authenticated as described in [HMAC]. 2.2 Cryptographic Key ID Sub-TLV The CKID Sub-TLV contains the 16-bit ID of the key that was used to authenticate the packet. Depending on the type and level of the packet, the key ID identifies a specific area or link level authentication key when multiple keys are active at the same time. 2.2.1 Sending Packets with CKID sub-TLV When constructing an HMAC-authenticated packet, a router may include the CKID sub-TLV in the type-133 TLV. If included, the CKID sub-TLV Zinin [Page 4] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 should contain the ID of the key that is used to authenticate the packet. 2.2.2 Receiving Packets with CKID sub-TLV When receiving an HMAC-authenticated PDU with the CKID sub-TLV, the receiving router should locate the key associated with the received key ID and use it for the packet authentication procedure. If the receiving router cannot find the key with specified ID or if the key is not active, the received PDU should be ignored. If the CKID sub- TLV is not present in the PDU, the procedures defined in [HMAC] should be followed (i.e., the CKID sub-TLV does not have to be included for an HMAC-signed ISIS packet to be considered authentic, instead it gives the receiving router a "hint" about the key that should be used for authentication when multiple keys are present). This document does not specify the key management procedure, however, the routers need to agree on the key IDs for the packets to be authenticated correctly. 3 Compatibility Issues Implementations not supporting described extensions will ignore the TLVs defined in this document. Also, implementations supporting the new TLVs will interoperate with implementation using [HMAC] only unless explicitly configured to perform sequence number verification, which is expected to be done when all routers on a segment support described mechanism. 4 Security issues This document describes a mechanism that improves security of the ISIS protocol. 5 Acknowledgements The author would like to thank Hannes Gredler, Tony Przygienda, Ran Atkinson, David Hudek and the rest of the ISIS working group for valuable feedback on this document. 6 References [ISIS] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:1992. [HMAC] Li, T., RJ Atkinson. "IS-IS Cryptographic Authentication" Zinin [Page 5] INTERNET DRAFT Protecting ISIS from replay attacks August 2001 Work in progress. 20 June 2001. draft-ietf-isis-hmac-03.txt. [ETIENNE] Jerome Etienne. "Proposal to fix OSPF cryptographic authentication flaws". [ISIS-TE] Li, T., Henk Smit. "IS-IS extensions for Traffic Engineering". Work in progress. June 2001. draft-ietf-isis- traffic-03.txt 7 Author's address Alex Zinin Nexsi Systems 1959 Concourse Drive San Jose, CA 95131 azinin@nexsi.com Zinin [Page 6] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 16:35:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28653 for ; Fri, 3 Aug 2001 16:35:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA57724; Fri, 3 Aug 2001 13:41:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA57712 for ; Fri, 3 Aug 2001 13:40:52 -0700 (PDT) Received: from mail.nexsi.com ([66.35.212.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f73KUew75082 for ; Fri, 3 Aug 2001 13:30:40 -0700 (PDT) X-JNPR-Received-From: outside Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id NAA24049 for ; Fri, 3 Aug 2001 13:35:27 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <103313634.20010803133339@nexsi.com> To: isis-wg@juniper.net Subject: Re: [Isis-wg] New version of the anti-replay draft. In-Reply-To: <70401748293.20010803041241@nexsi.com> References: <70401748293.20010803041241@nexsi.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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 13:33:39 -0700 Content-Transfer-Encoding: 7bit Folks, One thing that I'd like to be discussed is using CSNs in LSPs. The document does not specify this, but I think this needs attention. My opinion is LSP's native sequence number is not good enough (we lose the state when the LSP is purged, the SN space is reused each reload, etc.), and addressing all packet types but one does not make much sense since all packets are the same from the replaying perspective, the only difference is consequences. A possible approach would be (I mentioned this on the list already) to authenticate LSPs at the link level, i.e., using the link key and CSN, make sure CSNs are not taken into consideration when deciding which LSP is more recent, and ref_cnt the keys to make sure they're not freed when they become inactive, or ISIS is disabled on the interface (or the interface is removed), but there are LSPs that still need the key for periodic verification (btw, this part is not spelled out in HMAC either). Comments are welcome. -- Alex Zinin Friday, August 03, 2001, 4:12:41 AM, Alex Zinin wrote: > Folks, > Below is the new version of the document. This includes > type-133 sub-TLV format as suggested by Hannes and Tony, the > CSN sub-TLV (GenID + SN), separate for each packet type, > the Key ID sub-TLV, and using link-level keys for SNPs. > This seems to be a good enough approximation to start > the discussion. > I'll also do some slides in London. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 17:19:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29439 for ; Fri, 3 Aug 2001 17:19:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA57937; Fri, 3 Aug 2001 14:26:20 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA57925 for ; Fri, 3 Aug 2001 14:25:07 -0700 (PDT) Received: from snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f73LjIo02029 for ; Fri, 3 Aug 2001 14:45:18 -0700 (PDT) X-JNPR-Received-From: outside Received: from redback.com ([63.200.48.117]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHI00M6EG1O2I@mta5.snfc21.pbi.net> for isis-wg@juniper.net; Fri, 03 Aug 2001 14:08:12 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] agenda for London ... To: agenda@ietf.org, isis-wg@juniper.net Message-id: <3B6B0E50.6F2F4A3C@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: <3B689C83.9B895DDE@redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 03 Aug 2001 13:49:21 -0700 Content-Transfer-Encoding: 7BIT small revision, we'll have > 10min Administrativa > x draft status > x new RFCs > > 15min draft-hermelin-ext-lsp-frags Amir > 15min draft-ietf-isis-transient Danny > 20min draft-shand-isis-restart Mike > 20min draft-ietf-isis-wg-multi-topology Naiming 15min draft-shen-isis-ospf-p2p-over-lan-01 ? > > 15min draft-ietf-isis-auth-anti-replay Alex > 5min draft-ietf-isis-wg-tlv-codepoints Tony P. > > Any other open issues to be discussed at the end after > this agenda unless anybody objects since technically this draft didn't make the cut-off date (but it's not the only one). thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 3 22:28:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03461 for ; Fri, 3 Aug 2001 22:28:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA59146; Fri, 3 Aug 2001 19:35:19 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA59130 for ; Fri, 3 Aug 2001 19:34:41 -0700 (PDT) Received: from mail4.bigmailbox.com (mail4.bigmailbox.com [209.132.220.35]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f742ORw84205 for ; Fri, 3 Aug 2001 19:24:27 -0700 (PDT) X-JNPR-Received-From: outside Received: by mail4.bigmailbox.com (8.8.7/8.8.7) id TAA19291; Fri, 3 Aug 2001 19:27:44 -0700 Message-Id: <200108040227.TAA19291@mail4.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [61.144.161.2] From: "R Selvaraj" To: isis-wg@juniper.net Cc: eta_selvarajr@partner.huawei.com Subject: [Isis-wg] Doubt regarding Default Informatoin Originate Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 19:27:44 -0700 Content-Transfer-Encoding: binary Hi, I would like to know the advantage of originating default information in L1 LSPs. Since Att bit itself is sufficient for finding default route in a L1 area then what is the significant of originating default informaton in L1 LSPs. Pls let me clarified. Thanks, Selva. ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Aug 5 11:09:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14665 for ; Sun, 5 Aug 2001 11:09:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA69833; Sun, 5 Aug 2001 08:15:20 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA69818 for ; Sun, 5 Aug 2001 08:14:35 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f75F45w04038 for ; Sun, 5 Aug 2001 08:04:05 -0700 (PDT) X-JNPR-Received-From: outside Received: from SPREVIDI-W2K.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA14258; Sun, 5 Aug 2001 17:07:05 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010804082031.0367a538@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "R Selvaraj" From: stefano previdi Subject: Re: [Isis-wg] Doubt regarding Default Informatoin Originate Cc: isis-wg@juniper.net, eta_selvarajr@partner.huawei.com In-Reply-To: <200108040227.TAA19291@mail4.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 05 Aug 2001 17:04:33 +0200 At 04:27 04/08/2001, R Selvaraj wrote: >Hi, > >I would like to know the advantage of originating default information in >L1 LSPs. Since Att bit itself is sufficient for finding default route in a >L1 area then what is the significant of originating default informaton in >L1 LSPs. >Pls let me clarified. there are many reasons why you prefer to have an IP-specific default route: - your network is a single level-1 area. - your AS boundary is a level-1 router and you want to use it as default exit point. - ATT bit is only set based on clns information while an IP default route can be advertised based on IP information. - probably other good reasons... s. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 00:22:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00130 for ; Mon, 6 Aug 2001 00:22:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA73029; Sun, 5 Aug 2001 21:28:20 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA73017 for ; Sun, 5 Aug 2001 21:27:37 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 04:20:25 -0000 X-Apparently-From: Message-ID: <0d8a01c11e2f$9e855940$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] ISIS and OSPF Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 09:53:58 +0530 Content-Transfer-Encoding: 7bit Hi, OSPF and ISIS are both very similar in a lot of respects and i wanted to know as to which protocol scales better when deployed as an IGP ? Secondly, with the coming of IPv6 which protocol holds a better future. If we are using OSPF then we will have to write a completely new protocol and our IPv4/IPv6 transition router running a dual stack will have to run both the copies of OSPF .. This can be avoided with ISIS wherein we have 20 byte address field length. Any help on this would be very much appreciated. Thanks and Regards, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 01:08:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01036 for ; Mon, 6 Aug 2001 01:08:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA73289; Sun, 5 Aug 2001 22:15:20 -0700 (PDT) Received: from web20208.mail.yahoo.com (web20208.mail.yahoo.com [216.136.226.63]) by external.juniper.net (8.9.3/8.9.3) with SMTP id WAA73274 for ; Sun, 5 Aug 2001 22:14:57 -0700 (PDT) Message-ID: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Received: from [203.200.20.224] by web20208.mail.yahoo.com; Sun, 05 Aug 2001 22:07:46 PDT From: Swati Rastogi To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] Help Reqd ! Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 5 Aug 2001 22:07:46 -0700 (PDT) Hi, I am new to this protocol and i am going thru the RFC 1142 and am facing the following problems :- (1) What does rfc 1142 mean by "adjaceny" .. Is it an interface on which the packets are sent ?? If yes, then what is a link ? (2) What is a circuit ? (3) I was going through the presentation given by Dave Katz where he compares OSPF and ISIS. What is troubling me is the fact that in one of his slides he says that OSPF runs over IP while ISIS runs besides IP. Now in Dual ISIS we encapsulate our ISIS packet over the IP. So we are still using IP. (4) As far as i understand we send CSNPs to list the sequence numbers of one or more LSPs operating ... and as an ACK. Why do we then send Partial SNPs ?? Thanks and regards, Swati Rastogi __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 04:38:36 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19447 for ; Mon, 6 Aug 2001 04:38:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA74200; Mon, 6 Aug 2001 01:45:21 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by external.juniper.net (8.9.3/8.9.3) with SMTP id BAA74185 for ; Mon, 6 Aug 2001 01:44:14 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 08:37:01 -0000 X-Apparently-From: Message-ID: <0f6501c11e53$76dfecb0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Swati Rastogi" , References: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Subject: Re: [Isis-wg] Help Reqd ! Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 14:10:32 +0530 Content-Transfer-Encoding: 7bit > (1) What does rfc 1142 mean by "adjaceny" .. Is it an > interface on which the packets are sent ?? If yes, > then what is a link ? AFAIK adjacencies tell me what all routers/systems are connected to my router. Link refers to the actual hardware interface. > (2) What is a circuit ? Adjacencies can be of many types .. end system,L1 or L2 reachable address prefixes. Within each type based we have circuit ID which differentiaties as to whether it is a non broadcast circuit OR broadcast circuit when running level 1 decision process . .etc (Refer to 7.2.7 rfc 1142) > (3) I was going through the presentation given by Dave > Katz where he compares OSPF and ISIS. What is > troubling me is the fact that in one of his slides he > says that OSPF runs over IP while ISIS runs besides > IP. Now in Dual ISIS we encapsulate our ISIS packet > over the IP. So we are still using IP. No Idea ! > (4) As far as i understand we send CSNPs to list the > sequence numbers of one or more LSPs operating ... and > as an ACK. Why do we then send Partial SNPs ?? CSNPs are routing packets sent out of the designated router (on a LAN) to summarize all the LSPs in its database. These are recieved by other direct neighbouring ISs on the LAN and are used to maintain synchronization of link state databases amongst all ISs.The synchronization procedure is different on LANs and point to point links. On a point to point link, all the LSPs transmitted must be explicitly acknowledged by a Partial SNP from the other router. Unacknowledged LSPs are retransmitted. Regards, Manav Bhatia _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 08:30:28 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22044 for ; Mon, 6 Aug 2001 08:30:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA75298; Mon, 6 Aug 2001 05:37:21 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA75286 for ; Mon, 6 Aug 2001 05:36:09 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 06 Aug 2001 18:06:41 +0530 Received: from rameshrr (rameshrr.future.futsoft.com [192.168.5.19]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f76CRhB19941 for ; Mon, 6 Aug 2001 17:57:43 +0530 From: "Rayapureddi Ramesh" To: "'isis'" Message-Id: <000f01c11e74$8abe2000$1305a8c0@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MS-TNEF-Correlator: 00000000A220E83B6167D411AACD0050DABB295484D02800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_01C11EA2.A47AEFE0" Subject: [Isis-wg] Reg: Over Load bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 18:07:20 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C11EA2.A47AEFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, ISO/IEC FCD 10589 ISIS Standardis saying that "As a result of network misconfiguration, or certain transitory conditions, it is possible that there may be insufficient resources available to store the a received Link State PDU. When this occurs, an IS needs to take certain steps to ensure that if its LSP database becomes inconsistent with other IS's, that these ISs do not rely on forwarding paths through the overloaded IS". Take an example.. R1-----------------R2--------------------R3 | | | | | | R4------------------R5 Here R1 forward to R2 if any packet destined to routers R3, R4 and R5 by considering the forwarding path through R2 (i.e since R1 have route to R3, R4 and R5 with R2 as next hop). If R2 advertises an LSP with Overload Bit set, then R1 should not forward to R2 if any packet destined to R3, R4 and R5 since here R1 will not consider forwarding path through R2 (i.e it will not install routes to R3, R4 and R5 with next hop as R2). Am I correct?. Here my doubt is---- will this applicable to IP information (in LSP packet) also OR only to OSI information only while processing the LSPs received from overloaded IS?. Please clarify doubt. Regards, Ramesh ------=_NextPart_000_0010_01C11EA2.A47AEFE0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhcMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAAGABIABwAAAAEAAAEB A5AGAFwHAAAjAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAEwAAAFJlZzogT3ZlciBMb2FkIGJpdAAAAgFxAAEAAAAWAAAAAcEedIkZ7plDYoo6EdWsAABQ 2rspVAAAAgEdDAEAAAAhAAAAU01UUDpSQU1FU0hSUkBGVVRVUkUuRlVUU09GVC5DT00AAAAACwAB DgAAAABAAAYOAH6vfHQewQECAQoOAQAAABgAAAAAAAAAoiDoO2Fn1BGqzQBQ2rspVMKAAAADABQO AQAAAAsAHw4BAAAAAgEJEAEAAAC9AwAAuQMAAMIGAABMWkZ19/rHcwMACgByY3BnMTI1FjIA+Atg bg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGAOYwBQCwMLtSBIaSwH CqIKhAqASVNPL0mARUMgRkNEIA9A8DU4OSAUwBTABgABkIcSgAsRBAAgc2F5C4CYZyB0EPAFQCJB BCBEYSAJcHN1bAVAbyhmIG4RMHcFsGsghm0EAAWgbmZpZwhwtRdwaQIgLBhgBcBjBJBfAZALgBdA GcAAgXQFsHnvGmACIBagGeJzGiAbQBxQqQQgcG8EEGkCYGUXRN8XUASQHTAAwBuAYh0wC4D/GCAB IA3gCJACMBfyCGEacN0XwXYLcAtgHRNvFtAbUU8dMh0wF+IacGl2CYAgLkwLgBkAFjF0HTBQRLBV LiBXHbAa0WgWsfhvY2MIcBwxA5EWARig7wmABCAggQGQax0wGnYgsPxlcCTDCfAYICDjF3EGkMMc UQQgTFNQIBZwAZH+YREgHjEFoAeCC4AZUQCQfyXhHxED8BdQGGAdohXRJ18cMR1WKEEUwAQgZCCQ blsqEBfxbBuAAiAgAhByvncWghchCrAXUCTBaANgrHVnKfAhEm8hwHIJAG5hAQAh4BTAIiLgFApU QyUiA5FleGFtC1BldC4uFAQgMbAxVzJJUmQxLTNOUjIzTzQiM/cx7zbfMkZ8N284FTXfOw//N/85 DzofP088Pz1PPl9Dj20yxTQ0rzRANRQKFARI/x3CMyAspiByNFAnIgBwG4D9CrBjJTAFQAEAILAL gCHR3yCBLeEigBEQB/AzGiBFAO8kESHgRkAxsGIbgwCQBIEfFxQdMCy9LbdIsShpLv8dMACQKQBH sxDwIcBKdEhzX0sbKcNIsSgwGJF4BUBoeG9wKTFGFGUYgFHCZH8ukRngESAXwQOgJ6Ipw0/5LpUg QhxhESEqsiMhR9H+c1JwGDAh4CvySA9JH0ok30sMTyQds0fRA/BsAyAr8v9MJk0fTi4cYVv3HnEB kFwR/0qDJMNQnynwUiZR4jRQUqZZFARBbRXQG5FyIXF0Nj9jG0eDbRuAK8B1Yp8cckUyL3Vb8yNT YXALUPsN4CA2SSfAC4AssQDAGeLXTsFUtFkEKRfQbB9gVVDuUixxLFEggU8V8GjbayP2dyNgHSFw A2AfoU8hTMS/J6EEICF3A1IufGSsUB0gfSgyYwtgBoFl5WMbFARSfGVnCxEcMHM1MOAHkGi/Qm91 33bvMkUUBBHhAHkQAAAAAwAJWQMAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMA AoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUA AD9xAQADAAiACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAC4AIIAYAAAAAAMAAAAAAAABG AAAAAAGFAAAAAAAAHgASgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAFoAI IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAXgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA AAALAHuACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAIB+A8BAAAAEAAAAKIg6DthZ9QRqs0A UNq7KVQCAfoPAQAAABAAAACiIOg7YWfUEarNAFDauylUAgH7DwEAAABQAAAAAAAAADihuxAF5RAa obsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5OVFxtYWlsXHJh bWVzaHJyLnBzdAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDBBMjIwRTgzQjYx NjdENDExQUFDRDAwNTBEQUJCMjk1NDg0RDAyODAwAAAAAAMABhAR6qD2AwAHEL0DAAADABAQAAAA AAMAERAAAAAAHgAIEAEAAABlAAAASEksSVNPL0lFQ0ZDRDEwNTg5SVNJU1NUQU5EQVJESVNTQVlJ TkdUSEFUIkFTQVJFU1VMVE9GTkVUV09SS01JU0NPTkZJR1VSQVRJT04sT1JDRVJUQUlOVFJBTlNJ VE9SWUNPTgAAAABHyw== ------=_NextPart_000_0010_01C11EA2.A47AEFE0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 09:09:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22772 for ; Mon, 6 Aug 2001 09:09:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75498; Mon, 6 Aug 2001 06:15:20 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75478 for ; Mon, 6 Aug 2001 06:14:36 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f76D7A521695; Mon, 6 Aug 2001 09:07:10 -0400 (EDT) Received: from sevsisters (jlearman-dsl3.cisco.com [10.83.2.140]) by dingdong.cisco.com (Mirapoint) with SMTP id AAB07803; Mon, 6 Aug 2001 09:07:20 -0400 (EDT) Message-ID: <007401c11e78$b9c9bf40$8c02530a@sevsisters> From: "Jeff Learman" To: "Manav Bhatia" , References: <0d8a01c11e2f$9e855940$da046c6b@Manav> Subject: Re: [Isis-wg] ISIS and OSPF MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 08:51:21 -0400 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Manav Bhatia To: Sent: Monday, August 06, 2001 12:23 AM Subject: [Isis-wg] ISIS and OSPF > Hi, > OSPF and ISIS are both very similar in a lot of respects and i wanted to > know as to which protocol scales better when deployed as an IGP ? > Secondly, with the coming of IPv6 which protocol holds a better future. If > we are using OSPF then we will have to write a completely new protocol and > our IPv4/IPv6 transition router running a dual stack will have to run both > the copies of OSPF .. This can be avoided with ISIS wherein we have 20 byte > address field length. I don't know enough about OSPF to answer your questions. However, the address length of IS-IS isn't much of a help because it is always an OSI address (NSAP), not an IP address, and every router that is operating IS-IS has an NSAP. IPV6 can be supported in IS-IS for the same reasons that IPV4 could be -- because new reachability information can be added in the form of new TLV-encoded options. I would guess that this is equally true for OSPF, although it may be necessary to continue to give each OSPF router an IPV4 address with certain uniqueness requirements. Regards, Jeff > Any help on this would be very much appreciated. > > Thanks and Regards, > Manav > > "C is not a big language, and is not well served by a big book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 09:09:28 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22782 for ; Mon, 6 Aug 2001 09:09:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75514; Mon, 6 Aug 2001 06:15:50 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75480 for ; Mon, 6 Aug 2001 06:14:36 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f76D7A521698; Mon, 6 Aug 2001 09:07:11 -0400 (EDT) Received: from sevsisters (jlearman-dsl3.cisco.com [10.83.2.140]) by dingdong.cisco.com (Mirapoint) with SMTP id AAB07804; Mon, 6 Aug 2001 09:07:21 -0400 (EDT) Message-ID: <007501c11e78$ba1daba0$8c02530a@sevsisters> From: "Jeff Learman" To: "Swati Rastogi" , References: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Subject: Re: [Isis-wg] Help Reqd ! MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 09:05:31 -0400 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Swati Rastogi To: Sent: Monday, August 06, 2001 1:07 AM Subject: [Isis-wg] Help Reqd ! > Hi, > I am new to this protocol and i am going thru the RFC > 1142 and am facing the following problems :- These terms are defined in ISO 10589, which must be read for a thorough understanding of IS-IS. > (1) What does rfc 1142 mean by "adjaceny" .. Is it an > interface on which the packets are sent ?? If yes, > then what is a link ? An adjacency is a (circuit, l2 address) pair identifying a means of reaching an immediate neighbor. So, an adjacency is like a neighbor, except that you can have multiple adjacencies to a single neighbor, e.g., if it has to L2 addresses on one link or two links between you and it. > (2) What is a circuit ? A link. > (3) I was going through the presentation given by Dave > Katz where he compares OSPF and ISIS. What is > troubling me is the fact that in one of his slides he > says that OSPF runs over IP while ISIS runs besides > IP. Now in Dual ISIS we encapsulate our ISIS packet > over the IP. So we are still using IP. Nope. The encapsulation does not change; IS-IS runs directly over the link layer and does not use IP or OSI layer 3 addressing in communications between neighbors. > (4) As far as i understand we send CSNPs to list the > sequence numbers of one or more LSPs operating ... and > as an ACK. Why do we then send Partial SNPs ?? As ACKs on point-to-point links. The rules are different for point-to-point links and broadcast links and I don't have the details on the top of my head, but in general, PSNPs are used as ACKs, and CSNPs are used periodically. > Thanks and regards, > Swati Rastogi > > > > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 09:12:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22814 for ; Mon, 6 Aug 2001 09:12:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75606; Mon, 6 Aug 2001 06:20:21 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75591 for ; Mon, 6 Aug 2001 06:19:15 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (ams-clip-vpn-dhcp21.cisco.com [10.50.0.20]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA06328; Mon, 6 Aug 2001 15:11:47 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010806150002.0338dfd8@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Rayapureddi Ramesh" From: stefano previdi Subject: Re: [Isis-wg] Reg: Over Load bit Cc: "'isis'" In-Reply-To: <000f01c11e74$8abe2000$1305a8c0@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 06 Aug 2001 15:09:10 +0200 At 14:37 06/08/2001, Rayapureddi Ramesh wrote: >Hi, > >ISO/IEC FCD 10589 ISIS Standardis saying that "As a result of network >misconfiguration, or certain transitory conditions, it is possible that >there may be insufficient resources available to store the a received Link >State PDU. When this occurs, an IS needs to take certain steps to ensure >that if its LSP database becomes inconsistent with other IS's, that these >ISs do not rely on forwarding paths through the overloaded IS". > >Take an example.. > > R1-----------------R2--------------------R3 > | | > | | > | | > R4------------------R5 > > >Here R1 forward to R2 if any packet destined to routers R3, R4 and R5 by >considering the forwarding path through R2 (i.e since R1 have route to R3, >R4 and R5 with R2 as next hop). > >If R2 advertises an LSP with Overload Bit set, then R1 should not forward to >R2 if any packet destined to R3, R4 and R5 since here R1 will not consider >forwarding path through R2 (i.e it will not install routes to R3, R4 and R5 >with next hop as R2). > >Am I correct?. yes. >Here my doubt is---- >will this applicable to IP information (in LSP packet) also OR only to OSI >information only while processing the LSPs received from overloaded IS?. When running SPF, you don't move into the TENT list the neighbors of a node if such node has the overload-bit set. Therefore you won't continue to build the sub-tree after the overload-bit-node. This means that any route advertised by nodes downstream to the overload-bit-node will simply be never calculated, no matter their address family. s. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 09:18:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22872 for ; Mon, 6 Aug 2001 09:18:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75660; Mon, 6 Aug 2001 06:25:21 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by external.juniper.net (8.9.3/8.9.3) with SMTP id GAA75645 for ; Mon, 6 Aug 2001 06:24:50 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 13:17:35 -0000 X-Apparently-From: Message-ID: <123401c11e7a$a8e5cb40$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Jeff Learman" , References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> Subject: Re: [Isis-wg] ISIS and OSPF Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 18:51:05 +0530 Content-Transfer-Encoding: 7bit Thanks Jeff for the reply ! > of new TLV-encoded options. I would guess that this is equally true for > OSPF, although it may be necessary to continue to give each OSPF router > an IPV4 address with certain uniqueness requirements. But the very reason why IPv6 is coming into picture is the paucity of IPv4 addresses. So if OSPF has to support unique IPv4 addresses then how can it work in an IPv6 environment ? Secondly, in the present scenario (IPv4) which is considreded as a better IGP .. in terms of scalability ? Regards, Manav _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 09:52:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23392 for ; Mon, 6 Aug 2001 09:52:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA75928; Mon, 6 Aug 2001 06:59:21 -0700 (PDT) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by external.juniper.net (8.9.3/8.9.3) with SMTP id GAA75916 for ; Mon, 6 Aug 2001 06:58:17 -0700 (PDT) Received: (qmail 62673 invoked from network); 6 Aug 2001 13:51:03 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Aug 2001 13:51:03 -0000 From: "Ken Larmer" To: "Swati Rastogi" , Subject: RE: [Isis-wg] Help Reqd ! Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010806050746.18588.qmail@web20208.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 09:52:48 -0400 Content-Transfer-Encoding: 7bit > Hi, > I am new to this protocol and i am going thru the RFC > 1142 and am facing the following problems :- > > (1) What does rfc 1142 mean by "adjaceny" .. Is it an > interface on which the packets are sent ?? If yes, > then what is a link ? From an IS perspective, a directly attached IS neighbour becomes an adjacency if the Broadcast or Non-Broadcast initialization process succeeds between the 2 neighbours. This includes IIH PDU Acceptance Tests, Area Address Tests, Adjacency Tests and Adjacency Communication Tests. Once a FULL adjacency has been formed, the 2 IS neighbours will exchange routing information. > (2) What is a circuit ? A circuit references a link level connection, which connects at least 2 IS neighbours together so they may form an adjacency. Circuit-IDs identify individual links for purposes of path pruning and detection of 2-way communication. > (3) I was going through the presentation given by Dave > Katz where he compares OSPF and ISIS. What is > troubling me is the fact that in one of his slides he > says that OSPF runs over IP while ISIS runs besides > IP. Now in Dual ISIS we encapsulate our ISIS packet > over the IP. So we are still using IP. What Dave means here is that OSPF control packets are encapsulated in IP packets. Whereas IS-IS control packets are encapsulated in CLNS packets. Both OSPF and ISIS forward Data packets in their native format, IP packets for IP data and CLNS packets for OSI data. A Dual ISIS will forward both IP and CLNS Data packets. > (4) As far as i understand we send CSNPs to list the > sequence numbers of one or more LSPs operating ... and > as an ACK. Why do we then send Partial SNPs ?? This is dependant upon the link type, Broadcast (LAN) or Non-Broadcast (Point-to-Point). On a Broadcast circuit we elect a Designated Router for purposes of synchronizing the LSP Databases amongst a common set of LAN ISs. The DR periodically advertises the state of its LSP Database to the rest of the LAN via CSNPs. If a CSNP does not contain a particular LSP, which another IS on the LAN currently possesses in its LSP Database, the detecting IS will flood that LSP onto the LAN. However, if the CSNP contains a LSP reference to an LSP, which is not present in an adjacent LAN IS LSP Database, that detecting IS will send a PSNP requesting that particular LSP. The DR, upon receipt of the PSNP, will then flood that LSP onto the given LAN. On a Non-Broadcast circuit, CSNPs are sent at initialization and/or during circuit restart. This lets the adjacent IS know what the remote IS possesses in its LSP database(s). Both sides of the link set the SRMflag for all LSPs contained within their respective LSP databases prior to sending the CSNPs (there are some rules which apply). The CSNP LSP Entries are then processed to determine if the LSP Databases are synchronized. CSNP referenced LSP Entries which are non-referenced or newer in the remote LSP Database are requested via a PSNP and/or transmitted as a result of the SRMflag being set. CSNP referenced LSP Entries which are non-existent or older in the remote LSP Database are updated by the local IS as a result of receiving a PSNP request or as a result of the SRMflag being set (one in the same). No action is taken for CSNP referenced LSP Entries which are the same (no PSNP sent, just clear the SRMflag, receipt of the same LSP is equal to receipt of a PSNP acknowledgement). Once an LSP has been received on a non-broadcast link, a PSNP is sent as an acknowledgement to that LSP. Hope this helps? Cheers, Ken Larmer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 10:13:58 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23828 for ; Mon, 6 Aug 2001 10:13:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA76062; Mon, 6 Aug 2001 07:20:21 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA76047 for ; Mon, 6 Aug 2001 07:19:49 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f76ECN527527; Mon, 6 Aug 2001 10:12:23 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAD00768; Mon, 6 Aug 2001 10:12:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manav Bhatia" From: Jeff Learman Subject: Re: [Isis-wg] ISIS and OSPF Cc: In-Reply-To: <123401c11e7a$a8e5cb40$da046c6b@Manav> References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 06 Aug 2001 10:08:03 -0400 At 09:21 AM 8/6/2001, Manav Bhatia wrote: >Thanks Jeff for the reply ! >> of new TLV-encoded options. I would guess that this is equally true for >> OSPF, although it may be necessary to continue to give each OSPF router >> an IPV4 address with certain uniqueness requirements. >But the very reason why IPv6 is coming into picture is the paucity of IPv4 >addresses. So if OSPF has to support unique IPv4 addresses then how can it >work in an IPv6 environment ? First, I'm making a guess about OSPF. Let's wait and see what someone with more OSPF knowledge says. Second, there will be many more end systems than routers, so if only routers have IPV4 addresses, then there may be an order of magnitude or two of growth before the problem becomes critical again. Also, I said that there were uniqueness requirements, but I don't know precisely what these uniqueness requirements are. It is likely that routers belonging to one AS can use local IP addresses that are unique only within that AS. >Secondly, in the present scenario (IPv4) which is considreded as a better >IGP .. in terms of scalability ? Can't help you there! Studies that I have done with IS-IS indicate that it is surprisingly scalable in terms of bandwidth usage, even with relatively unreliable routers with short MTBFs (like days!). The practical limit of IS-IS is probably related to its two-level hierarchy rather than N-level hierarchy. Radia Perlman has ideas on how it could be extended to support that, but so far there is little interest. Evidently the scalability limits of IS-IS have not been reached, or else those who run IS-IS and have scalability issues are not making themselves heard on this forum. The biggest problem with scalability will probably be how long it takes to stabilize after a topology change. The greater the span of the sub-domain (area or routing domain), the greater the time. Multi-level IS-IS could be used to improve this, in hierarchical topologies that could take advantage of it. Regards, Jeff >Regards, >Manav > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 10:33:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24044 for ; Mon, 6 Aug 2001 10:33:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA76197; Mon, 6 Aug 2001 07:40:21 -0700 (PDT) Received: from mailhost.bravara.com (mailhost.bravidacorp.com [38.168.15.229]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA76182 for ; Mon, 6 Aug 2001 07:39:42 -0700 (PDT) Received: from chrislaptop (adsl-64-123-15-43.dsl.austtx.swbell.net [64.123.15.43]) by mailhost.bravara.com (Mirapoint) with ESMTP id AAA02749 (AUTH chris); Mon, 6 Aug 2001 07:32:24 -0700 (PDT) From: "Chris Flores" To: "Swati Rastogi" , Subject: RE: [Isis-wg] Help Reqd ! Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 5 Aug 2001 21:32:21 -0500 Content-Transfer-Encoding: 7bit My response is in-line. I hope it helps. Thanks. Chris -----Original Message----- From: isis-wg-admin@spider.juniper.net [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Swati Rastogi Sent: Monday, August 06, 2001 12:08 AM To: isis-wg@spider.juniper.net Subject: [Isis-wg] Help Reqd ! Hi, I am new to this protocol and i am going thru the RFC 1142 and am facing the following problems :- (1) What does rfc 1142 mean by "adjaceny" .. Is it an interface on which the packets are sent ?? If yes, then what is a link ? cf: The IS-IS protocol builds (and maintains) adjacencies between IS's or routers. A pair of neighboring IS's are said to be adjacent after they exchange CNSPs and synchronize their databases. A separate adjacency is created for each neighbor (on a circuit) and for each level of routing (on broadcast media). A link is a communication path between two neighbors. (2) What is a circuit ? (3) I was going through the presentation given by Dave Katz where he compares OSPF and ISIS. What is troubling me is the fact that in one of his slides he says that OSPF runs over IP while ISIS runs besides IP. Now in Dual ISIS we encapsulate our ISIS packet over the IP. So we are still using IP. cf: See RFC 1195. The IS-IS PDUs are transmitted directly over the underlying link layer services without the need for mutual encapsulation. (4) As far as i understand we send CSNPs to list the sequence numbers of one or more LSPs operating ... and as an ACK. Why do we then send Partial SNPs ?? cf: A PSNP is used to request the latest LSP from another IS. In addition, the PSNP is an ACK for the receipt of a new LSP. http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 11:01:03 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24923 for ; Mon, 6 Aug 2001 11:01:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA76409; Mon, 6 Aug 2001 08:07:21 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA76397 for ; Mon, 6 Aug 2001 08:06:25 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 14:59:09 -0000 X-Apparently-From: Message-ID: <134a01c11e88$d917b680$da046c6b@Manav> From: "Swati Rastogi" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Doubt on L2 router Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 20:32:38 +0530 Content-Transfer-Encoding: 7bit Hi All, In OSPF if the designated router fails then the backup designated router takes over and all of this is done automatically. But in ISIS we have a router configured as a L2 router drilled in the profiles. What would happen if this router goes down for some reason ? Since this is the only link via which the routers inside this area can communicate to the outside world. Does it imply that the routers are now blackholed ! This would imply that the protocol has a single point of failure .. Regards, Swati Rastogi _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 11:11:36 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25210 for ; Mon, 6 Aug 2001 11:11:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA76492; Mon, 6 Aug 2001 08:18:21 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA76475 for ; Mon, 6 Aug 2001 08:17:40 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f76FAE502098; Mon, 6 Aug 2001 11:10:14 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAD02412; Mon, 6 Aug 2001 11:10:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20010806105246.01f1af10@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] Help Reqd ! Cc: "Swati Rastogi" , In-Reply-To: References: <20010806050746.18588.qmail@web20208.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 06 Aug 2001 11:01:46 -0400 At 09:52 AM 8/6/2001, Ken Larmer wrote: >> Hi, >> I am new to this protocol and i am going thru the RFC >> 1142 and am facing the following problems :- >> >> (1) What does rfc 1142 mean by "adjaceny" .. Is it an >> interface on which the packets are sent ?? If yes, >> then what is a link ? > > From an IS perspective, a directly attached IS neighbour becomes an >adjacency if the Broadcast or Non-Broadcast initialization process succeeds >between the 2 neighbours. This includes IIH PDU Acceptance Tests, Area >Address Tests, Adjacency Tests and Adjacency Communication Tests. Once a >FULL adjacency has been formed, the 2 IS neighbours will exchange routing >information. Well put. Don't forget that end systems can also have adjacencies, although this may be less important for IP than for OSI, where it is critical. >> (2) What is a circuit ? > >A circuit references a link level connection, which connects at least 2 IS >neighbours together so they may form an adjacency. Circuit-IDs identify >individual links for purposes of path pruning and detection of 2-way >communication. Again, End System adjacencies can appear on a circuit, even if there are no other ISs on the link. This may be of no importance for an IP-only router. >> (3) I was going through the presentation given by Dave >> Katz where he compares OSPF and ISIS. What is >> troubling me is the fact that in one of his slides he >> says that OSPF runs over IP while ISIS runs besides >> IP. Now in Dual ISIS we encapsulate our ISIS packet >> over the IP. So we are still using IP. > >What Dave means here is that OSPF control packets are encapsulated in IP >packets. Whereas IS-IS control packets are encapsulated in CLNS packets. >Both OSPF and ISIS forward Data packets in their native format, IP packets >for IP data and CLNS packets for OSI data. A Dual ISIS will forward both IP >and CLNS Data packets. Be careful when you read "encapsulated in CLNS packets". It is absolutely correct, but does NOT mean that they are encapsulated in CLNP packets. It does mean that they are OSI connectionless layer three packets and therefore begin with a Network Layer Protocol ID (variously called NPID, NLPI, or NLPID). After that first octet, IS-IS and CLNP headers have little in common. Regards, Jeff >> (4) As far as i understand we send CSNPs to list the >> sequence numbers of one or more LSPs operating ... and >> as an ACK. Why do we then send Partial SNPs ?? > >This is dependant upon the link type, Broadcast (LAN) or Non-Broadcast >(Point-to-Point). > >On a Broadcast circuit we elect a Designated Router for purposes of >synchronizing the LSP Databases amongst a common set of LAN ISs. The DR >periodically advertises the state of its LSP Database to the rest of the LAN >via CSNPs. If a CSNP does not contain a particular LSP, which another IS on >the LAN currently possesses in its LSP Database, the detecting IS will flood >that LSP onto the LAN. However, if the CSNP contains a LSP reference to an >LSP, which is not present in an adjacent LAN IS LSP Database, that detecting >IS will send a PSNP requesting that particular LSP. The DR, upon receipt of >the PSNP, will then flood that LSP onto the given LAN. > >On a Non-Broadcast circuit, CSNPs are sent at initialization and/or during >circuit restart. This lets the adjacent IS know what the remote IS possesses >in its LSP database(s). Both sides of the link set the SRMflag for all LSPs >contained within their respective LSP databases prior to sending the CSNPs >(there are some rules which apply). The CSNP LSP Entries are then processed >to determine if the LSP Databases are synchronized. CSNP referenced LSP >Entries which are non-referenced or newer in the remote LSP Database are >requested via a PSNP and/or transmitted as a result of the SRMflag being >set. CSNP referenced LSP Entries which are non-existent or older in the >remote LSP Database are updated by the local IS as a result of receiving a >PSNP request or as a result of the SRMflag being set (one in the same). No >action is taken for CSNP referenced LSP Entries which are the same (no PSNP >sent, just clear the SRMflag, receipt of the same LSP is equal to receipt of >a PSNP acknowledgement). Once an LSP has been received on a non-broadcast >link, a PSNP is sent as an acknowledgement to that LSP. > >Hope this helps? > >Cheers, >Ken Larmer > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 11:20:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25365 for ; Mon, 6 Aug 2001 11:20:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA76565; Mon, 6 Aug 2001 08:25:22 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA76535 for ; Mon, 6 Aug 2001 08:24:02 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 6 Aug 2001 15:16:47 -0000 X-Apparently-From: Message-ID: <135c01c11e8b$4f403560$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Swati Rastogi" , "isis-wg" References: <134a01c11e88$d917b680$da046c6b@Manav> Subject: Re: [Isis-wg] Doubt on L2 router Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 20:50:17 +0530 Content-Transfer-Encoding: 7bit If a single level 2 router looses connectivity to the level 2 backbone then this router will indicate in its L1 routing packets that it is not "attached", thereby allowing level 1 routers in the area to route traffic for outside of the area to a different L2 router. Level 1 routers therfore route traffic to destinations outside of their area only to L2 routers which indicate in their level 1 LSPs that they are "attached" Coming back to your question .. yes the networks get blackholed ! There is no provision for use of L1 routers to repair a level 2 partition ! Hope this helps Manav ----- Original Message ----- From: "Swati Rastogi" To: "isis-wg" Sent: Monday, August 06, 2001 8:32 PM Subject: [Isis-wg] Doubt on L2 router > Hi All, > In OSPF if the designated router fails then the backup designated router > takes over and all of this is done automatically. But in ISIS we have a > router configured as a L2 router drilled in the profiles. What would happen > if this router goes down for some reason ? Since this is the only link via > which the routers inside this area can communicate to the outside world. > Does it imply that the routers are now blackholed ! > > This would imply that the protocol has a single point of failure .. > > Regards, > Swati Rastogi > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 11:48:51 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26084 for ; Mon, 6 Aug 2001 11:48:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA76730; Mon, 6 Aug 2001 08:53:21 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA76718 for ; Mon, 6 Aug 2001 08:52:56 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f76FjU504310; Mon, 6 Aug 2001 11:45:30 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAD03316; Mon, 6 Aug 2001 11:45:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20010806113921.01ecee58@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: Jeff Learman Subject: Re: [Isis-wg] Doubt on L2 router Cc: "isis-wg" In-Reply-To: <134a01c11e88$d917b680$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 06 Aug 2001 11:45:21 -0400 At 11:02 AM 8/6/2001, Swati Rastogi wrote: >Hi All, >In OSPF if the designated router fails then the backup designated router >takes over and all of this is done automatically. But in ISIS we have a >router configured as a L2 router drilled in the profiles. What would happen >if this router goes down for some reason ? Since this is the only link via >which the routers inside this area can communicate to the outside world. >Does it imply that the routers are now blackholed ! Are you confusing "designated router" with "L2 router"? In IS-IS, they're separate -- there is one L1 designated router on a LAN, and the election is automatic. On a LAN with more than one L2 router, there is also one L2 DR, and it is elected in the same way. If your L1 area has only one router connecting it to other areas, then you have a single point of failure that has nothing to do with IS-IS. If your area has multiple connections to other areas, then you don't. (There is also a practical requirement that your L2 routers are connected within your area, either directly or by L2 routers, if your area is used for transit routes between other areas.) >This would imply that the protocol has a single point of failure .. > >Regards, >Swati Rastogi > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 14:24:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29051 for ; Mon, 6 Aug 2001 14:24:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA77417; Mon, 6 Aug 2001 11:31:21 -0700 (PDT) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by external.juniper.net (8.9.3/8.9.3) with SMTP id LAA77405 for ; Mon, 6 Aug 2001 11:30:45 -0700 (PDT) Received: (qmail 30639 invoked from network); 6 Aug 2001 17:56:40 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Aug 2001 17:56:40 -0000 From: "Ken Larmer" To: "Jeff Learman" , "Swati Rastogi" Cc: "isis-wg" Subject: RE: [Isis-wg] Doubt on L2 router Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20010806113921.01ecee58@dingdong.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 6 Aug 2001 13:58:26 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > Sent: Monday, August 06, 2001 11:45 AM > To: Swati Rastogi > Cc: isis-wg > Subject: Re: [Isis-wg] Doubt on L2 router > > > At 11:02 AM 8/6/2001, Swati Rastogi wrote: > >Hi All, > >In OSPF if the designated router fails then the backup designated router > >takes over and all of this is done automatically. But in ISIS we have a > >router configured as a L2 router drilled in the profiles. What > would happen > >if this router goes down for some reason ? Since this is the > only link via > >which the routers inside this area can communicate to the outside world. > >Does it imply that the routers are now blackholed ! > > Are you confusing "designated router" with "L2 router"? > In IS-IS, they're separate -- there is one L1 designated router > on a LAN, and the election is automatic. On a LAN with > more than one L2 router, there is also one L2 DR, and > it is elected in the same way. > > If your L1 area has only one router connecting it to other > areas, then you have a single point of failure that has > nothing to do with IS-IS. If your area has multiple > connections to other areas, then you don't. (There is > also a practical requirement that your L2 routers are > connected within your area, either directly or by L2 > routers, if your area is used for transit routes between > other areas.) Of course, as with most things in life, there are exceptions. If you have an IS, which has multiple L1 IS instances configured, in order to get between L1 instances, some vendors set the Attached bit in the L1 LSP (LSP Number = 0) which they generate. While this allows for connectivity between L1 areas (each L1 IS instance is a separate L1 area "Sub-Domain"), it does not take into account some of the basic rules Jeff mentioned for setting the attached bit. That is, the attached bit will be set, regardless of whether or not your L2 Instance is connected to another L2 area. As a consequence, you may be able to get between L1 instances, but you may not be able to get outside of the physical router you are connected to if the L2 backbone is not contiguous. Or, you may take a less than desirable path to your destination because the "nearest L2 router" may contain a less desirable route. This is why it may make more sense in some situations to advertise an IP default route instead of relying on the "Attached Bit". Cheers, Ken Larmer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 21:44:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06695 for ; Mon, 6 Aug 2001 21:44:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA79158; Mon, 6 Aug 2001 18:50:21 -0700 (PDT) Received: from mail.nexsi.com ([66.35.212.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA79143 for ; Mon, 6 Aug 2001 18:49:10 -0700 (PDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA16165; Mon, 6 Aug 2001 18:43:21 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <64955986.20010807024129@nexsi.com> To: Jeff Learman CC: "Manav Bhatia" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] ISIS and OSPF In-Reply-To: <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 7 Aug 2001 02:41:29 +0100 Content-Transfer-Encoding: 7bit Manav, Regarding IPv6 support in OSPF, we have RFC2740 (so-called OSPFv3) for this purpose. There, each router needs to be assigned a unique 32-bit RID, but this does not mean that each router needs a unique IPv4 address. RID is just an unsigned integer with no addressing semantic. Regarding the scalability comparison, you'll have to ask the vendor you're using, as it depends on the actual implementations rather than the properties of the protocols. -- Alex Zinin Monday, August 06, 2001, 3:08:03 PM, Jeff Learman wrote: > At 09:21 AM 8/6/2001, Manav Bhatia wrote: >>Thanks Jeff for the reply ! >>> of new TLV-encoded options. I would guess that this is equally true for >>> OSPF, although it may be necessary to continue to give each OSPF router >>> an IPV4 address with certain uniqueness requirements. >>But the very reason why IPv6 is coming into picture is the paucity of IPv4 >>addresses. So if OSPF has to support unique IPv4 addresses then how can it >>work in an IPv6 environment ? > First, I'm making a guess about OSPF. Let's wait and see what someone > with more OSPF knowledge says. Second, there will be many more end > systems than routers, so if only routers have IPV4 addresses, then > there may be an order of magnitude or two of growth before the problem > becomes critical again. Also, I said that there were uniqueness > requirements, but I don't know precisely what these uniqueness > requirements are. It is likely that routers belonging to one > AS can use local IP addresses that are unique only within that AS. >>Secondly, in the present scenario (IPv4) which is considreded as a better >>IGP .. in terms of scalability ? > Can't help you there! Studies that I have done with IS-IS indicate > that it is surprisingly scalable in terms of bandwidth usage, even > with relatively unreliable routers with short MTBFs (like days!). > The practical limit of IS-IS is probably related to its two-level > hierarchy rather than N-level hierarchy. Radia Perlman has ideas > on how it could be extended to support that, but so far there is > little interest. Evidently the scalability limits of IS-IS have not > been reached, or else those who run IS-IS and have scalability > issues are not making themselves heard on this forum. > The biggest problem with scalability will probably be how long it > takes to stabilize after a topology change. The greater the span > of the sub-domain (area or routing domain), the greater the time. > Multi-level IS-IS could be used to improve this, in hierarchical > topologies that could take advantage of it. > Regards, > Jeff >>Regards, >>Manav >> >> >> >>_________________________________________________________ >>Do You Yahoo!? >>Get your free @yahoo.com address at http://mail.yahoo.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 6 22:26:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07139 for ; Mon, 6 Aug 2001 22:26:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA79353; Mon, 6 Aug 2001 19:32:21 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by external.juniper.net (8.9.3/8.9.3) with SMTP id TAA79341 for ; Mon, 6 Aug 2001 19:31:39 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 02:24:20 -0000 X-Apparently-From: Message-ID: <139801c11ee8$907c8490$da046c6b@Manav> From: "Swati Rastogi" To: "Alex Zinin" Cc: References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> <64955986.20010807024129@nexsi.com> Subject: Re: [Isis-wg] ISIS and OSPF MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 7 Aug 2001 07:57:37 +0530 Content-Transfer-Encoding: 7bit Hi Alex, Would this imply that OSPF is "as much ready" as ISIS for IPv6. If the IGP being used is OSPF then we will have to run two copies on the dual IP stack transition router ..but as i understood with ISIS we can work with a single copy of IGP running on the box. If we run two instances of OSPF then we face the problems of resource struggle, processor overheads, etc. What I always thought was that ISIS might prove handy in such a situation. Regards, Swati Rastogi ----- Original Message ----- From: "Alex Zinin" To: "Jeff Learman" Cc: "Manav Bhatia" ; Sent: Tuesday, August 07, 2001 7:11 AM Subject: Re: [Isis-wg] ISIS and OSPF > Manav, > > Regarding IPv6 support in OSPF, we have RFC2740 (so-called OSPFv3) > for this purpose. There, each router needs to be assigned a unique > 32-bit RID, but this does not mean that each router needs a unique > IPv4 address. RID is just an unsigned integer with no addressing > semantic. > > Regarding the scalability comparison, you'll have to ask the vendor > you're using, as it depends on the actual implementations rather than > the properties of the protocols. > > -- > Alex Zinin > > Monday, August 06, 2001, 3:08:03 PM, Jeff Learman wrote: > > > At 09:21 AM 8/6/2001, Manav Bhatia wrote: > >>Thanks Jeff for the reply ! > >>> of new TLV-encoded options. I would guess that this is equally true for > >>> OSPF, although it may be necessary to continue to give each OSPF router > >>> an IPV4 address with certain uniqueness requirements. > >>But the very reason why IPv6 is coming into picture is the paucity of IPv4 > >>addresses. So if OSPF has to support unique IPv4 addresses then how can it > >>work in an IPv6 environment ? > > > First, I'm making a guess about OSPF. Let's wait and see what someone > > with more OSPF knowledge says. Second, there will be many more end > > systems than routers, so if only routers have IPV4 addresses, then > > there may be an order of magnitude or two of growth before the problem > > becomes critical again. Also, I said that there were uniqueness > > requirements, but I don't know precisely what these uniqueness > > requirements are. It is likely that routers belonging to one > > AS can use local IP addresses that are unique only within that AS. > > >>Secondly, in the present scenario (IPv4) which is considreded as a better > >>IGP .. in terms of scalability ? > > > Can't help you there! Studies that I have done with IS-IS indicate > > that it is surprisingly scalable in terms of bandwidth usage, even > > with relatively unreliable routers with short MTBFs (like days!). > > The practical limit of IS-IS is probably related to its two-level > > hierarchy rather than N-level hierarchy. Radia Perlman has ideas > > on how it could be extended to support that, but so far there is > > little interest. Evidently the scalability limits of IS-IS have not > > been reached, or else those who run IS-IS and have scalability > > issues are not making themselves heard on this forum. > > > The biggest problem with scalability will probably be how long it > > takes to stabilize after a topology change. The greater the span > > of the sub-domain (area or routing domain), the greater the time. > > Multi-level IS-IS could be used to improve this, in hierarchical > > topologies that could take advantage of it. > > > Regards, > > Jeff > > > > >>Regards, > >>Manav > >> > >> > >> > >>_________________________________________________________ > >>Do You Yahoo!? > >>Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 7 06:28:55 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29523 for ; Tue, 7 Aug 2001 06:28:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA81408; Tue, 7 Aug 2001 03:34:21 -0700 (PDT) Received: from mail.nexsi.com ([66.35.212.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA81388 for ; Tue, 7 Aug 2001 03:33:26 -0700 (PDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id DAA18499; Tue, 7 Aug 2001 03:27:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1361300630.20010807112546@nexsi.com> To: "Swati Rastogi" CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] ISIS and OSPF In-Reply-To: <139801c11ee8$907c8490$da046c6b@Manav> References: <0d8a01c11e2f$9e855940$da046c6b@Manav> <007401c11e78$b9c9bf40$8c02530a@sevsisters> <4.3.2.7.2.20010806095024.01eae720@dingdong.cisco.com> <64955986.20010807024129@nexsi.com> <139801c11ee8$907c8490$da046c6b@Manav> 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 7 Aug 2001 11:25:46 +0100 Content-Transfer-Encoding: 7bit Swati, > Hi Alex, > Would this imply that OSPF is "as much ready" as ISIS for IPv6. Shoot higher, OSPFv3 is already deployed. > If the IGP > being used is OSPF then we will have to run two copies on the dual IP stack > transition router .. Yes, if you need the same box to route both IPv4 and IPv6, you'll have to have OSPFv2 and OSPFv3 running on it. > but as i understood with ISIS we can work with a single > copy of IGP running on the box. Correct. > If we run two instances of OSPF then we face the problems of resource > struggle, processor overheads, etc. For some reason, this does not scare me much. Routers already run multiple instances of an IGP. Also, think about an IGP running together with BGP. This does not mean, however, that I do not see the difference between one process vs 2 processes. > What I always thought was that ISIS might prove handy in such a situation. The fact that ISIS uses L2 as the transport has its pros and its cons. One of its beauties is that the basic mechanisms (interface, neighbor LSDB maintenance, etc.) are completely independent from the L3 semantics. Same beauty can byte you sometimes though, but there ain't no such thing as a free lunch. :) Alex. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 7 17:46:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12959 for ; Tue, 7 Aug 2001 17:46:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA84189; Tue, 7 Aug 2001 14:52:21 -0700 (PDT) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA84177 for ; Tue, 7 Aug 2001 14:51:40 -0700 (PDT) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 17:44:16 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> From: "Martin, Christian" 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] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 7 Aug 2001 17:44:08 -0400 Folks, I have some comments on the draft that I'd like to address with the WG. I apologize for cutting this so close to the meeting, but this is the first chance I've had to address it. A while back I began considering how IS-IS could be made to support PTP behavior over BMA networks. The driving force behind this was primarily the ability to assign arbitrary, per-neighbor metric information to individual neighbors. A second benefit would be the elimination of pseudonode exposion when a large amount of PTP LAN links were used to interconnect routers. I sent an email detailing the need to the WG, but there was little response. Some notable vendors also displayed little interest. The only suggestion I received, in fact, was to use PPPoE! After reviewing the draft, I have some concern about the utility of the proposal, and whether or not it satisfies a real need. While it does have merit and will help in many situations, the scope should be expanded to address some more complex situations. Comments of course are welcome. In regards to OSPF: OSPF currently supports NBMA networks. What we are attempting to do here is create PtMP (of where MP can be P if there are only two nodes on a LAN) networks out of BMA networks in order to support PTP type behavior, from a Djiktsra perspective, correct? This is in OSPF today. You can build NBNA networks on LANs and specify neighbors explicitly, with associated metrics. The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion based on the configured neighbor IP. As I see it, the only benefit the draft provides is the elimination of DR election (and the corresponding elimination of pseudonodes on PTP links), which can be done by making the interface point-to-multipoint (although requiring configuration). The major vendors support this feature today (I use it!). In regards to IS-IS: This was the tricky part, as there was nothing in 10589 or 1195 (or any subsequent draft) that proposes how to do this. Furthermore, the interaction between CLNS and IP makes the address resolution issue a bit trickier. Anyway, here is what I was thinking of. 1) Create support for point-to-multipoint in IS-IS. This has some additional benefit outside of the scope of LANs, as it allows the protocol to be used on real NBMA networks like Frame Relay and ATM. The way to do this is either cumbersome for the vendor or cumbersome for the operator. It also may break the current separation between subnetwork-dependent and independent functions, which may not sit well with ISO (or some IETF members). Let's address 802.3 networks first. As I see it, ISIS Hellos should be sent as PTP hellos. This means sending them to a MAC address and an interface. The interface is then made point-to-multipoint. For each configured adjacency, assign a circuit ID based on the current mechanism in 10589. The PTP hellos must be encapsulated in 802.3 frames, of course, but they should be unicast. CSNP should not be sent every 10 seconds, but rather in response to SRM flag changes, etc. Every router knows how to forward traffic across a LAN without passing it through the DIS, based on SNPA information from adjacencies. Forwarding would be still based on SNPA information, which is easily extracted from the configured MAC address of the neighbor (hence, the adjacency). An additional feature could be to address the neighbors based on NSAP, and then use ES-IS or some other address resolution mechanism to determine the MAC address. Either way, forwarding is an issue local to the router, and should not be much of an issue. This is where the 'cumbersome-ness' shifts. As far as switched WANs, the same principles could be applied. However, there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs, etc) that isn't addressed outside of X.25 in ISO (AFAIK). This may be too much of an undertaking, although it may be worth consideration if there is sufficient interest. Some possiblilities would be to use static mapping of NSAPs to l2cid, which is common today, and then specifiy the neighbor, the interface, and the metric. Finally, this information could be extended to support draft-ietf-isis-traffic-03.txt, by including link coloring, reserved bandwidth, etc, although the RSVP piece becomes trickier in the way it is encoded on LANs and in the way one reserves bandwidth across virtual adjacencies in a shared media environment. Either way, they are workable issues, and should be addressed given the growing ubiquity of TE-extension support. In summary: 1) Keep the changes at the subnetwork-dependent layer as much as possible, i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP links). This makes the modifications easier, development-wise. 2) Allow for both directly connected routers using LAN media as well as directed adjacencies across BMA networks for metric adjustment. 3) If the specification is about removing DR election (which as it stands now, it is), state this explicitly. I still think this does not address all the issues, particlularly, the use of switches as media termination and router hubbing devices. 4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some kind of address resolution mechanism to direct PTP hellos to the appropriate MAC address. 5) Allow per neighbor metric adjustment, and possibly pseudolink coloring and reservable/reserved BW info. 6) Optionally consider mechanisms to build NBMA support into IS-IS for switched WAN media. PtMP mode would be best, although it requires additional flooding, etc. NBMA mode, as in OSPF, is nice but may be difficult to do in most cases (except for SMDS) ~8^> 7) If it is desired to just turn a LAN link into a PTP link, then this is fine. However, if what I propose is acceptable, then the error checking portion of the draft needs to be modified to check for PtMP behavior first. Finally, I would think that OSPF implementation modifications should be submitted separately to the OSPF-WG, and not to the IS-IS WG. As stated earlier, a good deal of the desired functionality specified in the draft is already specified in RFC 2328 and later versions, so it may be unnecessary. Sorry this is so late - you may treat these comments as my contribution to the London meeting, in absentia of course. ;) Best Regards, -chris _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 7 19:38:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14359 for ; Tue, 7 Aug 2001 19:38:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA84697; Tue, 7 Aug 2001 16:44:22 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id QAA84685 for ; Tue, 7 Aug 2001 16:43:43 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Aug 2001 23:36:18 -0000 X-Apparently-From: Message-ID: <000801c11f9a$4c189a70$da046c6b@Manav> From: "Swati Rastogi" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] OSI ?? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 7 Aug 2001 20:36:26 +0530 Content-Transfer-Encoding: 7bit Hi All, This is slightly off-track but any help in this regard will be really very much appreciated. Here goes my long list of doubts (1) Is CLNP (OSI) analogous to IP (TCP/IP) .. If so then why have i never come across a CLNP packet format (analogy .. we have IP packet formats) (2) Routing is making sure that a packet reaches the destination safe 'n sound .. while a routing protocol ensures that the out of the available paths choosing the best one. So if ISIS runs along IP then who is taking care of the "routing" aspect i.e taking the packet from the source to the destination. ISIS is a routing protocol and its job shud be to just choose the optimal path .. once its done that it can then hand over the packet to CLNP for forwarding .. So where did i loose the track ?? (3) In my transport layer i could be running tp0, tp1, tp2 etc. How does the routing module know which transport layer to forward the packet to. There is only 1 byte field "SEL" aka selector in the NSAP addressing .. is this used to determine this ?? To summarize .. how when a module recvs a packet from the data link layer determines whether to use CONP or CLNP in the networking layer and then later which transport layer protocol is to be used in the transport layer! Which transport layer protocol does ISIS use ?? Please Help .. i am very confused with all the OSI terminology ! Thanks and Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 00:35:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19342 for ; Wed, 8 Aug 2001 00:35:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA85896; Tue, 7 Aug 2001 21:41:22 -0700 (PDT) Received: from mail.nexsi.com ([66.35.212.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA85884 for ; Tue, 7 Aug 2001 21:40:01 -0700 (PDT) Received: from khonsu.sw.nexsi.com (dynvpn0.nexsi.com [172.16.211.0]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id VAA28585; Tue, 7 Aug 2001 21:34:04 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <15966485551.20010808053211@nexsi.com> To: "Martin, Christian" CC: "IS-IS WG (E-mail)" Subject: Re: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt In-Reply-To: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> References: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 05:32:11 +0100 Content-Transfer-Encoding: 7bit Christian, A comment regarding OSPF---essentially, we're not changing anything in OSPF, we're only saying an implementation should be able to treat LAN link as a p2p network type. Your suggestion to implement p2mp in ISIS might make sense in a generic context, however, it would introduce unnecessary complexity to the p2p lan case, which is addressed simply by (again) treating the link as p2p (and hence automagically sending p2p iih's, using psnps, etc.) and agreeing on the MAC address. I think if there's enough interest in p2mp in ISIS, it should be addressed separately. Wrt the merits of the draft, it's not only eliminating DR/DIS election, it is also reducing the number of LSAs/LSPs in the domain, some flooding benefits, using ip unnumbered, etc. If you see any problems that are not addressed within the context of the draft, please elaborate. Regarding a separate OSPF doc, I don't see the critical mass of changes in OSPF (in fact, there are none) to justify splitting of a complete document. Thanks, -- Alex Zinin Tuesday, August 07, 2001, 10:44:08 PM, Martin, Christian wrote: > Folks, > I have some comments on the draft that I'd like to address with the WG. I > apologize for cutting this so close to the meeting, but this is the first > chance I've had to address it. > A while back I began considering how IS-IS could be made to support PTP > behavior over BMA networks. The driving force behind this was primarily the > ability to assign arbitrary, per-neighbor metric information to individual > neighbors. A second benefit would be the elimination of pseudonode exposion > when a large amount of PTP LAN links were used to interconnect routers. I > sent an email detailing the need to the WG, but there was little response. > Some notable vendors also displayed little interest. The only suggestion I > received, in fact, was to use PPPoE! After reviewing the draft, I have some > concern about the utility of the proposal, and whether or not it satisfies a > real need. While it does have merit and will help in many situations, the > scope should be expanded to address some more complex situations. Comments > of course are welcome. > In regards to OSPF: > OSPF currently supports NBMA networks. What we are attempting to do here is > create PtMP (of where MP can be P if there are only two nodes on a LAN) > networks out of BMA networks in order to support PTP type behavior, from a > Djiktsra perspective, correct? This is in OSPF today. You can build NBNA > networks on LANs and specify neighbors explicitly, with associated metrics. > The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion > based on the configured neighbor IP. As I see it, the only benefit the > draft provides is the elimination of DR election (and the corresponding > elimination of pseudonodes on PTP links), which can be done by making the > interface point-to-multipoint (although requiring configuration). The major > vendors support this feature today (I use it!). > In regards to IS-IS: > This was the tricky part, as there was nothing in 10589 or 1195 (or any > subsequent draft) that proposes how to do this. Furthermore, the > interaction between CLNS and IP makes the address resolution issue a bit > trickier. Anyway, here is what I was thinking of. > 1) Create support for point-to-multipoint in IS-IS. This has some > additional benefit outside of the scope of LANs, as it allows the protocol > to be used on real NBMA networks like Frame Relay and ATM. The way to do > this is either cumbersome for the vendor or cumbersome for the operator. It > also may break the current separation between subnetwork-dependent and > independent functions, which may not sit well with ISO (or some IETF > members). Let's address 802.3 networks first. > As I see it, ISIS Hellos should be sent as PTP hellos. This means sending > them to a MAC address and an interface. The interface is then made > point-to-multipoint. For each configured adjacency, assign a circuit ID > based on the current mechanism in 10589. The PTP hellos must be > encapsulated in 802.3 frames, of course, but they should be unicast. CSNP > should not be sent every 10 seconds, but rather in response to SRM flag > changes, etc. > Every router knows how to forward traffic across a LAN without passing it > through the DIS, based on SNPA information from adjacencies. Forwarding > would be still based on SNPA information, which is easily extracted from the > configured MAC address of the neighbor (hence, the adjacency). An > additional feature could be to address the neighbors based on NSAP, and then > use ES-IS or some other address resolution mechanism to determine the MAC > address. Either way, forwarding is an issue local to the router, and should > not be much of an issue. This is where the 'cumbersome-ness' shifts. > As far as switched WANs, the same principles could be applied. However, > there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs, > etc) that isn't addressed outside of X.25 in ISO (AFAIK). This may be too > much of an undertaking, although it may be worth consideration if there is > sufficient interest. Some possiblilities would be to use static mapping of > NSAPs to l2cid, which is common today, and then specifiy the neighbor, the > interface, and the metric. > Finally, this information could be extended to support > draft-ietf-isis-traffic-03.txt, by including link coloring, reserved > bandwidth, etc, although the RSVP piece becomes trickier in the way it is > encoded on LANs and in the way one reserves bandwidth across virtual > adjacencies in a shared media environment. Either way, they are workable > issues, and should be addressed given the growing ubiquity of TE-extension > support. > In summary: > 1) Keep the changes at the subnetwork-dependent layer as much as possible, > i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP > links). This makes the modifications easier, development-wise. > 2) Allow for both directly connected routers using LAN media as well as > directed adjacencies across BMA networks for metric adjustment. > 3) If the specification is about removing DR election (which as it stands > now, it is), state this explicitly. I still think this does not address all > the issues, particlularly, the use of switches as media termination and > router hubbing devices. > 4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some > kind of address resolution mechanism to direct PTP hellos to the appropriate > MAC address. > 5) Allow per neighbor metric adjustment, and possibly pseudolink coloring > and reservable/reserved BW info. > 6) Optionally consider mechanisms to build NBMA support into IS-IS for > switched WAN media. PtMP mode would be best, although it requires > additional flooding, etc. NBMA mode, as in OSPF, is nice but may be > difficult to do in most cases (except for SMDS) ~8^> > 7) If it is desired to just turn a LAN link into a PTP link, then this is > fine. However, if what I propose is acceptable, then the error checking > portion of the draft needs to be modified to check for PtMP behavior first. > Finally, I would think that OSPF implementation modifications should be > submitted separately to the OSPF-WG, and not to the IS-IS WG. As stated > earlier, a good deal of the desired functionality specified in the draft is > already specified in RFC 2328 and later versions, so it may be unnecessary. > Sorry this is so late - you may treat these comments as my contribution to > the London meeting, in absentia of course. ;) > Best Regards, > -chris > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 01:55:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27596 for ; Wed, 8 Aug 2001 01:55:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA86272; Tue, 7 Aug 2001 23:01:22 -0700 (PDT) Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA86260 for ; Tue, 7 Aug 2001 23:00:33 -0700 (PDT) Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 01:53:07 -0400 Message-ID: <94B9091E1149D411A45C00508BACEB359CDCF2@entmail.gnilink.com> From: "Martin, Christian" To: "'isis-wg@external.juniper.net'" Subject: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 01:53:07 -0400 Alex, Thanks for the response. Comments inline... > Christian, > > A comment regarding OSPF---essentially, we're not changing > anything in OSPF, we're only saying an implementation should > be able to treat LAN link as a p2p network type. Understood. > > Your suggestion to implement p2mp in ISIS might make sense in a > generic context, however, it would introduce unnecessary > complexity to the p2p lan case, which is addressed simply > by (again) treating the link as p2p (and hence automagically > sending p2p iih's, using psnps, etc.) and agreeing on > the MAC address. This is one of the benefits I see. I was hoping it could be extended to the more general case. It is not uncommon for routers to be connected via switches to other routers in an attempt to minimize port costs and maximize bandwidth. If you connect 10 routers to a switch (in the same VLAN of course), all costs (to the pseudonode) are the same. Directed adjacencies (while more complex, configuration-wise) are a cost effective way of adjusting metrics without using dedicated, PTP links )or VLANs). > I think if there's enough interest in p2mp in ISIS, it should > be addressed separately. Perhaps this should be the case. I can generate a draft and submit it separately. Care to collaborate? > Wrt the merits of the draft, it's not only eliminating > DR/DIS election, it is also reducing the number of LSAs/LSPs in > the domain, some flooding benefits, using ip unnumbered, etc. Many network operators feel that IP unnumbered presents several operational drawbacks, particularly when troubleshooting link problems. I for one am not opposed to it, but I could not convince my Ops staff that there was enough merit in reducing IP usage to justify the reduction in operational utility of addressed links (for pinging, traceroute, ER-LSPs, etc). Nevertheless, others may have this requirement, so I am not diametrically opposed to it. Either way, you mention this, so I am ok with it. > If you see any problems that are not addressed within the > context of the draft, please elaborate. I don't disagree with anything in the draft - I just think that it is fairly specific in scope. By expanding the scope to a more generic case, a specification and subsequent implementations would not need additional rewrites to cover other requirements. For what it's worth, the draft does do some nice things ( things that caused me to scrap GigE for POP interconnect in favor of POS - at a higher cost per Mb ). I was just thinking that some additional work would yield an IS-IS implementation that covered the generic case. > Regarding a separate OSPF doc, I don't see the critical mass > of changes in OSPF (in fact, there are none) to justify splitting > of a complete document. I do not write code for a vendor, so I cannot in fairness speak to this directly. But I would think that the OSPF-WG would be interested in this work, as it does require an implementation to treat a LAN as PTP - which may not be trivial. Just a thought. > > Thanks, > Thanks, as well. -chris _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 04:27:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08055 for ; Wed, 8 Aug 2001 04:27:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA86899; Wed, 8 Aug 2001 01:33:22 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by external.juniper.net (8.9.3/8.9.3) with SMTP id BAA86887 for ; Wed, 8 Aug 2001 01:32:49 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Aug 2001 08:25:21 -0000 X-Apparently-From: Message-ID: <011301c11fe4$34096500$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Swati Rastogi" , References: <000801c11f9a$4c189a70$da046c6b@Manav> Subject: Re: [Isis-wg] OSI ?? Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 13:59:05 +0530 Content-Transfer-Encoding: 7bit > > (1) Is CLNP (OSI) analogous to IP (TCP/IP) .. If so then why have i never > come across a CLNP packet format (analogy .. we have IP packet formats) Refer to ISO/IEC 8473, Section 7 > (2) Routing is making sure that a packet reaches the destination safe 'n > sound .. while a routing protocol ensures that the out of the available > paths choosing the best one. So if ISIS runs along IP then who is taking > care of the "routing" aspect i.e taking the packet from the source to the > destination. ISIS is a routing protocol and its job shud be to just choose > the optimal path .. once its done that it can then hand over the packet to > CLNP for forwarding .. So where did i loose the track ?? ISIS protocol is designed to work in close conjunction with ISO 8473 and ISO 9542. The latter is used to establish connectivity and reachability between end systems and Intermediate systems. Data is carried by ISO 8473. It provides connectionless mode network service. > (3) In my transport layer i could be running tp0, tp1, tp2 etc. How does the > routing module know which transport layer to forward the packet to. There is > only 1 byte field "SEL" aka selector in the NSAP addressing .. is this used > to determine this ?? For ISIS you dont access the upper transport layer .. and hence you dont need to know that .. I hope i am right .. SEL byte is always zero for Intermediate systems > To summarize .. how when a module recvs a packet from the data link layer > determines whether to use CONP or CLNP in the networking layer and then > later which transport layer protocol is to be used in the transport layer! The OSI pdu has a "network layer protocol identifier" parameter in its fixed part .. which probably tells about whether its CLNP or CONP. > > Which transport layer protocol does ISIS use ?? It wont be running on top of any transport layer. > > Please Help .. i am very confused with all the OSI terminology ! Regards, Manav Bhatia > > Thanks and Regards, > Swati > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 04:52:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08338 for ; Wed, 8 Aug 2001 04:51:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA87048; Wed, 8 Aug 2001 01:58:22 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id BAA87036 for ; Wed, 8 Aug 2001 01:57:00 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Aug 2001 08:49:33 -0000 X-Apparently-From: Message-ID: <018801c11fe7$95230050$da046c6b@Manav> From: "Swati Rastogi" To: "Manav Bhatia" , References: <000801c11f9a$4c189a70$da046c6b@Manav> <011301c11fe4$34096500$da046c6b@Manav> Subject: Re: [Isis-wg] OSI ?? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 14:23:17 +0530 Content-Transfer-Encoding: 7bit > > (2) Routing is making sure that a packet reaches the destination safe 'n > > sound .. while a routing protocol ensures that the out of the available > > paths choosing the best one. So if ISIS runs along IP then who is taking > > care of the "routing" aspect i.e taking the packet from the source to the > > destination. ISIS is a routing protocol and its job shud be to just choose > > the optimal path .. once its done that it can then hand over the packet to > > CLNP for forwarding .. So where did i loose the track ?? > > ISIS protocol is designed to work in close conjunction with ISO 8473 and ISO > 9542. The latter is used to establish connectivity and reachability between > end systems and Intermediate systems. Data is carried by ISO 8473. It > provides connectionless mode network service. > Does it imply that all ISIS PDUs like L1 lan/p2p IIS Hello, L1/2 LSPs, L1/2 CSNPs, L1/2 PSNPs form the data part in the ISO 8473 data PDU ? Quoting Jeff . . " Be careful when you read "encapsulated in CLNS packets". It is absolutely correct, but does NOT mean that they are encapsulated in CLNP packets. It does mean that they are OSI connectionless layer three packets and therefore begin with a Network Layer Protocol ID (variously called NPID, NLPI, or NLPID). After that first octet, IS-IS and CLNP headers have little in common." He says that ISIS packets are not encapsulated in CLNP packets .. Moreover he also mentions that ISIS and CLNP headers have a little in common except for NLPID ? Does it imply that there will be different values in NLPID for CLNP,CONP and ISIS packets ?? Pl. clarify Thanks and Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 10:25:03 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13384 for ; Wed, 8 Aug 2001 10:25:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA88596; Wed, 8 Aug 2001 07:31:22 -0700 (PDT) Received: from hotmail.com (f90.law3.hotmail.com [209.185.241.90]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA88584 for ; Wed, 8 Aug 2001 07:30:43 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Aug 2001 07:23:14 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 08 Aug 2001 14:23:14 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2001 14:23:14.0890 (UTC) FILETIME=[A93E02A0:01C12015] Subject: [Isis-wg] Doubts on Traffic Engineering Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 14:23:14 +0000 Hello, I have some doubts related to the traffic engineering related draft associated with IS - IS. According to the Draft draft-ietf-isis-traffic-03.txt, certain TLVs are modified to add Information on traffic Engineering. These are: 1. IS Reachability TLV 2. IP Reachability TLV My questions: Queries Regarding the Extended IS Reachability TLV ------------------------------------------------------------- 1. Sub TLV: 3 Description: Administrative Group Query: a. Who assigns the Adminstrative Group for the Router. Is it a configurable parameter ? b. Is this sub-TLV a must or optional ? ------------------------------------------------------------- 2. Sub TLV: 9, 10 & 11 Query: a. How do we come to know about the Maximum Link bandwidth of the Link ? b. Are there any Functional Computation for this purpose ? c. Or can this be included as a configurable Parameter? d. Is this sub-TLV a must or optional ? -------------------------------------------------------------- 3. Sub TLV: 18 Description: Traffic Engineering Default metric Query: a. Is this a configurable Parameter ? b. Is this sub-TLV optional or must ? ------------------------------------------------------------ Queries Regarding Extended IP Reachability TLV Are there any sub-TLVs defined for this TLV after the publishing of the draft ? ------------------------------------------------------------ I was also wondering if the implementation compliant with this draft is to transmit all the TLVs (IP internal reachibility, IP external reachibility and IP extended reachibility) or should it transmit either 2 or 1 of these depending on circumstances. Can you please suggest any standard/draft that answers all my questions if at all there is any. I shall be obliged to receive early response. Thanking you in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 10:57:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14206 for ; Wed, 8 Aug 2001 10:57:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88749; Wed, 8 Aug 2001 08:03:22 -0700 (PDT) Received: from hotmail.com (f37.law3.hotmail.com [209.185.241.37]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88737 for ; Wed, 8 Aug 2001 08:02:58 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Aug 2001 07:55:30 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 08 Aug 2001 14:55:30 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2001 14:55:30.0673 (UTC) FILETIME=[2B0F0E10:01C1201A] Subject: [Isis-wg] Adjacency type Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 14:55:30 +0000 Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. My question is: Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacenc? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 10:59:58 2001 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 ; Wed, 8 Aug 2001 10:59:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88782; Wed, 8 Aug 2001 08:06:22 -0700 (PDT) Received: from hotmail.com (f48.law3.hotmail.com [209.185.241.48]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88770 for ; Wed, 8 Aug 2001 08:05:08 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Aug 2001 07:57:40 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 08 Aug 2001 14:57:40 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2001 14:57:40.0433 (UTC) FILETIME=[7866DC10:01C1201A] Subject: [Isis-wg] Doubts on adjacency type Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 14:57:40 +0000 Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. My question is: If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacenc? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 11:10:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14597 for ; Wed, 8 Aug 2001 11:10:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88863; Wed, 8 Aug 2001 08:17:22 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA88851 for ; Wed, 8 Aug 2001 08:16:03 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id LAA24554; Wed, 8 Aug 2001 11:08:30 -0400 Message-ID: <3B7155EE.36CBCB40@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sachidananda K CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Doubts on adjacency type 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 11:08:30 -0400 Content-Transfer-Encoding: 7bit Sachidananda K wrote: > Hello, > > I have some doubts related to the adjacency type. According to my > understanding there are 3 different types of adjacencies: ES adjacency; L1 > adjacency; and L2 adjacency. > > Let me take a setup consisting of 3 IS: A, B and C. > where:- > IS B is a L1/L2 IS. > IS A is L1 only IS. > IS c is L2 only IS. > If c is adjacent to B, then the adjacency type between B and C should be L2 > adjacency. > > My question is: > If A is adjacent to B, then should the adjacency type be L2 adjacency or > should it be L1 adjacenc? > It will be an L1 adjacency ( of course in case there is at least one area address in common ) -- Tayfun Gol > > I shall be obliged to get my doubt clarified. > Thanking you in advance for all the responses received. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 11:22:55 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14913 for ; Wed, 8 Aug 2001 11:22:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88941; Wed, 8 Aug 2001 08:29:22 -0700 (PDT) Received: from hotmail.com (f77.law3.hotmail.com [209.185.241.77]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88924 for ; Wed, 8 Aug 2001 08:28:20 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 8 Aug 2001 08:20:51 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 08 Aug 2001 15:20:51 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Aug 2001 15:20:51.0744 (UTC) FILETIME=[B5B01200:01C1201D] Subject: [Isis-wg] Doubts on adjacency type Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 15:20:51 +0000 Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. My question is: If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacency? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 11:24:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14954 for ; Wed, 8 Aug 2001 11:24:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88966; Wed, 8 Aug 2001 08:31:17 -0700 (PDT) Received: from mta1-svc.virgin.net (mta1-svc.virgin.net [62.253.164.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA88929 for ; Wed, 8 Aug 2001 08:28:33 -0700 (PDT) Received: from iparchitect2 ([212.250.194.63]) by mta1-svc.virgin.net (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20010808152103.TLIC5645.mta1-svc.virgin.net@iparchitect2>; Wed, 8 Aug 2001 16:21:03 +0100 From: "Dave Humphrey" To: "Sachidananda K" , Subject: RE: [Isis-wg] Adjacency type Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 16:21:01 +0100 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Following your example. C will make a L2 adjancency with B. A will make an L1 adjacency with B. A cannot make L2 adjacencies it is not configured to do so. Basically a box with an interface configured to work at both levels will make adjacencies with other box's at the levels at which they are configured. On a LAN a box will generate L1 and L2 hellos separately to find adjacencies. On a p2p circuit there is only one hello type and the circuit type field is used to determine whether the advertiser can make an L1, L2 or both adjacency. Dave Humphrey - -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Sachidananda K Sent: 08 August 2001 15:56 To: isis-wg@spider.juniper.net Subject: [Isis-wg] Adjacency type Hello, I have some doubts related to the adjacency type. According to my understanding there are 3 different types of adjacencies: ES adjacency; L1 adjacency; and L2 adjacency. My question is: Let me take a setup consisting of 3 IS: A, B and C. where:- IS B is a L1/L2 IS. IS A is L1 only IS. IS c is L2 only IS. If c is adjacent to B, then the adjacency type between B and C should be L2 adjacency. If A is adjacent to B, then should the adjacency type be L2 adjacency or should it be L1 adjacenc? I shall be obliged to get my doubt clarified. Thanking you in advance for all the responses received. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBO3FXZdDzf3p4iWAnEQIJnQCgofZJgZnU1y+lASNS7x9TkzabxeoAnisH hYFsXTqDHRU9XH2aKXhUU6eY =QMV0 -----END PGP SIGNATURE----- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 13:45:19 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18122 for ; Wed, 8 Aug 2001 13:45:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA89696; Wed, 8 Aug 2001 10:51:22 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA89679 for ; Wed, 8 Aug 2001 10:50:10 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f78HgtC27973; Wed, 8 Aug 2001 10:42:55 -0700 (PDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAH00113; Wed, 8 Aug 2001 13:42:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20010808112629.00ba85f0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: Jeff Learman Subject: Re: [Isis-wg] OSI ?? Cc: In-Reply-To: <000801c11f9a$4c189a70$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 13:40:33 -0400 Swati, At 11:06 AM 8/7/2001, Swati Rastogi wrote: >Hi All, >This is slightly off-track but any help in this regard will be really very >much appreciated. > >Here goes my long list of doubts > >(1) Is CLNP (OSI) analogous to IP (TCP/IP) .. If so then why have i never >come across a CLNP packet format (analogy .. we have IP packet formats) Yes, CLNP provides very similar services to IP. You don't see packet formats everywhere because it never became popular -- mostly because of the incredible success of IP. >(2) Routing is making sure that a packet reaches the destination safe 'n >sound .. while a routing protocol ensures that the out of the available >paths choosing the best one. So if ISIS runs along IP then who is taking >care of the "routing" aspect i.e taking the packet from the source to the >destination. IS-IS sends its packets directly over the link layer -- IP is not involved. There are two exceptions to this, (a) partition repair tunneling and (b) Integrated IS-IS over IP tunnels. (a) didn't work until a rather recent correction, and (b) was never popular. Ignore both of these until you have everything else VERY well understood. >ISIS is a routing protocol and its job shud be to just choose >the optimal path .. once its done that it can then hand over the packet to >CLNP for forwarding .. So where did i loose the track ?? You are correct and that's how it works. >(3) In my transport layer i could be running tp0, tp1, tp2 etc. How does the >routing module know which transport layer to forward the packet to. There is >only 1 byte field "SEL" aka selector in the NSAP addressing .. is this used >to determine this ?? >To summarize .. how when a module recvs a packet from the data link layer >determines whether to use CONP or CLNP in the networking layer and then >later which transport layer protocol is to be used in the transport layer! These are not IS-IS questions, so I will reply separately. >Which transport layer protocol does ISIS use ?? None, as mentioned above. >Please Help .. i am very confused with all the OSI terminology ! You're not the first! >Thanks and Regards, >Swati >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 13:47:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18144 for ; Wed, 8 Aug 2001 13:47:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA89718; Wed, 8 Aug 2001 10:53:59 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA89684 for ; Wed, 8 Aug 2001 10:50:10 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f78Hgfg11672; Wed, 8 Aug 2001 10:42:41 -0700 (PDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAH00115; Wed, 8 Aug 2001 13:42:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20010808113114.01d74cb8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: Jeff Learman Subject: Re: [Isis-wg] OSI ?? Cc: "Manav Bhatia" , In-Reply-To: <018801c11fe7$95230050$da046c6b@Manav> References: <000801c11f9a$4c189a70$da046c6b@Manav> <011301c11fe4$34096500$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 13:42:05 -0400 At 04:53 AM 8/8/2001, Swati Rastogi wrote: >> > (2) Routing is making sure that a packet reaches the destination safe 'n >> > sound .. while a routing protocol ensures that the out of the available >> > paths choosing the best one. So if ISIS runs along IP then who is taking >> > care of the "routing" aspect i.e taking the packet from the source to >the >> > destination. ISIS is a routing protocol and its job shud be to just >choose >> > the optimal path .. once its done that it can then hand over the packet >to >> > CLNP for forwarding .. So where did i loose the track ?? >> >> ISIS protocol is designed to work in close conjunction with ISO 8473 and >ISO >> 9542. The latter is used to establish connectivity and reachability >between >> end systems and Intermediate systems. Data is carried by ISO 8473. It >> provides connectionless mode network service. >> >Does it imply that all ISIS PDUs like L1 lan/p2p IIS Hello, L1/2 LSPs, L1/2 >CSNPs, L1/2 PSNPs form the data part in the ISO 8473 data PDU ? >Quoting Jeff . . No, none of these are carried in the data part of the 8473 data PDU. >" Be careful when you read "encapsulated in CLNS packets". It is absolutely >correct, but does NOT mean that they are encapsulated in CLNP packets. It >does mean that they are OSI connectionless layer three packets and therefore >begin with a Network Layer Protocol ID (variously called NPID, NLPI, or >NLPID). After that first octet, IS-IS and CLNP headers have little in >common." > >He says that ISIS packets are not encapsulated in CLNP packets .. Moreover >he also mentions that ISIS and CLNP headers have a little in common except >for NLPID ? >Does it imply that there will be different values in NLPID for CLNP,CONP and >ISIS packets ?? Yes, except for CONS, which is more complicated (remember, the network access protocol for CONS is X.25, and there is no standard protocol to implement X.25 in the service provider's network). CLNP is 0x81, ESIS is 0x82, ISIS is 0x83, IDRP has 0x84 (but doesn't use it), and Network Layer Security Protocol (ISO NLSP) uses 0x85. Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 13:54:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18249 for ; Wed, 8 Aug 2001 13:54:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA89785; Wed, 8 Aug 2001 11:00:23 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA89767 for ; Wed, 8 Aug 2001 10:59:20 -0700 (PDT) Received: (qmail 4055 invoked from network); 8 Aug 2001 17:40:12 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Aug 2001 17:40:12 -0000 From: "Ken Larmer" To: , "Swati Rastogi" Cc: "Ken Larmer" Subject: RE: [Isis-wg] OSI ?? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <000801c11f9a$4c189a70$da046c6b@Manav> Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 13:42:00 -0400 Content-Transfer-Encoding: 8bit Hi, Let me try to explain the difference between CLNS (Connection-Less Network Service) and CONS (Connection-Oriented Network Service). Furthermore, I will attempt to explain their use with IS-IS (OSI only) and I will then attempt to tie their use with Integrated IS-IS (Dual OSI and IP). One must remember that OSI was conceived in the 1980s by Digital with its primary reason being to increase DECnet Phase IV address space. Thus, Digital designed DECnet Phase V, which in turn spawned the better part of OSI. In the 1980s the predominate LAN technology was Ethernet and the predominate WAN technology was X.25. Ethernet circuits are considered to be Connection-Less, while X.25 networks are considered to be Connection-Oriented. The difference being that when an ES wants to transmit a data packet across an Ethernet, it simply sends it to the destination or to the default router. There is no need to establish a prior connection because all MTU sizes should be the same and there is no need to negotiate flow-control below the transport layer. However, on an X.25 network, an ES or IS must setup the connection to the remote DTE prior to transmission of data packets. X.25 has many negotiable options for data transfer, there are really no defaults, per say! So, CONS was employed as a mechanism for communicating with ISO-8208 X.25 packet switch networks to facilitate call setup, parameter negotiation, circuit maintenance and call teardown. SNDCF (Sub-Network Dependent Convergence Functions) are utilized by the OSI network layer to communicate with the X.25 PLP (Packet Level Protocol) for execution of these DTE functions. Through this CONS mechanism, we can setup, maintain and teardown SVCs between X.25 DTEs. Furthermore, since X.25 already possessed a method for guaranteed delivery (LAPB – Link Access Procedure Balanced) at the datalink DTE<>DCE and packet sequencing at the X.25 network layer DTEDTE, there is no need to sequence packets at the transport layer when using a CONS network. So, most applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport mechanism across CONS networks. TP0 and TP2 are much like UDP. Ethernet on the other hand does not require call establishment prior to transport of data. So, CLNS is used to communicate across this type of network. Since there is no guaranteed delivery mechanism with Ethernet (Broadcast circuits for that matter), we need to make sure we use a higher-layer to guarantee delivery of packets. This is where OSI TP4 comes into play. OSI TP4 is much like TCP in that it sequences packets and basically guarantees their delivery. Now, how does this tie into CLNP (Connection-Less Network Protocol) and the format of OSI packets? Well, both CONS and CLNS networks transfer OSI data in CLNP packet formats. On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is carrying OSI data, must have as its first octet a value of 128 (81 hex) = OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS control packet. This first octet is referred to as the NLPID (Network Layer Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD (Intradomain Routing Protocol Discriminator) for IS-IS control packets. This is how the packet is passed up the stack to the proper network layer entity. On a CONS X.25 network, OSI packets are exchanged as USER DATA contained within the X.25- PLP. Again, the first octet in the user data portion of an X.25 packet, must have as its first octet a value of 128 (81 hex) = OSI data packet. ES-IS and IS-IS are not normally run over an X.25 circuit. Instead most implementations of OSI/X.25 only allow for SVCs or DED (Dynamically Established Datalinks). In most cases, the OSI network layer uses X.121 addresses (X.25 DTE addresses), extracted from X.121 formatted NSAPs to signal the correct DTE for the call setup to the remote DTE. Another reason for not running ES-IS or IS-IS over an X.25 network is because some PSNs charge by the packet. Static routes are much cheaper. An IS-IS OSI-only router will exchange IS-IS and ES-IS control data encapsulated in a CLNP packet. An IS-IS OSI-only router will also forward OSI data in a CLNP packet. An Integrated IS-IS IP-only router will exchange IS-IS control data encapsulated in a CLNP packet. An IS-IS IP-only router will forward IP data in an IP encapsulated packet. It will NOT exchange any ES-IS control data nor will it forward any OSI data, just IP data in its native format. An Integrated IS-IS Dual router will act as both an OSI-only router and IP-only router. Finally, the SEL (Selector) portion of an NSAP, though not defined by any ISO docs in this manner, was used by Digital to signal the Network layer of a DECnet Phase V system to send this packet to either the NSP (DECnet Phase IV transport) or OSI Transport. Hope this helps? Cheers, Ken Larmer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 14:10:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18523 for ; Wed, 8 Aug 2001 14:10:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA89956; Wed, 8 Aug 2001 11:16:24 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA89931 for ; Wed, 8 Aug 2001 11:15:54 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id B0A80F2C4B; Wed, 8 Aug 2001 11:08:24 -0700 (PDT) To: "Martin, Christian" Cc: "IS-IS WG (E-mail)" , acee@redback.com, jenny@redback.com Subject: Re: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt In-reply-to: Mail from "Martin, Christian" dated Tue, 07 Aug 2001 17:44:08 EDT <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> From: Naiming Shen Message-Id: <20010808180824.B0A80F2C4B@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 11:08:24 -0700 Martin, some comments inline, thanks. ]Folks, ] ]I have some comments on the draft that I'd like to address with the WG. I ]apologize for cutting this so close to the meeting, but this is the first ]chance I've had to address it. ] ]A while back I began considering how IS-IS could be made to support PTP ]behavior over BMA networks. The driving force behind this was primarily the ]ability to assign arbitrary, per-neighbor metric information to individual ]neighbors. A second benefit would be the elimination of pseudonode exposion ]when a large amount of PTP LAN links were used to interconnect routers. I ]sent an email detailing the need to the WG, but there was little response. ]Some notable vendors also displayed little interest. The only suggestion I ]received, in fact, was to use PPPoE! After reviewing the draft, I have some ]concern about the utility of the proposal, and whether or not it satisfies a ]real need. While it does have merit and will help in many situations, the ]scope should be expanded to address some more complex situations. Comments ]of course are welcome. ] ]In regards to OSPF: ] ]OSPF currently supports NBMA networks. What we are attempting to do here is ]create PtMP (of where MP can be P if there are only two nodes on a LAN) ]networks out of BMA networks in order to support PTP type behavior, from a ]Djiktsra perspective, correct? This is in OSPF today. You can build NBNA ]networks on LANs and specify neighbors explicitly, with associated metrics. ]The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion ]based on the configured neighbor IP. As I see it, the only benefit the ]draft provides is the elimination of DR election (and the corresponding ]elimination of pseudonodes on PTP links), which can be done by making the ]interface point-to-multipoint (although requiring configuration). The major ]vendors support this feature today (I use it!). no comments on OSPF;-) ] ]In regards to IS-IS: ] ]This was the tricky part, as there was nothing in 10589 or 1195 (or any ]subsequent draft) that proposes how to do this. Furthermore, the ]interaction between CLNS and IP makes the address resolution issue a bit ]trickier. Anyway, here is what I was thinking of. general comment is that, this draft is an ietf draft, we are trying to solve some real problems on today's Internet, no attempt is made here trying to tie this into clns and make it so complicated so no prograss will be made for years to come. This draft only needs some very simple changes(almost no changes to the existing protocols) and make the p2p over LAN work for the IP protocol. it's so simple that it's almost emberassing to make it as an Internet draft:-) For most of the current router implementations, the major change proposed from this draft is to add a configuration knob. that's probably it. ] ]1) Create support for point-to-multipoint in IS-IS. This has some ]additional benefit outside of the scope of LANs, as it allows the protocol ]to be used on real NBMA networks like Frame Relay and ATM. The way to do ]this is either cumbersome for the vendor or cumbersome for the operator. It ]also may break the current separation between subnetwork-dependent and ]independent functions, which may not sit well with ISO (or some IETF ]members). Let's address 802.3 networks first. My feeling is this, isis does not have NBMA for so long since OSPF has "invented" it, with atm/frame relay "legacy" services less popular these days, i don't see a requirement to do this in ISIS for now. Even with OSPF, as i remember when i was with previous companies, we alwasy "advise" customers to use point-to-point when link-state protocols are used for obvious reasons the problems NBMA has. Yes, we can develop the nbma for isis, then adapt the nbma for the LAN, but don't think it's worth the effort. ] ]As I see it, ISIS Hellos should be sent as PTP hellos. This means sending ]them to a MAC address and an interface. The interface is then made ]point-to-multipoint. For each configured adjacency, assign a circuit ID ]based on the current mechanism in 10589. The PTP hellos must be ]encapsulated in 802.3 frames, of course, but they should be unicast. CSNP ]should not be sent every 10 seconds, but rather in response to SRM flag ]changes, etc. ] ]Every router knows how to forward traffic across a LAN without passing it ]through the DIS, based on SNPA information from adjacencies. Forwarding ]would be still based on SNPA information, which is easily extracted from the ]configured MAC address of the neighbor (hence, the adjacency). An ]additional feature could be to address the neighbors based on NSAP, and then ]use ES-IS or some other address resolution mechanism to determine the MAC ]address. Either way, forwarding is an issue local to the router, and should ]not be much of an issue. This is where the 'cumbersome-ness' shifts. ] ]As far as switched WANs, the same principles could be applied. However, ]there is the issue of mapping NSAPs to layer 2 circuit IDs (DLCIs, VCCs, ]etc) that isn't addressed outside of X.25 in ISO (AFAIK). This may be too ]much of an undertaking, although it may be worth consideration if there is ]sufficient interest. Some possiblilities would be to use static mapping of ]NSAPs to l2cid, which is common today, and then specifiy the neighbor, the ]interface, and the metric. ] ]Finally, this information could be extended to support ]draft-ietf-isis-traffic-03.txt, by including link coloring, reserved ]bandwidth, etc, although the RSVP piece becomes trickier in the way it is ]encoded on LANs and in the way one reserves bandwidth across virtual ]adjacencies in a shared media environment. Either way, they are workable ]issues, and should be addressed given the growing ubiquity of TE-extension ]support. when a circuit is a p2p-over-lan, it's just an p2p circuit to IGP, nothing says it can't carry TE TLV in it's LSPs. ] ]In summary: ] ]1) Keep the changes at the subnetwork-dependent layer as much as possible, ]i.e., make IS-IS think that a LAN link is a PTP link (or a collection of PtP ]links). This makes the modifications easier, development-wise. this draft only lets level-3 IGP knows this interface is a "p2p", no one else needs to know that. So the IGP thinks this is a p2p interface, and lower layer thinks(actually it is) a broadcast interface, that's it. ] ]2) Allow for both directly connected routers using LAN media as well as ]directed adjacencies across BMA networks for metric adjustment. ] ]3) If the specification is about removing DR election (which as it stands ]now, it is), state this explicitly. I still think this does not address all ]the issues, particlularly, the use of switches as media termination and ]router hubbing devices. well, it's a p2p circuit to IGP, no DR is needed, there is no need to explitely say that no DR election is needed on a p2p circuit. DR is only relavernt to IGP, not to layer two or below. I don't see how using a switch in the middle will change anything, swich is a layer two device, and we don't change anything on layer two here. ] ]4) Optionally allow IS-IS to use NSAP addresses as neighbors and build some ]kind of address resolution mechanism to direct PTP hellos to the appropriate ]MAC address. if you mean to include mac address resolution for clns, we don't try to do this here. ] ]5) Allow per neighbor metric adjustment, and possibly pseudolink coloring ]and reservable/reserved BW info. metric you of course can adjust, it's an isis circuit. color or other TE attributes is the same as normal p2p interface. you can do that too. ] ]6) Optionally consider mechanisms to build NBMA support into IS-IS for ]switched WAN media. PtMP mode would be best, although it requires ]additional flooding, etc. NBMA mode, as in OSPF, is nice but may be ]difficult to do in most cases (except for SMDS) ~8^> not in this draft, someone else can try. ] ]7) If it is desired to just turn a LAN link into a PTP link, then this is ]fine. However, if what I propose is acceptable, then the error checking ]portion of the draft needs to be modified to check for PtMP behavior first. not sure what error checking needs to be done, no ptmp attempt is being made. ] ]Finally, I would think that OSPF implementation modifications should be ]submitted separately to the OSPF-WG, and not to the IS-IS WG. As stated ]earlier, a good deal of the desired functionality specified in the draft is ]already specified in RFC 2328 and later versions, so it may be unnecessary. we can only submit into one working group, doesn't make sense to break this draft into isis, ospf, arp, etc seperate portions. the change on OSPF of this draft is that: NO CHANGE AT ALL. we can't find arp working group. so it goes into isis working group;-) ] ]Sorry this is so late - you may treat these comments as my contribution to ]the London meeting, in absentia of course. ;) appreciate for your comments. thanks. ] ]Best Regards, ] -chris ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 15:13:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19591 for ; Wed, 8 Aug 2001 15:13:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA90342; Wed, 8 Aug 2001 12:19:22 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by external.juniper.net (8.9.3/8.9.3) with SMTP id MAA90330 for ; Wed, 8 Aug 2001 12:18:29 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Aug 2001 19:10:58 -0000 X-Apparently-From: Message-ID: <00a101c1203e$641910b0$da046c6b@Manav> From: "Swati Rastogi" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Thanks ! Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 00:44:46 +0530 Content-Transfer-Encoding: 7bit Hi All, I am very grateful to James Carlson, Jeff Learman and Ken Larmer for all the help they offered to me and the personal guidance .. as a result of which i am able to understand most of the concepts which i was unable to grasp since a last few months ! Thanks a lot ! With warm regards, Swati Rastogi _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 15:52:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20226 for ; Wed, 8 Aug 2001 15:52:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA90564; Wed, 8 Aug 2001 12:59:23 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA90552 for ; Wed, 8 Aug 2001 12:58:55 -0700 (PDT) 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 MAA08987; Wed, 8 Aug 2001 12:51:25 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 12:51:25 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A5E1@avalon.pluris.com> From: Les Ginsberg To: "'Ken Larmer'" , isis-wg@spider.juniper.net, Swati Rastogi Subject: RE: [Isis-wg] OSI ?? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 8 Aug 2001 12:51:20 -0700 Ken - This is a good summary. A few minor corrections/clarifications. As has been mentioned in other responses, but is worth reemphasis, IS-IS PDUs are NOT encapsulated in CLNP PDUs as your text states below. IS-IS (as well as ES-IS) are run directly over the link layer. They can be de-multiplexed from CLNP PDUs by the initial byte in the NPDU - which is a Network Layer Protocol Identifier(NLPID) in all three cases: CLNP - 0x81(129) ES-IS - 0x82(130) IS-IS - 0x83(131) As far as the SEL byte is concerned, it should be intuitively thought of as an ID for the network layer user. The NSAP associated with a network layer user most often bears a close relationship to the network entity title(NET) assigned to the Layer 3 protocol. (Although strict interpretation of ISO addressing allows for a user NSAP to bear virtually no relationship to the NET this is not commonly encountered and is, frankly, too bizarre to be discussed.) So, if the NET assigned consisted of: Area address: 49 System ID: 1111.2222.3333 Selector: 00 (Always) then a network layer user on that box would have an NSAP which differed only in the selector (i.e. 49.1111.2222.3333.xx). There is no set of universally assigned values for the SEL byte. SEL's are assigned within an administrative domain or by industry agreement. For example, SONET(Bellcore/Telcordia) specifications assigned: 01 - OSI transport AF - TL1 Address Resolution Protocol (I think I remember that value correctly...) In order for OSI transport layers to successfully communicate within a SONET domain, these values would have to be used consistently. In this context, DEC's use of the selector byte to direct NPDUs to the appropriate transport layer is quite appropriate and consistent with OSI addressing semantics. Les > > Hi, > > Let me try to explain the difference between CLNS > (Connection-Less Network > Service) and CONS (Connection-Oriented Network Service). > Furthermore, I will > attempt to explain their use with IS-IS (OSI only) and I will > then attempt > to tie their use with Integrated IS-IS (Dual OSI and IP). > > One must remember that OSI was conceived in the 1980s > by Digital with its > primary reason being to increase DECnet Phase IV address space. Thus, > Digital designed DECnet Phase V, which in turn spawned the > better part of > OSI. In the 1980s the predominate LAN technology was Ethernet and the > predominate WAN technology was X.25. Ethernet circuits are > considered to be > Connection-Less, while X.25 networks are considered to be > Connection-Oriented. > > The difference being that when an ES wants to transmit a data > packet across > an Ethernet, it simply sends it to the destination or to the > default router. > There is no need to establish a prior connection because all MTU sizes > should be the same and there is no need to negotiate > flow-control below the > transport layer. However, on an X.25 network, an ES or IS > must setup the > connection to the remote DTE prior to transmission of data > packets. X.25 has > many negotiable options for data transfer, there are really > no defaults, per > say! > > So, CONS was employed as a mechanism for communicating > with ISO-8208 X.25 > packet switch networks to facilitate call setup, parameter > negotiation, > circuit maintenance and call teardown. SNDCF (Sub-Network Dependent > Convergence Functions) are utilized by the OSI network layer > to communicate > with the X.25 PLP (Packet Level Protocol) for execution of these DTE > functions. Through this CONS mechanism, we can setup, > maintain and teardown > SVCs between X.25 DTEs. > > Furthermore, since X.25 already possessed a method for > guaranteed delivery > (LAPB - Link Access Procedure Balanced) at the datalink > DTE<>DCE and packet > sequencing at the X.25 network layer DTEDTE, there is > no need to > sequence packets at the transport layer when using a CONS > network. So, most > applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport > mechanism across CONS networks. TP0 and TP2 are much like UDP. > > Ethernet on the other hand does not require call > establishment prior to > transport of data. So, CLNS is used to communicate across this type of > network. Since there is no guaranteed delivery mechanism with Ethernet > (Broadcast circuits for that matter), we need to make sure we use a > higher-layer to guarantee delivery of packets. This is where > OSI TP4 comes > into play. OSI TP4 is much like TCP in that it sequences packets and > basically guarantees their delivery. > > Now, how does this tie into CLNP (Connection-Less > Network Protocol) and the > format of OSI packets? Well, both CONS and CLNS networks > transfer OSI data > in CLNP packet formats. > > On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 > formatted ethernet frames. The data portion of an IEEE 802.3 > frame, which is > carrying OSI data, must have as its first octet a value of > 128 (81 hex) = > OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 > hex) IS-IS > control packet. This first octet is referred to as the NLPID > (Network Layer > Protocol Identifier) for ES-IS and OSI data and error packets > and as IRPD > (Intradomain Routing Protocol Discriminator) for IS-IS > control packets. This > is how the packet is passed up the stack to the proper > network layer entity. > > On a CONS X.25 network, OSI packets are exchanged as > USER DATA contained > within the X.25- PLP. Again, the first octet in the user data > portion of an > X.25 packet, must have as its first octet a value of 128 (81 > hex) = OSI data > packet. ES-IS and IS-IS are not normally run over an X.25 > circuit. Instead > most implementations of OSI/X.25 only allow for SVCs or DED > (Dynamically > Established Datalinks). In most cases, the OSI network layer > uses X.121 > addresses (X.25 DTE addresses), extracted from X.121 > formatted NSAPs to > signal the correct DTE for the call setup to the remote DTE. > Another reason > for not running ES-IS or IS-IS over an X.25 network is > because some PSNs > charge by the packet. Static routes are much cheaper. > > An IS-IS OSI-only router will exchange IS-IS and ES-IS > control data > encapsulated in a CLNP packet. An IS-IS OSI-only router will > also forward > OSI data in a CLNP packet. An Integrated IS-IS IP-only router > will exchange > IS-IS control data encapsulated in a CLNP packet. An IS-IS > IP-only router > will forward IP data in an IP encapsulated packet. It will > NOT exchange any > ES-IS control data nor will it forward any OSI data, just IP > data in its > native format. An Integrated IS-IS Dual router will act as > both an OSI-only > router and IP-only router. > > Finally, the SEL (Selector) portion of an NSAP, though > not defined by any > ISO docs in this manner, was used by Digital to signal the > Network layer of > a DECnet Phase V system to send this packet to either the NSP > (DECnet Phase > IV transport) or OSI Transport. > > Hope this helps? > > Cheers, > Ken Larmer > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 16:11:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20468 for ; Wed, 8 Aug 2001 16:11:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA90697; Wed, 8 Aug 2001 13:17:23 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA90685 for ; Wed, 8 Aug 2001 13:16:58 -0700 (PDT) Received: from JHARPER-W2K.cisco.com ([10.49.188.150]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA07513; Wed, 8 Aug 2001 21:09:24 +0100 (BST) Message-Id: <4.3.2.7.2.20010808130016.079c0860@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: John Harper Subject: RE: [Isis-wg] OSI ?? Cc: , "Swati Rastogi" , "Ken Larmer" In-Reply-To: References: <000801c11f9a$4c189a70$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id NAA90686 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 13:09:25 -0700 Content-Transfer-Encoding: 8bit This seems to be a rather inaccurate portrayal of the way it really was. I'm sure nobody cares, but I thought I'd correct it a little anyway. (I was chair of the OSI Network Layer group during the time it was doing all this, as well as running the lower layers of the DECnet/OSI architecture, so I really was There). First, OSI was conceived long before DEC latched onto it - in the late 70s, whilst our decision to adopt it was made in 1984. Our rationale was that if not, SNA would take over the world. If OSI achieved anything at all, it was to delay SNA for long enough that TCP/IP did in fact take over the world - meeting all the objectives that we at DEC had for OSI, even if all the actual protocols were different. Incidentally our original ideas for DECnet were to have 64-bit addresses. The OSI (NSAP) address format was a horrible compromise to accomodate the world views of both the phone companies and the data networking people (us and the tiny TCP/IP community at the time). CONS and CLNS were completely different religious views of the world. CONS came from the phone companies and from the view that X.25 was the centre of the universe, and everything else should look like it. CLNS of course came from the data networking community. Either of them had standards to allow it to operate over all kinds of subnetwork (OSI jargon), including both LANs and WANs such as X.25 and ISDN. (ISO/IEC 8881 tells you how to make a LAN look like an X.25 network, should you ever want to). In practice CONS collapsed under the combined weight of its own complexity and the general incompetence of its protagonists, and has never seen even a serious attempt to implement it, never mind deploy it. Incidentally CONS most definitely does (did) NOT transport data using CLNP packets. It used all kinds of complicated interworking arrangements at subnetwork boundaries precisely to avoid this approach, which was anethema to the CONS religion. As several people have already said, IS-IS does NOT use CLNP to carry its packets, nor does ES-IS. I happen to think this was an excellent decision, although John Moy certainly disagrees with me. John At 13:42 08/08/2001 -0400, Ken Larmer wrote: >Hi, > > Let me try to explain the difference between CLNS > (Connection-Less Network >Service) and CONS (Connection-Oriented Network Service). Furthermore, I will >attempt to explain their use with IS-IS (OSI only) and I will then attempt >to tie their use with Integrated IS-IS (Dual OSI and IP). > > One must remember that OSI was conceived in the 1980s by Digital > with its >primary reason being to increase DECnet Phase IV address space. Thus, >Digital designed DECnet Phase V, which in turn spawned the better part of >OSI. In the 1980s the predominate LAN technology was Ethernet and the >predominate WAN technology was X.25. Ethernet circuits are considered to be >Connection-Less, while X.25 networks are considered to be >Connection-Oriented. > >The difference being that when an ES wants to transmit a data packet across >an Ethernet, it simply sends it to the destination or to the default router. >There is no need to establish a prior connection because all MTU sizes >should be the same and there is no need to negotiate flow-control below the >transport layer. However, on an X.25 network, an ES or IS must setup the >connection to the remote DTE prior to transmission of data packets. X.25 has >many negotiable options for data transfer, there are really no defaults, per >say! > > So, CONS was employed as a mechanism for communicating with > ISO-8208 X.25 >packet switch networks to facilitate call setup, parameter negotiation, >circuit maintenance and call teardown. SNDCF (Sub-Network Dependent >Convergence Functions) are utilized by the OSI network layer to communicate >with the X.25 PLP (Packet Level Protocol) for execution of these DTE >functions. Through this CONS mechanism, we can setup, maintain and teardown >SVCs between X.25 DTEs. > >Furthermore, since X.25 already possessed a method for guaranteed delivery >(LAPB ­ Link Access Procedure Balanced) at the datalink DTE<>DCE and packet >sequencing at the X.25 network layer DTEDTE, there is no need to >sequence packets at the transport layer when using a CONS network. So, most >applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport >mechanism across CONS networks. TP0 and TP2 are much like UDP. > > Ethernet on the other hand does not require call establishment > prior to >transport of data. So, CLNS is used to communicate across this type of >network. Since there is no guaranteed delivery mechanism with Ethernet >(Broadcast circuits for that matter), we need to make sure we use a >higher-layer to guarantee delivery of packets. This is where OSI TP4 comes >into play. OSI TP4 is much like TCP in that it sequences packets and >basically guarantees their delivery. > > Now, how does this tie into CLNP (Connection-Less Network > Protocol) and the >format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >in CLNP packet formats. > >On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is >carrying OSI data, must have as its first octet a value of 128 (81 hex) = >OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >control packet. This first octet is referred to as the NLPID (Network Layer >Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >(Intradomain Routing Protocol Discriminator) for IS-IS control packets. This >is how the packet is passed up the stack to the proper network layer entity. > > On a CONS X.25 network, OSI packets are exchanged as USER DATA > contained >within the X.25- PLP. Again, the first octet in the user data portion of an >X.25 packet, must have as its first octet a value of 128 (81 hex) = OSI data >packet. ES-IS and IS-IS are not normally run over an X.25 circuit. Instead >most implementations of OSI/X.25 only allow for SVCs or DED (Dynamically >Established Datalinks). In most cases, the OSI network layer uses X.121 >addresses (X.25 DTE addresses), extracted from X.121 formatted NSAPs to >signal the correct DTE for the call setup to the remote DTE. Another reason >for not running ES-IS or IS-IS over an X.25 network is because some PSNs >charge by the packet. Static routes are much cheaper. > > An IS-IS OSI-only router will exchange IS-IS and ES-IS control data >encapsulated in a CLNP packet. An IS-IS OSI-only router will also forward >OSI data in a CLNP packet. An Integrated IS-IS IP-only router will exchange >IS-IS control data encapsulated in a CLNP packet. An IS-IS IP-only router >will forward IP data in an IP encapsulated packet. It will NOT exchange any >ES-IS control data nor will it forward any OSI data, just IP data in its >native format. An Integrated IS-IS Dual router will act as both an OSI-only >router and IP-only router. > > Finally, the SEL (Selector) portion of an NSAP, though not > defined by any >ISO docs in this manner, was used by Digital to signal the Network layer of >a DECnet Phase V system to send this packet to either the NSP (DECnet Phase >IV transport) or OSI Transport. > >Hope this helps? > >Cheers, >Ken Larmer > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 18:16:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22597 for ; Wed, 8 Aug 2001 18:16:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA91233; Wed, 8 Aug 2001 15:22:23 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA91221 for ; Wed, 8 Aug 2001 15:21:18 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f78M8XJ01703; Wed, 8 Aug 2001 18:08:33 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAI05139; Wed, 8 Aug 2001 18:08:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20010808141857.01dc2c78@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] OSI ?? Cc: , "Swati Rastogi" , "Ken Larmer" In-Reply-To: References: <000801c11f9a$4c189a70$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id PAA91222 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 18:08:23 -0400 Content-Transfer-Encoding: 8bit At 01:42 PM 8/8/2001, Ken Larmer wrote: >Hi, > > Let me try to explain the difference between CLNS (Connection-Less Network >Service) and CONS (Connection-Oriented Network Service). Furthermore, I will >attempt to explain their use with IS-IS (OSI only) and I will then attempt >to tie their use with Integrated IS-IS (Dual OSI and IP). > > One must remember that OSI was conceived in the 1980s by Digital with its >primary reason being to increase DECnet Phase IV address space. Thus, >Digital designed DECnet Phase V, which in turn spawned the better part of >OSI. In the 1980s the predominate LAN technology was Ethernet and the >predominate WAN technology was X.25. Ethernet circuits are considered to be >Connection-Less, while X.25 networks are considered to be >Connection-Oriented. > >The difference being that when an ES wants to transmit a data packet across >an Ethernet, it simply sends it to the destination or to the default router. >There is no need to establish a prior connection because all MTU sizes >should be the same and there is no need to negotiate flow-control below the >transport layer. However, on an X.25 network, an ES or IS must setup the >connection to the remote DTE prior to transmission of data packets. X.25 has >many negotiable options for data transfer, there are really no defaults, per >say! > > So, CONS was employed as a mechanism for communicating with ISO-8208 X.25 >packet switch networks to facilitate call setup, parameter negotiation, >circuit maintenance and call teardown. SNDCF (Sub-Network Dependent >Convergence Functions) are utilized by the OSI network layer to communicate >with the X.25 PLP (Packet Level Protocol) for execution of these DTE >functions. Through this CONS mechanism, we can setup, maintain and teardown >SVCs between X.25 DTEs. Warning: SNDCF is usually used to mean the way CLNS operates over a particular kind of data-link, and most commonly for the specific case of CLNP over X.25 (where CLNP is using X.25 as a link level protocol -- sort of like tunneling). >Furthermore, since X.25 already possessed a method for guaranteed delivery >(LAPB ­ Link Access Procedure Balanced) at the datalink DTE<>DCE and packet >sequencing at the X.25 network layer DTEDTE, there is no need to >sequence packets at the transport layer when using a CONS network. So, most >applications (both of them :^) use OSI TP0 or TP2 for an OSI Transport >mechanism across CONS networks. TP0 and TP2 are much like UDP. Not quite. CLTP is like UDP; they both provide a connectionless service. TP0 and TP2 are simpler protocols than TP4 or IP, but provide connection-oriented services over a network that is already connection-oriented, and therefore are simpler than TP4 or TCP, as Ken says. > Ethernet on the other hand does not require call establishment prior to >transport of data. So, CLNS is used to communicate across this type of >network. Since there is no guaranteed delivery mechanism with Ethernet >(Broadcast circuits for that matter), we need to make sure we use a >higher-layer to guarantee delivery of packets. This is where OSI TP4 comes >into play. OSI TP4 is much like TCP in that it sequences packets and >basically guarantees their delivery. True, except that there is a provision for X.25-CONS over LLC3, which is on Ethernet. Fortunately not very popular. > Now, how does this tie into CLNP (Connection-Less Network Protocol) and the >format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >in CLNP packet formats. False. The protocol used to provide CONS is X.25, and involves no CLNP packets. CLNP can operate over X.25, but CONS is not involved. >On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is >carrying OSI data, must have as its first octet a value of 128 (81 hex) = >OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >control packet. This first octet is referred to as the NLPID (Network Layer >Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >(Intradomain Routing Protocol Discriminator) for IS-IS control packets. IDRP is the inTER-domain routing protocol, not inTRA-domain, which is IS-IS. IDRP serves the same role as BGP does for IP, and like BGP is a distance-vector protocol, not a link-state protocol. >This >is how the packet is passed up the stack to the proper network layer entity. > > On a CONS X.25 network, OSI packets are exchanged as USER DATA contained >within the X.25- PLP. Again, the first octet in the user data portion of an >X.25 packet, must have as its first octet a value of 128 (81 hex) = OSI data >packet. This is true only when running CLNS over X.25, and the NLPID is really considered part of the CLNS PDU, according to the specs. (When I say CLNS in this context, I mean CLNP, ES-IS, or IS-IS.) >ES-IS and IS-IS are not normally run over an X.25 circuit. >Instead most implementations of OSI/X.25 only allow for SVCs or DED >(Dynamically Established Datalinks). Really? >In most cases, the OSI network layer uses X.121 >addresses (X.25 DTE addresses), extracted from X.121 formatted NSAPs to >signal the correct DTE for the call setup to the remote DTE. Another reason >for not running ES-IS or IS-IS over an X.25 network is because some PSNs >charge by the packet. Static routes are much cheaper. > > An IS-IS OSI-only router will exchange IS-IS and ES-IS control data >encapsulated in a CLNP packet. ES-IS and IS-IS packets are NOT exchanged in CLNP packets. >An IS-IS OSI-only router will also forward >OSI data in a CLNP packet. An Integrated IS-IS IP-only router will exchange >IS-IS control data encapsulated in a CLNP packet. IS-IS packets are NOT exchanged in CLNP packets. >An IS-IS IP-only router >will forward IP data in an IP encapsulated packet. It will NOT exchange any >ES-IS control data nor will it forward any OSI data, just IP data in its >native format. An Integrated IS-IS Dual router will act as both an OSI-only >router and IP-only router. > > Finally, the SEL (Selector) portion of an NSAP, though not defined by any >ISO docs in this manner, was used by Digital to signal the Network layer of >a DECnet Phase V system to send this packet to either the NSP (DECnet Phase >IV transport) or OSI Transport. True, the NSEL was not identified in ISO network layer addressing, CLNP, or ES-IS specs. It was discussed in NIST OIW agreements. Finally, though, IS-IS mandated that the final octet of an NSAP would not be used in routing decisions, except at the destination end system. Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 18:19:04 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22643 for ; Wed, 8 Aug 2001 18:19:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA91278; Wed, 8 Aug 2001 15:25:25 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA91235 for ; Wed, 8 Aug 2001 15:22:36 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f78MEpJ01986; Wed, 8 Aug 2001 18:14:51 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAI05367; Wed, 8 Aug 2001 18:15:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20010808180904.01e115d0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: Jeff Learman Subject: RE: [Isis-wg] OSI ?? Cc: "'Ken Larmer'" , isis-wg@spider.juniper.net, Swati Rastogi In-Reply-To: <17C81AD1F1FED411991E006008F6D1CAA5A5E1@avalon.pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 18:14:54 -0400 At 03:51 PM 8/8/2001, Les Ginsberg wrote: >In this context, DEC's use of the selector byte to direct NPDUs to the >appropriate transport layer is quite appropriate and consistent with OSI >addressing semantics. Yes, although it doesn't permit many of the capabilities offered by these protocols, such as multiplexing CLTP and TP2-4 on the same CONS connection, or negotiating the transport protocol from TP2 to TP0. Anyway, while it's allowable to use the NSEL to address a particular transport protocol engine, it's not necessary. TP0, TP1, TP2, TP3, TP4, and CLTP can be implemented in the same protocol engine and share the same NSEL. Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 8 18:21:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22671 for ; Wed, 8 Aug 2001 18:20:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA91309; Wed, 8 Aug 2001 15:27:24 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA91283 for ; Wed, 8 Aug 2001 15:26:07 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f78MILJ02100; Wed, 8 Aug 2001 18:18:21 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAI05451; Wed, 8 Aug 2001 18:18:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20010808144950.01f08c28@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Naiming Shen From: Jeff Learman Subject: Re: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt Cc: "Martin, Christian" , "IS-IS WG (E-mail)" , acee@redback.com, jenny@redback.com In-Reply-To: <20010808180824.B0A80F2C4B@prattle.redback.com> References: <94B9091E1149D411A45C00508BACEB359CDCEC@entmail.gnilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 18:18:31 -0400 At 02:08 PM 8/8/2001, Naiming Shen wrote: >My feeling is this, isis does not have NBMA for so long since OSPF has >"invented" it, with atm/frame relay "legacy" services less popular >these days, i don't see a requirement to do this in ISIS for now. >Even with OSPF, as i remember when i was with previous companies, >we alwasy "advise" customers to use point-to-point when link-state >protocols are used for obvious reasons the problems NBMA has. >Yes, we can develop the nbma for isis, then adapt the nbma for the >LAN, but don't think it's worth the effort. ISO 8473-1988 defined "general topology" networks, which are non-broadcast, multiple-access networks. X.25 is an example, and connectionless networks can be GT networks. IS-IS does not support exchange of routing information over GT networks unless they are modeled as collections of statically enabled point-to-point links. I don't know why, but perhaps it was because X.25 was the only prevalent GT network at the time, and it didn't make sense to have an SVC when exchanging periodic PDUs. Using an IGP over GT net certainly makes more sense for connectionless than for connection-oriented. Jeff _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 00:34:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28616 for ; Thu, 9 Aug 2001 00:34:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA92890; Wed, 8 Aug 2001 21:40:27 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA92875 for ; Wed, 8 Aug 2001 21:39:36 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 04:32:03 -0000 X-Apparently-From: Message-ID: <01fa01c1208c$c5d0a4a0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] SNAP & NSAP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 10:05:41 +0530 Content-Transfer-Encoding: 7bit I have a small doubt . . (i) NSAP is an OSI equivalent of an IP address in a TCP/IP network. Is SNAP address equivalent of the ethernet address in the data link layer if its a 802.2 ntwrk ? Rgds, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 02:25:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15824 for ; Thu, 9 Aug 2001 02:25:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA93427; Wed, 8 Aug 2001 23:31:23 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id XAA93415 for ; Wed, 8 Aug 2001 23:30:01 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 06:22:26 -0000 X-Apparently-From: Message-ID: <033f01c1209c$319fae60$da046c6b@Manav> From: "Swati Rastogi" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Area Architecture Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 11:56:13 +0530 Content-Transfer-Encoding: 7bit Hi, In OSPF it is said that the areas are bound to the interfaces and that the OSPF area boundaries fall within a router. This statement is not very clear and it gets more confusing when its said that in ISIS, area boundaries is on a link rather than in the router. What is bothering me is the fact that in ISIS also its only on the interface basis that i say that the particular link is L1 or L2. Let me explain . . A, B are both cisco routers A --------------------- B (L1/L2) (L1) A and B are both in the same area Configuration of router A would be interface loopback0 ip address 192.168.1.1 255.255.255.255 ! interface Pos2/0/0 ip address 192.168.16.1 255.255.255.0 ip router isis isis circuit-type-level-2 ! Fastethernet4/0/0 ip address 192.168.11.1 255.255.255.0 ip router isis isis circuit-type-level-1 ! router isis net 49.0001.1921.6800.1001.00 (1) If we look at the profile definition then here also we have defined the areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while 192.168.11/24 is L1. (2) Will all of the LSPs recvd on any one of the interfaces be known to the other ? Router configuration of Router B interface loopback0 ip address 192.168.1.2 255.255.255.255 ! interface Fastethernet0/0 ip address 192.168.11.2 255.255.255.0 ip router isis isis circuit-type-level-1 ! router isis net 49.0001.1921.6800.1002 (1) Here on the 192.168.1/24 interface both the routers are running L1 level routing .. So is ISIS not interface based ?? Please explain . . Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 02:55:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16132 for ; Thu, 9 Aug 2001 02:55:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA93594; Thu, 9 Aug 2001 00:01:24 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id AAA93579 for ; Thu, 9 Aug 2001 00:00:39 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 06:53:02 -0000 X-Apparently-From: Message-ID: <036101c120a0$77cdd980$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] L1/L2 Designated Router Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 12:26:48 +0530 Content-Transfer-Encoding: 7bit The LAN toplogy looks smthg like this .. O O | | ________|__________|______ | | (A) | | O O--> interface defined as L1 ^---- another interface defined as L2 (1) Suppose the IS A has the highest priority .. then can a single Intermediate system be both a LAN L1 Designated IS and a LAN L2 Designated IS. (2) Will this pseudonode be known by the ID (6 bytes in the NSAP address) of the designated IS followed by some pseudonode ID assigned by the designated IS ? Regards, Manav "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 05:23:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18514 for ; Thu, 9 Aug 2001 05:23:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA94471; Thu, 9 Aug 2001 02:29:23 -0700 (PDT) Received: from web8101.in.yahoo.com (web8101.in.yahoo.com [203.199.70.28]) by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA94459 for ; Thu, 9 Aug 2001 02:28:20 -0700 (PDT) Message-ID: <20010809092045.79428.qmail@web8101.in.yahoo.com> Received: from [203.200.20.224] by web8101.in.yahoo.com; Thu, 09 Aug 2001 10:20:45 BST From: =?iso-8859-1?q?sudhir=20dskjf?= To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [Isis-wg] Routing or forwarding Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 10:20:45 +0100 (BST) Content-Transfer-Encoding: 8bit hi all, The Dual Is-Is performs routing i.e to calculate the optimal path or it forwards packets also? I have this doubt because i read that the IS-IS uses the services of the data link directly. Can a routing protocol make use of a lower layer services or the Is-IS protocol makes use of CLNP or Ip for forwarding. thanks in advance srikrishna ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 05:29:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18608 for ; Thu, 9 Aug 2001 05:29:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA94533; Thu, 9 Aug 2001 02:36:24 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA94521 for ; Thu, 9 Aug 2001 02:35:23 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (ams-clip-vpn-dhcp51.cisco.com [10.50.0.50]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19535; Thu, 9 Aug 2001 11:27:46 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010809111542.00b48c50@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: stefano previdi Subject: Re: [Isis-wg] Area Architecture Cc: "isis-wg" In-Reply-To: <033f01c1209c$319fae60$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 11:25:17 +0200 At 08:26 09/08/2001, Swati Rastogi wrote: >Hi, >In OSPF it is said that the areas are bound to the interfaces and that the >OSPF area boundaries fall within a router. This statement is not very clear >and it gets more confusing when its said that in ISIS, area boundaries is on >a link rather than in the router. this because the router itself is configured as part of one area. What you did in your example below is that you forced (through some interface configuration commands) the router to establish a specific adjacency level. But this doesn't mean that the router is part of more areas. The router is still part of one area. s. >What is bothering me is the fact that in >ISIS also its only on the interface basis that i say that the particular >link is L1 or L2. >Let me explain . . >A, B are both cisco routers > >A --------------------- B >(L1/L2) (L1) > >A and B are both in the same area > >Configuration of router A would be > >interface loopback0 >ip address 192.168.1.1 255.255.255.255 >! >interface Pos2/0/0 >ip address 192.168.16.1 255.255.255.0 >ip router isis >isis circuit-type-level-2 >! >Fastethernet4/0/0 >ip address 192.168.11.1 255.255.255.0 >ip router isis >isis circuit-type-level-1 >! >router isis >net 49.0001.1921.6800.1001.00 > >(1) If we look at the profile definition then here also we have defined the >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while >192.168.11/24 is L1. >(2) Will all of the LSPs recvd on any one of the interfaces be known to the >other ? > >Router configuration of Router B > >interface loopback0 >ip address 192.168.1.2 255.255.255.255 >! >interface Fastethernet0/0 >ip address 192.168.11.2 255.255.255.0 >ip router isis >isis circuit-type-level-1 >! >router isis >net 49.0001.1921.6800.1002 > >(1) Here on the 192.168.1/24 interface both the routers are running L1 level >routing .. So is ISIS not interface based ?? > >Please explain . . > >Regards, >Swati > > > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 05:32:51 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18686 for ; Thu, 9 Aug 2001 05:32:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA94568; Thu, 9 Aug 2001 02:39:23 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA94551 for ; Thu, 9 Aug 2001 02:38:11 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (ams-clip-vpn-dhcp51.cisco.com [10.50.0.50]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA20776; Thu, 9 Aug 2001 11:30:34 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010809111256.0390ef08@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manav Bhatia" From: stefano previdi Subject: Re: [Isis-wg] L1/L2 Designated Router Cc: In-Reply-To: <036101c120a0$77cdd980$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 11:28:05 +0200 At 08:56 09/08/2001, Manav Bhatia wrote: >The LAN toplogy looks smthg like this .. > > O O > | | > ________|__________|______ > | | (A) > | | > O O--> interface defined as L1 > ^---- another interface defined as L2 > >(1) Suppose the IS A has the highest priority .. then can a single >Intermediate system be both a LAN L1 Designated IS and a LAN L2 Designated >IS. yes. >(2) Will this pseudonode be known by the ID (6 bytes in the NSAP address) of >the designated IS followed by some pseudonode ID assigned by the designated >IS ? yes, if your router is DIS for both levels, you will have two distinct pseudonodes. Pseudodone ID is part of LSP-ID: 6-bytes lsp-id 1-byte pseudonode-id 1-byte fragment number s. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 09:58:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23854 for ; Thu, 9 Aug 2001 09:58:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA95724; Thu, 9 Aug 2001 07:04:23 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA95712 for ; Thu, 9 Aug 2001 07:03:04 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id GAA25129; Thu, 9 Aug 2001 06:55:28 -0700 (PDT) From: Mike Truskowski Message-Id: <200108091355.GAA25129@diablo.cisco.com> Subject: Re: [Isis-wg] Area Architecture To: sprevidi@cisco.com (stefano previdi) Cc: swatirstogi@yahoo.com, isis-wg@spider.juniper.net In-Reply-To: <4.3.2.7.2.20010809111542.00b48c50@brussels.cisco.com>; from "stefano previdi" at Aug 9, 101 3:50 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 6:55:27 PDT Swati, First of all you are discussing the actions of a protocol and trying to relate them to how a router is configured. This is hard to do..... Consider a processor with I/O ports attached. For OSPF, when the processor runs OSPF each I/O port must be told that it is running OSPF and "which" area it is in. For ISIS, when the processor runs ISIS it is given an area address by default within the NET. Now when an I/O port is enabled for ISIS they belong to the same area as the processor or instance of ISIS Consider a simple example using 1 NET. So with a router... you configure the router to start ISIS by saying "router isis" but you also must tell this router his NET. router isis net 490001xxxxssssss00 Now when you enable an interface the interface is in this area by default....490001xxxx. mike > > At 08:26 09/08/2001, Swati Rastogi wrote: > >Hi, > >In OSPF it is said that the areas are bound to the interfaces and that the > >OSPF area boundaries fall within a router. This statement is not very clear > >and it gets more confusing when its said that in ISIS, area boundaries is on > >a link rather than in the router. > > this because the router itself is configured as part of one area. > What you did in your example below is that you forced (through some > interface configuration commands) the router to establish a specific > adjacency level. But this doesn't mean that the router is part of > more areas. The router is still part of one area. > > s. > > > >What is bothering me is the fact that in > >ISIS also its only on the interface basis that i say that the particular > >link is L1 or L2. > >Let me explain . . > >A, B are both cisco routers > > > >A --------------------- B > >(L1/L2) (L1) > > > >A and B are both in the same area > > > >Configuration of router A would be > > > >interface loopback0 > >ip address 192.168.1.1 255.255.255.255 > >! > >interface Pos2/0/0 > >ip address 192.168.16.1 255.255.255.0 > >ip router isis > >isis circuit-type-level-2 > >! > >Fastethernet4/0/0 > >ip address 192.168.11.1 255.255.255.0 > >ip router isis > >isis circuit-type-level-1 > >! > >router isis > >net 49.0001.1921.6800.1001.00 > > > >(1) If we look at the profile definition then here also we have defined the > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while > >192.168.11/24 is L1. > >(2) Will all of the LSPs recvd on any one of the interfaces be known to the > >other ? > > > >Router configuration of Router B > > > >interface loopback0 > >ip address 192.168.1.2 255.255.255.255 > >! > >interface Fastethernet0/0 > >ip address 192.168.11.2 255.255.255.0 > >ip router isis > >isis circuit-type-level-1 > >! > >router isis > >net 49.0001.1921.6800.1002 > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 level > >routing .. So is ISIS not interface based ?? > > > >Please explain . . > > > >Regards, > >Swati > > > > > > > > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at http://mail.yahoo.com > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 10:48:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25736 for ; Thu, 9 Aug 2001 10:48:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA96007; Thu, 9 Aug 2001 07:54:24 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA95995 for ; Thu, 9 Aug 2001 07:53:33 -0700 (PDT) Received: (qmail 55285 invoked from network); 9 Aug 2001 14:45:57 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Aug 2001 14:45:57 -0000 From: "Ken Larmer" To: "Jeff Learman" Cc: , "Swati Rastogi" Subject: RE: [Isis-wg] OSI ?? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.3.2.7.2.20010808141857.01dc2c78@dingdong.cisco.com> Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 10:47:46 -0400 Content-Transfer-Encoding: 7bit Thanks for all the corrections :^) I have a very bad habit of calling all OSI packets CLNP, when they are clearly not! Furthermore, I apologize if I miss-represented the evolution of OSI! Just a couple of comments and I'll fade away! Jeff, I believe you meant to say X.25 over ethernet is LLC2 not LLC3. Please correct me if I'm wrong. BTW, Digital had a lot of customers running this hack. I also realize you can run IS-IS over a X.25 PVC on one IS-IS implementation I know of. My comment was simply stating that this is not a common practice. Jeff, please help me here, I made the following statement: >Now, how does this tie into CLNP (Connection-Less Network Protocol) and the >format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >in CLNP packet formats. Your response: >False. The protocol used to provide CONS is X.25, and involves >no CLNP packets. CLNP can operate over X.25, but CONS is not involved. What is the format? CONS is used establish the connection and IS-IS does the forwarding. I know I didn't state that, but is that true? Jeff, please help me here, I made the following statement: >On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >formatted ethernet frames. The data portion of an IEEE 802.3 frame, which is >carrying OSI data, must have as its first octet a value of 128 (81 hex) = >OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >control packet. This first octet is referred to as the NLPID (Network Layer >Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >(Intradomain Routing Protocol Discriminator) for IS-IS control packets. Your response: >IDRP is the inTER-domain routing protocol, not inTRA-domain, which is >IS-IS. IDRP serves the same role as BGP does for IP, and like BGP is >a distance-vector protocol, not a link-state protocol. Jeff, did you mean IDRPI (Inter-Domain Routing Protocol Information) from RFC 1195. My statement refers to ISO-10589 control packets, the first octet of which is the IRPD (Intradomain Routing Protocol Discriminator)field. Of course, we could throw another 1,000 acronyms into OSI so it would be a bit more confusing. I believe that this open discussion is good for this working group. Much to often I see questions go unanswered because many folks do not have all the right answers or the ones that do are too busy to respond. I would rather see this type of discussion, than have a bunch of folks who are to afraid to respond because they may get some portion of their response wrong. This stuff is extremely complex and needs many minds to get the facts 100% correct. Just my thoughts! Cheers, Ken _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 10:56:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25960 for ; Thu, 9 Aug 2001 10:56:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA96089; Thu, 9 Aug 2001 08:02:24 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA96077 for ; Thu, 9 Aug 2001 08:01:57 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 14:54:20 -0000 X-Apparently-From: Message-ID: <00d601c120e3$b3f24a70$da046c6b@Manav> From: "Swati Rastogi" To: "Mike Truskowski" , "isis-wg" References: <200108091355.GAA25129@diablo.cisco.com> Subject: Re: [Isis-wg] Area Architecture MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 20:28:05 +0530 Content-Transfer-Encoding: 7bit Mike, If this is so then I am having problems visualizing as to how we can assign multiple addresses to an IS. For i always thought that area addresses are assigned per interface basis. There is this line in the rfc 1195 which says .. "A level 1 router will refuse to become a neighbor with a node whose area addresses do not overlap its area address." This creates a confusion too .. Consider the topology as shown below. A ----- B ------ C (l1) (l2) (l1) A & B are in the same area while C is in a different area. A and C are L1 routers and B is an L2 only. Firstly .. is this configuration possible ?? Secondly .. B and C are in different areas so how does the adjaceny go up ?? Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I thought that B should then be L1/L2 I know i am being miserable .. but please help! Thanks in advance .. Swati ----- Original Message ----- From: "Mike Truskowski" To: "stefano previdi" Cc: ; Sent: Thursday, August 09, 2001 7:25 PM Subject: Re: [Isis-wg] Area Architecture > Swati, > First of all you are discussing the actions of a protocol > and trying to relate them to how a router is configured. > This is hard to do..... > > Consider a processor with I/O ports attached. > > For OSPF, when the processor runs OSPF each I/O port > must be told that it is running OSPF and "which" area > it is in. > > For ISIS, when the processor runs ISIS it is given > an area address by default within the NET. Now > when an I/O port is enabled for ISIS they belong > to the same area as the processor or instance of ISIS > > Consider a simple example using 1 NET. > So with a router... you configure the router to > start ISIS by saying "router isis" but you also > must tell this router his NET. > > router isis > net 490001xxxxssssss00 > > Now when you enable an interface the interface is in > this area by default....490001xxxx. > > mike > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > >Hi, > > >In OSPF it is said that the areas are bound to the interfaces and that the > > >OSPF area boundaries fall within a router. This statement is not very clear > > >and it gets more confusing when its said that in ISIS, area boundaries is on > > >a link rather than in the router. > > > > this because the router itself is configured as part of one area. > > What you did in your example below is that you forced (through some > > interface configuration commands) the router to establish a specific > > adjacency level. But this doesn't mean that the router is part of > > more areas. The router is still part of one area. > > > > s. > > > > > > >What is bothering me is the fact that in > > >ISIS also its only on the interface basis that i say that the particular > > >link is L1 or L2. > > >Let me explain . . > > >A, B are both cisco routers > > > > > >A --------------------- B > > >(L1/L2) (L1) > > > > > >A and B are both in the same area > > > > > >Configuration of router A would be > > > > > >interface loopback0 > > >ip address 192.168.1.1 255.255.255.255 > > >! > > >interface Pos2/0/0 > > >ip address 192.168.16.1 255.255.255.0 > > >ip router isis > > >isis circuit-type-level-2 > > >! > > >Fastethernet4/0/0 > > >ip address 192.168.11.1 255.255.255.0 > > >ip router isis > > >isis circuit-type-level-1 > > >! > > >router isis > > >net 49.0001.1921.6800.1001.00 > > > > > >(1) If we look at the profile definition then here also we have defined the > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 while > > >192.168.11/24 is L1. > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to the > > >other ? > > > > > >Router configuration of Router B > > > > > >interface loopback0 > > >ip address 192.168.1.2 255.255.255.255 > > >! > > >interface Fastethernet0/0 > > >ip address 192.168.11.2 255.255.255.0 > > >ip router isis > > >isis circuit-type-level-1 > > >! > > >router isis > > >net 49.0001.1921.6800.1002 > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 level > > >routing .. So is ISIS not interface based ?? > > > > > >Please explain . . > > > > > >Regards, > > >Swati > > > > > > > > > > > > > > > > > >_________________________________________________________ > > >Do You Yahoo!? > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 11:20:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26888 for ; Thu, 9 Aug 2001 11:20:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA96294; Thu, 9 Aug 2001 08:27:24 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA96282 for ; Thu, 9 Aug 2001 08:26:37 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id IAA24299; Thu, 9 Aug 2001 08:19:00 -0700 (PDT) From: Mike Truskowski Message-Id: <200108091519.IAA24299@diablo.cisco.com> Subject: Re: [Isis-wg] Area Architecture To: swatirstogi@yahoo.com (Swati Rastogi) Cc: truskows@cisco.com, isis-wg@spider.juniper.net In-Reply-To: <00d601c120e3$b3f24a70$da046c6b@Manav>; from "Swati Rastogi" at Aug 9, 101 7:58 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 8:19:00 PDT I don't mind answering questions but I want to know who you work for. In my email I stated that I would give a simple example. see below... > > Mike, > If this is so then I am having problems visualizing as to how we can assign > multiple addresses to an IS. For i always thought that area addresses are > assigned per interface basis. > There is this line in the rfc 1195 which says .. "A level 1 router will > refuse to become a neighbor with a node whose area addresses do not overlap > its area address." This creates a confusion too .. Consider the topology as > shown below. > > A ----- B ------ C > (l1) (l2) (l1) > > A & B are in the same area while C is in a different area. > A and C are L1 routers and B is an L2 only. > > Firstly .. is this configuration possible ?? This is not a valid topology "if" the lines connecting them is serial links. If so put B into the same are by saying: router isis net 12 net 11 If you want to the the following with an ethernet... B (11) | ------------- | | A(12) C(12) Then this works as long as either A or C is L1/L2 and B is L2. A and C will create a L1 adjacency. C and B will create a L2 adjacency. If A wants to send a packet to B then the router will be A-to-C-to-B... following the L2 route. A will pick C because C having the adjacency with B will have access to external areas. Then the L1 instance on C will set the ATT bit telling A that C has a path. During SPF time A will set C as the next hop out to forward packets outside the area. > Secondly .. B and C are in different areas so how does the adjaceny go up ?? The adjacency in this case will not come up. A and C are L1 in area 11. B is in 12. No level 1 adjacency because they must be in the same area. No level 2 because only B is level 2. If you change, say C, to be L1/L2 then there will be an adjacency between B & C. A will be black holed. Alone and unreachable. > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > thought that B should then be L1/L2 See above. Mike > > I know i am being miserable .. but please help! > > Thanks in advance .. > > Swati > > ----- Original Message ----- > From: "Mike Truskowski" > To: "stefano previdi" > Cc: ; > Sent: Thursday, August 09, 2001 7:25 PM > Subject: Re: [Isis-wg] Area Architecture > > > > Swati, > > First of all you are discussing the actions of a protocol > > and trying to relate them to how a router is configured. > > This is hard to do..... > > > > Consider a processor with I/O ports attached. > > > > For OSPF, when the processor runs OSPF each I/O port > > must be told that it is running OSPF and "which" area > > it is in. > > > > For ISIS, when the processor runs ISIS it is given > > an area address by default within the NET. Now > > when an I/O port is enabled for ISIS they belong > > to the same area as the processor or instance of ISIS > > > > Consider a simple example using 1 NET. > > So with a router... you configure the router to > > start ISIS by saying "router isis" but you also > > must tell this router his NET. > > > > router isis > > net 490001xxxxssssss00 > > > > Now when you enable an interface the interface is in > > this area by default....490001xxxx. > > > > mike > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > >Hi, > > > >In OSPF it is said that the areas are bound to the interfaces and that > the > > > >OSPF area boundaries fall within a router. This statement is not very > clear > > > >and it gets more confusing when its said that in ISIS, area boundaries > is on > > > >a link rather than in the router. > > > > > > this because the router itself is configured as part of one area. > > > What you did in your example below is that you forced (through some > > > interface configuration commands) the router to establish a specific > > > adjacency level. But this doesn't mean that the router is part of > > > more areas. The router is still part of one area. > > > > > > s. > > > > > > > > > >What is bothering me is the fact that in > > > >ISIS also its only on the interface basis that i say that the > particular > > > >link is L1 or L2. > > > >Let me explain . . > > > >A, B are both cisco routers > > > > > > > >A --------------------- B > > > >(L1/L2) (L1) > > > > > > > >A and B are both in the same area > > > > > > > >Configuration of router A would be > > > > > > > >interface loopback0 > > > >ip address 192.168.1.1 255.255.255.255 > > > >! > > > >interface Pos2/0/0 > > > >ip address 192.168.16.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-2 > > > >! > > > >Fastethernet4/0/0 > > > >ip address 192.168.11.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1001.00 > > > > > > > >(1) If we look at the profile definition then here also we have defined > the > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 > while > > > >192.168.11/24 is L1. > > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to > the > > > >other ? > > > > > > > >Router configuration of Router B > > > > > > > >interface loopback0 > > > >ip address 192.168.1.2 255.255.255.255 > > > >! > > > >interface Fastethernet0/0 > > > >ip address 192.168.11.2 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1002 > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 > level > > > >routing .. So is ISIS not interface based ?? > > > > > > > >Please explain . . > > > > > > > >Regards, > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 11:55:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28315 for ; Thu, 9 Aug 2001 11:55:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96495; Thu, 9 Aug 2001 09:02:24 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96483 for ; Thu, 9 Aug 2001 09:01:21 -0700 (PDT) Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA00496; Thu, 9 Aug 2001 08:53:20 -0700 (PDT) Message-Id: <4.3.2.7.2.20010809104554.02cb3620@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manav Bhatia" From: Micah Bartell Subject: Re: [Isis-wg] SNAP & NSAP Cc: In-Reply-To: <01fa01c1208c$c5d0a4a0$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 10:53:19 -0500 SNAP? That refers to a data link encapsulation for Ethernet, it is an extension of the 802.2 protocol. Are you sure you are not referring to SNPA, which is Subnetwork Point of Attachment? This is the same as the MAC address. /mpb At 10:05 08/09/2001 +0530, Manav Bhatia wrote: >I have a small doubt . . > >(i) NSAP is an OSI equivalent of an IP address in a TCP/IP network. >Is SNAP address equivalent of the ethernet address in the data link layer if >its a 802.2 ntwrk ? > >Rgds, >Manav > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 12:02:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28666 for ; Thu, 9 Aug 2001 12:02:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96552; Thu, 9 Aug 2001 09:08:24 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96540 for ; Thu, 9 Aug 2001 09:07:19 -0700 (PDT) Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA00749; Thu, 9 Aug 2001 08:59:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20010809105526.02ab0210@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: sudhir dskjf From: Micah Bartell Subject: Re: [Isis-wg] Routing or forwarding Cc: isis-wg@spider.juniper.net In-Reply-To: <20010809092045.79428.qmail@web8101.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 10:59:38 -0500 Or are you talking about IS-IS fowarding LSP's? Because IS-IS runs directly over the data link, it would not make use of CLNS or IP for it's forwarding. Some other protocols do make use of other L3 protocols for forwarding routing information, such as OSPF making use of IP. Is this what you were looking for? /mpb At 10:20 08/09/2001 +0100, sudhir dskjf wrote: >hi all, >The Dual Is-Is performs routing i.e to calculate the >optimal path or it forwards packets also? >I have this doubt because i read that the IS-IS uses >the services of the data link directly. Can a routing >protocol make use of a lower layer services or the >Is-IS protocol makes use of CLNP or Ip for forwarding. > >thanks in advance >srikrishna > >____________________________________________________________ >Do You Yahoo!? >Send a newsletter, share photos & files, conduct polls, organize chat >events. Visit http://in.groups.yahoo.com. >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 12:10:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28841 for ; Thu, 9 Aug 2001 12:10:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96649; Thu, 9 Aug 2001 09:15:27 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA96617 for ; Thu, 9 Aug 2001 09:14:36 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 16:06:57 -0000 X-Apparently-From: Message-ID: <002501c120ed$d92e4230$da046c6b@Manav> From: "Swati Rastogi" To: "Mike Truskowski" Cc: "isis-wg" Subject: Fw: [Isis-wg] Area Architecture MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 21:40:42 +0530 Content-Transfer-Encoding: 7bit Pl. see my comments inline .. > Hi Mike, > I am working in a startup company and we are trying to develop the entire > tcp/ip stack. I have to look after the integrated ISIS .. this is my second > job .. prior to this i was working on BGP for a firm known as Tata > Consultancy Services (TCS) .. > > Regards, > Swati Rastogi > > ----- Original Message ----- > From: "Mike Truskowski" > To: "Swati Rastogi" > Cc: ; > Sent: Thursday, August 09, 2001 8:49 PM > Subject: Re: [Isis-wg] Area Architecture > > > > I don't mind answering questions but I want to know > > who you work for. > > > > > > A ----- B ------ C > > > (l1) (l2) (l1) > > > > > > A & B are in the same area while C is in a different area. > > > A and C are L1 routers and B is an L2 only. > > > > > > Firstly .. is this configuration possible ?? > > This is not a valid topology "if" the lines connecting > > them is serial links. If so put B into the same are by > > saying: > > router isis > > net 12 > > net 11 > > > > If you want to the the following with an ethernet... > > > > B (11) > > | > > ------------- > > | | > > A(12) C(12) > > > > Then this works as long as either A or C is L1/L2 and > > B is L2. > > > > A and C will create a L1 adjacency. Can i have L1 adjaceny between ISs in differet areas ! How !?!?! AFAIK i mentioned that A & B are in the same area while C is in some other area. > > C and B will create a L2 adjacency. I think you got the routers wrong ! Your figure above says that B is L1 then how can it have L2 adjaceny with B ??? > > If A wants to send a packet to B then the router will > > be A-to-C-to-B... following the L2 route. Why A and B are in same areas .. !?!? I think you had smthg else in mind and you have written something else .. could you please check that ! Regards, Swati > > > > A will pick C because C having the adjacency with B will > > have access to external areas. Then the L1 instance on > > C will set the ATT bit telling A that C has a path. > > During SPF time A will set C as the next hop out to forward > > packets outside the area. > > > > > Secondly .. B and C are in different areas so how does the adjaceny go > up ?? > > The adjacency in this case will not come up. > > A and C are L1 in area 11. B is in 12. > > No level 1 adjacency because they must be in the same area. > > No level 2 because only B is level 2. > > If you change, say C, to be L1/L2 then there will be > > an adjacency between B & C. A will be black holed. Alone > > and unreachable. > > > > > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > > > thought that B should then be L1/L2 > > See above. > > > > Mike > > > > > > > > > > I know i am being miserable .. but please help! > > > > > > Thanks in advance .. > > > > > > Swati > > > > > > ----- Original Message ----- > > > From: "Mike Truskowski" > > > To: "stefano previdi" > > > Cc: ; > > > Sent: Thursday, August 09, 2001 7:25 PM > > > Subject: Re: [Isis-wg] Area Architecture > > > > > > > > > > Swati, > > > > First of all you are discussing the actions of a protocol > > > > and trying to relate them to how a router is configured. > > > > This is hard to do..... > > > > > > > > Consider a processor with I/O ports attached. > > > > > > > > For OSPF, when the processor runs OSPF each I/O port > > > > must be told that it is running OSPF and "which" area > > > > it is in. > > > > > > > > For ISIS, when the processor runs ISIS it is given > > > > an area address by default within the NET. Now > > > > when an I/O port is enabled for ISIS they belong > > > > to the same area as the processor or instance of ISIS > > > > > > > > Consider a simple example using 1 NET. > > > > So with a router... you configure the router to > > > > start ISIS by saying "router isis" but you also > > > > must tell this router his NET. > > > > > > > > router isis > > > > net 490001xxxxssssss00 > > > > > > > > Now when you enable an interface the interface is in > > > > this area by default....490001xxxx. > > > > > > > > mike > > > > > > > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > > > >Hi, > > > > > >In OSPF it is said that the areas are bound to the interfaces and > that > > > the > > > > > >OSPF area boundaries fall within a router. This statement is not > very > > > clear > > > > > >and it gets more confusing when its said that in ISIS, area > boundaries > > > is on > > > > > >a link rather than in the router. > > > > > > > > > > this because the router itself is configured as part of one area. > > > > > What you did in your example below is that you forced (through some > > > > > interface configuration commands) the router to establish a specific > > > > > adjacency level. But this doesn't mean that the router is part of > > > > > more areas. The router is still part of one area. > > > > > > > > > > s. > > > > > > > > > > > > > > > >What is bothering me is the fact that in > > > > > >ISIS also its only on the interface basis that i say that the > > > particular > > > > > >link is L1 or L2. > > > > > >Let me explain . . > > > > > >A, B are both cisco routers > > > > > > > > > > > >A --------------------- B > > > > > >(L1/L2) (L1) > > > > > > > > > > > >A and B are both in the same area > > > > > > > > > > > >Configuration of router A would be > > > > > > > > > > > >interface loopback0 > > > > > >ip address 192.168.1.1 255.255.255.255 > > > > > >! > > > > > >interface Pos2/0/0 > > > > > >ip address 192.168.16.1 255.255.255.0 > > > > > >ip router isis > > > > > >isis circuit-type-level-2 > > > > > >! > > > > > >Fastethernet4/0/0 > > > > > >ip address 192.168.11.1 255.255.255.0 > > > > > >ip router isis > > > > > >isis circuit-type-level-1 > > > > > >! > > > > > >router isis > > > > > >net 49.0001.1921.6800.1001.00 > > > > > > > > > > > >(1) If we look at the profile definition then here also we have > defined > > > the > > > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my > L2 > > > while > > > > > >192.168.11/24 is L1. > > > > > >(2) Will all of the LSPs recvd on any one of the interfaces be > known to > > > the > > > > > >other ? > > > > > > > > > > > >Router configuration of Router B > > > > > > > > > > > >interface loopback0 > > > > > >ip address 192.168.1.2 255.255.255.255 > > > > > >! > > > > > >interface Fastethernet0/0 > > > > > >ip address 192.168.11.2 255.255.255.0 > > > > > >ip router isis > > > > > >isis circuit-type-level-1 > > > > > >! > > > > > >router isis > > > > > >net 49.0001.1921.6800.1002 > > > > > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running > L1 > > > level > > > > > >routing .. So is ISIS not interface based ?? > > > > > > > > > > > >Please explain . . > > > > > > > > > > > >Regards, > > > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > > > >Do You Yahoo!? > > > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > >_______________________________________________ > > > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > _______________________________________________ > > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 12:15:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29034 for ; Thu, 9 Aug 2001 12:15:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96715; Thu, 9 Aug 2001 09:21:26 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96695 for ; Thu, 9 Aug 2001 09:20:55 -0700 (PDT) Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA01511; Thu, 9 Aug 2001 09:13:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20010809110059.02d03cc0@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: Micah Bartell Subject: Re: [Isis-wg] Area Architecture Cc: "Mike Truskowski" , "isis-wg" In-Reply-To: <00d601c120e3$b3f24a70$da046c6b@Manav> References: <200108091355.GAA25129@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 11:13:14 -0500 At 20:28 08/09/2001 +0530, Swati Rastogi wrote: >Mike, >If this is so then I am having problems visualizing as to how we can assign >multiple addresses to an IS. For i always thought that area addresses are >assigned per interface basis. NSAP's are applied per node, while IP addresses are applied per interface. If we assign multiple NSAP's to a single node, that "area" is actually the union of those area addresses. >There is this line in the rfc 1195 which says .. "A level 1 router will >refuse to become a neighbor with a node whose area addresses do not overlap >its area address." If a router is an L1-Only router and receives an IIH from a neighbor with a different Area Address, it will not form an adjacency. >This creates a confusion too .. Consider the topology as >shown below. > >A ----- B ------ C >(l1) (l2) (l1) > >A & B are in the same area while C is in a different area. >A and C are L1 routers and B is an L2 only. > >Firstly .. is this configuration possible ?? If A is L1-Only, and B is L2-Only, what level of adjacency would they form? If C is in a different are, but is L1-Only, what level of adjacency would it form with B, which is L2-Only? This would be a broken design. Make A L1-Only, B L1L2, and C L1L2 and everything works fine. >Secondly .. B and C are in different areas so how does the adjaceny go up ?? It will only go up if you allow them to form L2 adjacencies. >Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. No. > I >thought that B should then be L1/L2 Yes, you need to allow adjacency usage L1, with B being an L1L2 router. >I know i am being miserable .. but please help! > >Thanks in advance .. > >Swati > >----- Original Message ----- >From: "Mike Truskowski" >To: "stefano previdi" >Cc: ; >Sent: Thursday, August 09, 2001 7:25 PM >Subject: Re: [Isis-wg] Area Architecture > > > > Swati, > > First of all you are discussing the actions of a protocol > > and trying to relate them to how a router is configured. > > This is hard to do..... > > > > Consider a processor with I/O ports attached. > > > > For OSPF, when the processor runs OSPF each I/O port > > must be told that it is running OSPF and "which" area > > it is in. > > > > For ISIS, when the processor runs ISIS it is given > > an area address by default within the NET. Now > > when an I/O port is enabled for ISIS they belong > > to the same area as the processor or instance of ISIS > > > > Consider a simple example using 1 NET. > > So with a router... you configure the router to > > start ISIS by saying "router isis" but you also > > must tell this router his NET. > > > > router isis > > net 490001xxxxssssss00 > > > > Now when you enable an interface the interface is in > > this area by default....490001xxxx. > > > > mike > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > >Hi, > > > >In OSPF it is said that the areas are bound to the interfaces and that >the > > > >OSPF area boundaries fall within a router. This statement is not very >clear > > > >and it gets more confusing when its said that in ISIS, area boundaries >is on > > > >a link rather than in the router. > > > > > > this because the router itself is configured as part of one area. > > > What you did in your example below is that you forced (through some > > > interface configuration commands) the router to establish a specific > > > adjacency level. But this doesn't mean that the router is part of > > > more areas. The router is still part of one area. > > > > > > s. > > > > > > > > > >What is bothering me is the fact that in > > > >ISIS also its only on the interface basis that i say that the >particular > > > >link is L1 or L2. > > > >Let me explain . . > > > >A, B are both cisco routers > > > > > > > >A --------------------- B > > > >(L1/L2) (L1) > > > > > > > >A and B are both in the same area > > > > > > > >Configuration of router A would be > > > > > > > >interface loopback0 > > > >ip address 192.168.1.1 255.255.255.255 > > > >! > > > >interface Pos2/0/0 > > > >ip address 192.168.16.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-2 > > > >! > > > >Fastethernet4/0/0 > > > >ip address 192.168.11.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1001.00 > > > > > > > >(1) If we look at the profile definition then here also we have defined >the > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 >while > > > >192.168.11/24 is L1. > > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to >the > > > >other ? > > > > > > > >Router configuration of Router B > > > > > > > >interface loopback0 > > > >ip address 192.168.1.2 255.255.255.255 > > > >! > > > >interface Fastethernet0/0 > > > >ip address 192.168.11.2 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1002 > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 >level > > > >routing .. So is ISIS not interface based ?? > > > > > > > >Please explain . . > > > > > > > >Regards, > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 12:21:19 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29257 for ; Thu, 9 Aug 2001 12:21:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96794; Thu, 9 Aug 2001 09:27:24 -0700 (PDT) Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA96777 for ; Thu, 9 Aug 2001 09:26:12 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 16:18:35 -0000 X-Apparently-From: Message-ID: <004901c120ef$78f5ece0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "sudhir dskjf" , "Micah Bartell" Cc: References: <4.3.2.7.2.20010809105526.02ab0210@cactus.cisco.com> Subject: Re: [Isis-wg] Routing or forwarding Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 21:52:19 +0530 Content-Transfer-Encoding: 7bit I think what Sudhir meant was that if IS-IS just performs the routing functions then who forwards these packets (ISIS) to the underlying network .. since it is not supposed to be running on top of any networking layer protocol ! Manav ----- Original Message ----- From: "Micah Bartell" To: "sudhir dskjf" Cc: Sent: Thursday, August 09, 2001 9:29 PM Subject: Re: [Isis-wg] Routing or forwarding > Or are you talking about IS-IS fowarding LSP's? Because IS-IS runs > directly over the data link, it would not make use of CLNS or IP for it's > forwarding. Some other protocols do make use of other L3 protocols for > forwarding routing information, such as OSPF making use of IP. > > Is this what you were looking for? > > /mpb > > At 10:20 08/09/2001 +0100, sudhir dskjf wrote: > >hi all, > >The Dual Is-Is performs routing i.e to calculate the > >optimal path or it forwards packets also? > >I have this doubt because i read that the IS-IS uses > >the services of the data link directly. Can a routing > >protocol make use of a lower layer services or the > >Is-IS protocol makes use of CLNP or Ip for forwarding. > > > >thanks in advance > >srikrishna > > > >____________________________________________________________ > >Do You Yahoo!? > >Send a newsletter, share photos & files, conduct polls, organize chat > >events. Visit http://in.groups.yahoo.com. > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 12:22:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29323 for ; Thu, 9 Aug 2001 12:22:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96837; Thu, 9 Aug 2001 09:29:27 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96796 for ; Thu, 9 Aug 2001 09:27:57 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id JAA16521; Thu, 9 Aug 2001 09:20:20 -0700 (PDT) From: Mike Truskowski Message-Id: <200108091620.JAA16521@diablo.cisco.com> Subject: Re: Fw: [Isis-wg] Area Architecture To: swatirstogi@yahoo.com (Swati Rastogi) Cc: truskows@cisco.com, isis-wg@spider.juniper.net In-Reply-To: <002501c120ed$d92e4230$da046c6b@Manav>; from "Swati Rastogi" at Aug 9, 101 9:12 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 9:20:20 PDT Swati, Yep, I got it wrong... I answered the questions for the following topology. A----B----C (11) (12) (11). A and C in same area = 11 B in area 12 A and C are L1 only B is L1/L2. I will go back an reply properly to what you sent the first time... mike > > > Pl. see my comments inline .. > > > Hi Mike, > > I am working in a startup company and we are trying to develop the entire > > tcp/ip stack. I have to look after the integrated ISIS .. this is my > second > > job .. prior to this i was working on BGP for a firm known as Tata > > Consultancy Services (TCS) .. > > > > Regards, > > Swati Rastogi > > > > ----- Original Message ----- > > From: "Mike Truskowski" > > To: "Swati Rastogi" > > Cc: ; > > Sent: Thursday, August 09, 2001 8:49 PM > > Subject: Re: [Isis-wg] Area Architecture > > > > > > > I don't mind answering questions but I want to know > > > who you work for. > > > > > > > > > A ----- B ------ C > > > > (l1) (l2) (l1) > > > > > > > > A & B are in the same area while C is in a different area. > > > > A and C are L1 routers and B is an L2 only. > > > > > > > > Firstly .. is this configuration possible ?? > > > This is not a valid topology "if" the lines connecting > > > them is serial links. If so put B into the same are by > > > saying: > > > router isis > > > net 12 > > > net 11 > > > > > > If you want to the the following with an ethernet... > > > > > > B (11) > > > | > > > ------------- > > > | | > > > A(12) C(12) > > > > > > Then this works as long as either A or C is L1/L2 and > > > B is L2. > > > > > > A and C will create a L1 adjacency. > > Can i have L1 adjaceny between ISs in differet areas ! > How !?!?! > > AFAIK i mentioned that A & B are in the same area while C is in some other > area. > > > > C and B will create a L2 adjacency. > > I think you got the routers wrong ! > Your figure above says that B is L1 then how can it have L2 adjaceny with B > ??? > > > > If A wants to send a packet to B then the router will > > > be A-to-C-to-B... following the L2 route. > > Why A and B are in same areas .. !?!? > > I think you had smthg else in mind and you have written something else .. > could you please check that ! > > Regards, > Swati > > > > > > > > A will pick C because C having the adjacency with B will > > > have access to external areas. Then the L1 instance on > > > C will set the ATT bit telling A that C has a path. > > > During SPF time A will set C as the next hop out to forward > > > packets outside the area. > > > > > > > Secondly .. B and C are in different areas so how does the adjaceny go > > up ?? > > > The adjacency in this case will not come up. > > > A and C are L1 in area 11. B is in 12. > > > No level 1 adjacency because they must be in the same area. > > > No level 2 because only B is level 2. > > > If you change, say C, to be L1/L2 then there will be > > > an adjacency between B & C. A will be black holed. Alone > > > and unreachable. > > > > > > > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > > > > thought that B should then be L1/L2 > > > See above. > > > > > > Mike > > > > > > > > > > > > > > I know i am being miserable .. but please help! > > > > > > > > Thanks in advance .. > > > > > > > > Swati > > > > > > > > ----- Original Message ----- > > > > From: "Mike Truskowski" > > > > To: "stefano previdi" > > > > Cc: ; > > > > Sent: Thursday, August 09, 2001 7:25 PM > > > > Subject: Re: [Isis-wg] Area Architecture > > > > > > > > > > > > > Swati, > > > > > First of all you are discussing the actions of a protocol > > > > > and trying to relate them to how a router is configured. > > > > > This is hard to do..... > > > > > > > > > > Consider a processor with I/O ports attached. > > > > > > > > > > For OSPF, when the processor runs OSPF each I/O port > > > > > must be told that it is running OSPF and "which" area > > > > > it is in. > > > > > > > > > > For ISIS, when the processor runs ISIS it is given > > > > > an area address by default within the NET. Now > > > > > when an I/O port is enabled for ISIS they belong > > > > > to the same area as the processor or instance of ISIS > > > > > > > > > > Consider a simple example using 1 NET. > > > > > So with a router... you configure the router to > > > > > start ISIS by saying "router isis" but you also > > > > > must tell this router his NET. > > > > > > > > > > router isis > > > > > net 490001xxxxssssss00 > > > > > > > > > > Now when you enable an interface the interface is in > > > > > this area by default....490001xxxx. > > > > > > > > > > mike > > > > > > > > > > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > > > > >Hi, > > > > > > >In OSPF it is said that the areas are bound to the interfaces and > > that > > > > the > > > > > > >OSPF area boundaries fall within a router. This statement is not > > very > > > > clear > > > > > > >and it gets more confusing when its said that in ISIS, area > > boundaries > > > > is on > > > > > > >a link rather than in the router. > > > > > > > > > > > > this because the router itself is configured as part of one area. > > > > > > What you did in your example below is that you forced (through > some > > > > > > interface configuration commands) the router to establish a > specific > > > > > > adjacency level. But this doesn't mean that the router is part of > > > > > > more areas. The router is still part of one area. > > > > > > > > > > > > s. > > > > > > > > > > > > > > > > > > >What is bothering me is the fact that in > > > > > > >ISIS also its only on the interface basis that i say that the > > > > particular > > > > > > >link is L1 or L2. > > > > > > >Let me explain . . > > > > > > >A, B are both cisco routers > > > > > > > > > > > > > >A --------------------- B > > > > > > >(L1/L2) (L1) > > > > > > > > > > > > > >A and B are both in the same area > > > > > > > > > > > > > >Configuration of router A would be > > > > > > > > > > > > > >interface loopback0 > > > > > > >ip address 192.168.1.1 255.255.255.255 > > > > > > >! > > > > > > >interface Pos2/0/0 > > > > > > >ip address 192.168.16.1 255.255.255.0 > > > > > > >ip router isis > > > > > > >isis circuit-type-level-2 > > > > > > >! > > > > > > >Fastethernet4/0/0 > > > > > > >ip address 192.168.11.1 255.255.255.0 > > > > > > >ip router isis > > > > > > >isis circuit-type-level-1 > > > > > > >! > > > > > > >router isis > > > > > > >net 49.0001.1921.6800.1001.00 > > > > > > > > > > > > > >(1) If we look at the profile definition then here also we have > > defined > > > > the > > > > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my > > L2 > > > > while > > > > > > >192.168.11/24 is L1. > > > > > > >(2) Will all of the LSPs recvd on any one of the interfaces be > > known to > > > > the > > > > > > >other ? > > > > > > > > > > > > > >Router configuration of Router B > > > > > > > > > > > > > >interface loopback0 > > > > > > >ip address 192.168.1.2 255.255.255.255 > > > > > > >! > > > > > > >interface Fastethernet0/0 > > > > > > >ip address 192.168.11.2 255.255.255.0 > > > > > > >ip router isis > > > > > > >isis circuit-type-level-1 > > > > > > >! > > > > > > >router isis > > > > > > >net 49.0001.1921.6800.1002 > > > > > > > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are > running > > L1 > > > > level > > > > > > >routing .. So is ISIS not interface based ?? > > > > > > > > > > > > > >Please explain . . > > > > > > > > > > > > > >Regards, > > > > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > > > > >Do You Yahoo!? > > > > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > > > >_______________________________________________ > > > > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > _______________________________________________ > > > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > > > > > > > > > _________________________________________________________ > > > > Do You Yahoo!? > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 12:29:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29476 for ; Thu, 9 Aug 2001 12:29:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96970; Thu, 9 Aug 2001 09:36:26 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA96953 for ; Thu, 9 Aug 2001 09:35:15 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id JAA22658; Thu, 9 Aug 2001 09:27:39 -0700 (PDT) From: Mike Truskowski Message-Id: <200108091627.JAA22658@diablo.cisco.com> Subject: Re: [Isis-wg] Area Architecture To: swatirstogi@yahoo.com (Swati Rastogi) Cc: truskows@cisco.com, isis-wg@spider.juniper.net In-Reply-To: <00d601c120e3$b3f24a70$da046c6b@Manav>; from "Swati Rastogi" at Aug 9, 101 7:54 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 9:27:39 PDT Swati, Second try ... here goes with your topology below. > > Mike, > If this is so then I am having problems visualizing as to how we can assign > multiple addresses to an IS. For i always thought that area addresses are > assigned per interface basis. > There is this line in the rfc 1195 which says .. "A level 1 router will > refuse to become a neighbor with a node whose area addresses do not overlap > its area address." This creates a confusion too .. Consider the topology as > shown below. > > A ----- B ------ C > (l1) (l2) (l1) L1 L2 L1 > > A & B are in the same area while C is in a different area. > A and C are L1 routers and B is an L2 only. > > Firstly .. is this configuration possible ?? It is possible but will not work. L1 adjacencies are separate from L2 adjacencies. So A and B need a L1 adj. but can not because B is not L1. C can not talk to B because they are in different areas and they need a L2 adj. So C needs to be L1/L2. This works: A--------B-----------C area 1 1 2 L1 L1/L2 L2/L1 > Secondly .. B and C are in different areas so how does the adjaceny go up ?? It does not. C must be L2. They there will be only a L2 adj. No L1 adj. > Thirdly .. A is a L1 router while B is L2 .. Can they communicate .. I > thought that B should then be L1/L2 B must be L1/L2 for A to talk to it. The discussion I had before was actually more detailed but the topology was also different. Match the discussion with the topology I replied with and you will have a couple of scenarios to play iwth. Mike > > I know i am being miserable .. but please help! > > Thanks in advance .. > > Swati > > ----- Original Message ----- > From: "Mike Truskowski" > To: "stefano previdi" > Cc: ; > Sent: Thursday, August 09, 2001 7:25 PM > Subject: Re: [Isis-wg] Area Architecture > > > > Swati, > > First of all you are discussing the actions of a protocol > > and trying to relate them to how a router is configured. > > This is hard to do..... > > > > Consider a processor with I/O ports attached. > > > > For OSPF, when the processor runs OSPF each I/O port > > must be told that it is running OSPF and "which" area > > it is in. > > > > For ISIS, when the processor runs ISIS it is given > > an area address by default within the NET. Now > > when an I/O port is enabled for ISIS they belong > > to the same area as the processor or instance of ISIS > > > > Consider a simple example using 1 NET. > > So with a router... you configure the router to > > start ISIS by saying "router isis" but you also > > must tell this router his NET. > > > > router isis > > net 490001xxxxssssss00 > > > > Now when you enable an interface the interface is in > > this area by default....490001xxxx. > > > > mike > > > > > > > > At 08:26 09/08/2001, Swati Rastogi wrote: > > > >Hi, > > > >In OSPF it is said that the areas are bound to the interfaces and that > the > > > >OSPF area boundaries fall within a router. This statement is not very > clear > > > >and it gets more confusing when its said that in ISIS, area boundaries > is on > > > >a link rather than in the router. > > > > > > this because the router itself is configured as part of one area. > > > What you did in your example below is that you forced (through some > > > interface configuration commands) the router to establish a specific > > > adjacency level. But this doesn't mean that the router is part of > > > more areas. The router is still part of one area. > > > > > > s. > > > > > > > > > >What is bothering me is the fact that in > > > >ISIS also its only on the interface basis that i say that the > particular > > > >link is L1 or L2. > > > >Let me explain . . > > > >A, B are both cisco routers > > > > > > > >A --------------------- B > > > >(L1/L2) (L1) > > > > > > > >A and B are both in the same area > > > > > > > >Configuration of router A would be > > > > > > > >interface loopback0 > > > >ip address 192.168.1.1 255.255.255.255 > > > >! > > > >interface Pos2/0/0 > > > >ip address 192.168.16.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-2 > > > >! > > > >Fastethernet4/0/0 > > > >ip address 192.168.11.1 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1001.00 > > > > > > > >(1) If we look at the profile definition then here also we have defined > the > > > >areas on the interfaces basis .. saying that 192.168.16/24 is my L2 > while > > > >192.168.11/24 is L1. > > > >(2) Will all of the LSPs recvd on any one of the interfaces be known to > the > > > >other ? > > > > > > > >Router configuration of Router B > > > > > > > >interface loopback0 > > > >ip address 192.168.1.2 255.255.255.255 > > > >! > > > >interface Fastethernet0/0 > > > >ip address 192.168.11.2 255.255.255.0 > > > >ip router isis > > > >isis circuit-type-level-1 > > > >! > > > >router isis > > > >net 49.0001.1921.6800.1002 > > > > > > > >(1) Here on the 192.168.1/24 interface both the routers are running L1 > level > > > >routing .. So is ISIS not interface based ?? > > > > > > > >Please explain . . > > > > > > > >Regards, > > > >Swati > > > > > > > > > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 13:15:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00594 for ; Thu, 9 Aug 2001 13:15:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97339; Thu, 9 Aug 2001 10:22:25 -0700 (PDT) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by external.juniper.net (8.9.3/8.9.3) with SMTP id KAA97327 for ; Thu, 9 Aug 2001 10:21:07 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 17:13:30 -0000 X-Apparently-From: Message-ID: <005e01c120f7$24a6d9d0$da046c6b@Manav> From: "Swati Rastogi" To: "Micah Bartell" Cc: "Mike Truskowski" , "isis-wg" References: <200108091355.GAA25129@diablo.cisco.com> <4.3.2.7.2.20010809110059.02d03cc0@cactus.cisco.com> Subject: Re: [Isis-wg] Area Architecture MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 22:46:42 +0530 Content-Transfer-Encoding: 7bit > >If this is so then I am having problems visualizing as to how we can assign > >multiple addresses to an IS. For i always thought that area addresses are > >assigned per interface basis. > > NSAP's are applied per node, while IP addresses are applied per interface. > > If we assign multiple NSAP's to a single node, that "area" is actually the > union of those area addresses. Can you please expound on the above point .. As i understand node refers to an IS .. Are you implying that one IS can be in multiple areas ?? Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 13:26:51 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00863 for ; Thu, 9 Aug 2001 13:26:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97425; Thu, 9 Aug 2001 10:31:30 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by external.juniper.net (8.9.3/8.9.3) with SMTP id KAA97413 for ; Thu, 9 Aug 2001 10:30:04 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 Aug 2001 17:22:12 -0000 X-Apparently-From: Message-ID: <006901c120f8$6000adc0$da046c6b@Manav> From: "Mareline Sheldon" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Levels and adjacencies Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 22:55:33 +0530 Content-Transfer-Encoding: 7bit Hi everybody, I am Mareline Sheldon and am new to this mailing list. I was looking around the mail archieves and was glad that i found some because what is being discussed here is exactly what i am looking for .. Here i go .. Say i am a L1/L2 router and i have a L1 adjacency with router A and L2 adjaceny with router B. I will in principle then be only flooding L1 LSPs to A and L2 LSPs to B. And if i have a L1/L2 adjacency with IS C .. then i shall be flooding both ?? True ?? But i have a feeling .. that i cant have L1/L2 adjaceny with some IS ?? /mary -- Nipon Datacom _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 13:31:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01057 for ; Thu, 9 Aug 2001 13:31:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97499; Thu, 9 Aug 2001 10:37:27 -0700 (PDT) Received: from usa04.ambernetworks.com ([63.121.148.133]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97465 for ; Thu, 9 Aug 2001 10:36:35 -0700 (PDT) Received: by usa04.ambernetworks.com with Internet Mail Service (5.5.2653.19) id <3ZYG82Q7>; Thu, 9 Aug 2001 10:27:04 -0700 Message-ID: <9F4704BE89F7D4118A0F0002B328C36CA0F68B@usa04.ambernetworks.com> From: Anand Ammundi To: "'Manav Bhatia'" , sudhir dskjf , Micah Bartell Cc: isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Routing or forwarding MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 10:27:03 -0700 A routing protocol is part of the control plane...it merely provides the required information to the data plane for the forwarding to take place. As far as getting the control packets themselves across, since IS-IS (and OSPF for that matter) are not sending out their PDU's beyond 1 hop, the receiving peer will know to send the PDU up the stack to ISIS based on the protocol ID's (0xFEFE or 0x0021 etc)...actually, it is not really a "taken for granted" thing...for example, say over a POS link, you have 2 different PDU's ... 1) PPP-IP 2) PPP-ISIS assuming that software forwarding is a thing of the past, in case 1) the data plane will make a forwarding decision based on the DST_ADDR and either send it to CPU or forward it directly...for case 2), there explicitly has to be special handling in the data plane, to send this to CPU (stack) as a terminating packet...note that this handling is implicitly taken care of for say OSPF or BGP since they are on top of IP. hope this answers your question anand ps: Though I don't think the spec has anything against ISIS running over IP, but I doubt if there are any such implementations on the field. -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Thursday, August 09, 2001 9:22 AM To: sudhir dskjf; Micah Bartell Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Routing or forwarding I think what Sudhir meant was that if IS-IS just performs the routing functions then who forwards these packets (ISIS) to the underlying network .. since it is not supposed to be running on top of any networking layer protocol ! Manav ----- Original Message ----- From: "Micah Bartell" To: "sudhir dskjf" Cc: Sent: Thursday, August 09, 2001 9:29 PM Subject: Re: [Isis-wg] Routing or forwarding > Or are you talking about IS-IS fowarding LSP's? Because IS-IS runs > directly over the data link, it would not make use of CLNS or IP for it's > forwarding. Some other protocols do make use of other L3 protocols for > forwarding routing information, such as OSPF making use of IP. > > Is this what you were looking for? > > /mpb > > At 10:20 08/09/2001 +0100, sudhir dskjf wrote: > >hi all, > >The Dual Is-Is performs routing i.e to calculate the > >optimal path or it forwards packets also? > >I have this doubt because i read that the IS-IS uses > >the services of the data link directly. Can a routing > >protocol make use of a lower layer services or the > >Is-IS protocol makes use of CLNP or Ip for forwarding. > > > >thanks in advance > >srikrishna > > > >____________________________________________________________ > >Do You Yahoo!? > >Send a newsletter, share photos & files, conduct polls, organize chat > >events. Visit http://in.groups.yahoo.com. > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 13:35:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01115 for ; Thu, 9 Aug 2001 13:35:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97545; Thu, 9 Aug 2001 10:41:27 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97528 for ; Thu, 9 Aug 2001 10:40:32 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f79HWfO08856; Thu, 9 Aug 2001 13:32:41 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAJ07650; Thu, 9 Aug 2001 13:32:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809115859.00baeb10@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: Jeff Learman Subject: RE: [Isis-wg] OSI ?? Cc: , "Swati Rastogi" In-Reply-To: References: <4.3.2.7.2.20010808141857.01dc2c78@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 12:29:14 -0400 At 10:47 AM 8/9/2001, Ken Larmer wrote: >Thanks for all the corrections :^) > >I have a very bad habit of calling all OSI packets CLNP, when they are >clearly not! Furthermore, I apologize if I miss-represented the evolution of >OSI! > >Just a couple of comments and I'll fade away! > >Jeff, I believe you meant to say X.25 over ethernet is LLC2 not LLC3. Please >correct me if I'm wrong. BTW, Digital had a lot of customers running this >hack. OOPS! You're right, LLC2 is connection-oriented LLC. LLC3 was from MAP (GM's manufacturing automation protocol). >I also realize you can run IS-IS over a X.25 PVC on one IS-IS implementation >I know of. My comment was simply stating that this is not a common practice. You can also run it over an SVC, as long as it is statically assigned, rather than than one that comes up and goes down >Jeff, please help me here, I made the following statement: > >>Now, how does this tie into CLNP (Connection-Less Network Protocol) and the >>format of OSI packets? Well, both CONS and CLNS networks transfer OSI data >>in CLNP packet formats. > >Your response: > >>False. The protocol used to provide CONS is X.25, and involves >>no CLNP packets. CLNP can operate over X.25, but CONS is not involved. > >What is the format? CONS is used establish the connection and IS-IS does the >forwarding. I know I didn't state that, but is that true? IS-IS never does forwarding. It's just a routing protocol, which derives routing information for the use of the network layer data protocol, which forwards the data. IS-IS was designed for use with CLNP, and then extended for use with IP. It has never been standardized for use with CONS. CONS itself, like CLNS itself, is an abstract service definition and does not impose a protocol. There are other specifications that state how to provide CONS using X.25 as a network access protocol. (The actual network delivery protocol and routing protocols for X.25 are not standard, because it's the X.25 service provider's job -- in this case the X.25 service provider is a company or national organization. They can do whatever they want, as long as they provide a service that can be interfaced to using X.25.) >Jeff, please help me here, I made the following statement: > >>On a CLNS Ethernet network, OSI packets are exchanged using IEEE 802.3 >>formatted ethernet frames. The data portion of an IEEE 802.3 frame, which >is >>carrying OSI data, must have as its first octet a value of 128 (81 hex) = >>OSI data packet, 129 (82 hex) ES-IS control packet or 130 (83 hex) IS-IS >>control packet. This first octet is referred to as the NLPID (Network Layer >>Protocol Identifier) for ES-IS and OSI data and error packets and as IRPD >>(Intradomain Routing Protocol Discriminator) for IS-IS control packets. > >Your response: > >>IDRP is the inTER-domain routing protocol, not inTRA-domain, which is >>IS-IS. IDRP serves the same role as BGP does for IP, and like BGP is >>a distance-vector protocol, not a link-state protocol. > >Jeff, did you mean IDRPI (Inter-Domain Routing Protocol Information) from >RFC 1195. My statement refers to ISO-10589 control packets, the first octet >of which is the IRPD (Intradomain Routing Protocol Discriminator)field. Of >course, we could throw another 1,000 acronyms into OSI so it would be a bit >more confusing. No, I wasn't referring to IDRPI. IDRP stands for "Interdomain Routeing Protocol", which is like BGP. The first octet of an OSI connectionless network layer protocol packet isthe NLPI, "Network layer protocol ID", aka NPID or NLPID. I don't recall an IRPD (I thought that was a transposition on your part), so my response was non-sequitur. Where is that IRDP defined? >I believe that this open discussion is good for this working group. Much to >often I see questions go unanswered because many folks do not have all the >right answers or the ones that do are too busy to respond. I would rather >see this type of discussion, than have a bunch of folks who are to afraid to >respond because they may get some portion of their response wrong. This >stuff is extremely complex and needs many minds to get the facts 100% >correct. > >Just my thoughts! > >Cheers, >Ken _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 13:52:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01507 for ; Thu, 9 Aug 2001 13:52:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA97703; Thu, 9 Aug 2001 11:00:26 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA97685 for ; Thu, 9 Aug 2001 10:59:20 -0700 (PDT) Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA05956; Thu, 9 Aug 2001 10:51:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20010809125054.02184ae8@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: Micah Bartell Subject: Re: [Isis-wg] Area Architecture Cc: "Mike Truskowski" , "isis-wg" In-Reply-To: <005e01c120f7$24a6d9d0$da046c6b@Manav> References: <200108091355.GAA25129@diablo.cisco.com> <4.3.2.7.2.20010809110059.02d03cc0@cactus.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 12:51:33 -0500 No, I am saying that an area can have multiple area addresses. /mpb At 22:46 08/09/2001 +0530, Swati Rastogi wrote: > > >If this is so then I am having problems visualizing as to how we can >assign > > >multiple addresses to an IS. For i always thought that area addresses are > > >assigned per interface basis. > > > > NSAP's are applied per node, while IP addresses are applied per interface. > > > > If we assign multiple NSAP's to a single node, that "area" is actually the > > union of those area addresses. > >Can you please expound on the above point .. >As i understand node refers to an IS .. Are you implying that one IS can be >in multiple areas ?? > >Regards, >Swati > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 14:04:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01691 for ; Thu, 9 Aug 2001 14:04:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA97816; Thu, 9 Aug 2001 11:11:26 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id LAA97804 for ; Thu, 9 Aug 2001 11:10:26 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id OAA02029; Thu, 9 Aug 2001 14:02:42 -0400 Message-ID: <3B72D042.A8FD5308@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mareline Sheldon CC: isis-wg , tgol@laurelnetworks.com Subject: Re: [Isis-wg] Levels and adjacencies References: <006901c120f8$6000adc0$da046c6b@Manav> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 09 Aug 2001 14:02:42 -0400 Content-Transfer-Encoding: 7bit Mareline Sheldon wrote: > Hi everybody, > I am Mareline Sheldon and am new to this mailing list. I was looking around > the mail archieves and was glad that i found some because what is being > discussed here is exactly what i am looking for .. Here i go .. > > Say i am a L1/L2 router and i have a L1 adjacency with router A and L2 > adjaceny with router B. I will in principle then be only flooding L1 LSPs to > A and L2 LSPs to B. That is true. > > And if i have a L1/L2 adjacency with IS C .. then i shall be flooding both > ?? > > True ?? > You can have L1/L2 adjacency with a router over a point to point link if both levels are enabled on both routers' interfaces ( and an area address in common for L1 ) and in this case you will be flooding both L1 and L2 LSPs. For multiaccess links, there will be a seperate adjacency per enabled level. Hope this helps... Tayfun Gol > > > But i have a feeling .. that i cant have L1/L2 adjaceny with some IS ?? > > /mary > > -- > Nipon Datacom > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 14:45:15 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02674 for ; Thu, 9 Aug 2001 14:45:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA98056; Thu, 9 Aug 2001 11:51:25 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA98044 for ; Thu, 9 Aug 2001 11:50:11 -0700 (PDT) Received: (qmail 67835 invoked from network); 9 Aug 2001 18:42:34 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Aug 2001 18:42:34 -0000 From: "Ken Larmer" To: "Jeff Learman" Cc: , "Swati Rastogi" Subject: RE: [Isis-wg] OSI ?? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.3.2.7.2.20010809115859.00baeb10@dingdong.cisco.com> Importance: Normal Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 14:44:23 -0400 Content-Transfer-Encoding: 7bit Sorry Jeff, I just have a couple more questions? > IS-IS never does forwarding. It's just a routing protocol, which > derives routing information for the use of the network layer data > protocol, which forwards the data. Jeff, please help me out here, I am really confused! You stated that IS-IS never does forwarding. I understand that it never does forwarding of IP packets, but what about CLNP, does this still hold true? > IS-IS was designed for use with CLNP, and then extended for use with > IP. It has never been standardized for use with CONS. Jeff, ISO-10589 states the following, which I thought pertained to CONS circuits? Please help to clear this up for me??? ISO 8208 subnetworks 8.3.1 Network layer protocols The way in which the underlying service assumed by ISO 8473 is provided for ISO 8208 subnetworks is described in clause 8 of ISO 8473. This defines a set of Subnetwork Dependent Convergence Functions (SNDCFs) that relate the service provided by specific individual ISO International Standard subnetworks to the abstract "underlying service" defined in 5.5 of ISO 8473. In particular 8.4.3 describes the Subnetwork Dependent Convergence Functions used with ISO 8208 Subnetworks. Use of ISO 8473 subnetwork dependent convergence functions SVCs shall be established according to the procedures defined in the ISO 8208 Subnetwork Dependent Convergence Functions of ISO 8473 (this may be on system management action or on arrival of data depending on the type of circuit). The Call Request shall contain a Protocol Discriminator specifying ISO 8473 in the first octet of Call Userdata. > No, I wasn't referring to IDRPI. IDRP stands for "Interdomain Routeing > Protocol", which is like BGP. The first octet of an OSI connectionless > network layer protocol packet isthe NLPI, "Network layer protocol ID", aka > NPID or NLPID. I don't recall an IRPD (I thought that was a transposition > on your part), so my response was non-sequitur. Where is that > IRDP defined? Jeff, are you talking about the DSAP/SSAP of an IEEE 802.3 packet? The IDRP (83) is what identifies an IS-IS packet within an IEEE 802.3 ethernet frame. Cheers, Ken _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 9 17:59:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06336 for ; Thu, 9 Aug 2001 17:59:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA98931; Thu, 9 Aug 2001 15:06:26 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA98919 for ; Thu, 9 Aug 2001 15:05:39 -0700 (PDT) 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 OAA03346; Thu, 9 Aug 2001 14:57:51 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 14:57:51 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A5ED@avalon.pluris.com> From: Les Ginsberg To: "'Ken Larmer'" , Jeff Learman Cc: isis-wg@spider.juniper.net, Swati Rastogi Subject: RE: [Isis-wg] OSI ?? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 9 Aug 2001 14:57:48 -0700 > > No, I wasn't referring to IDRPI. IDRP stands for > "Interdomain Routeing > > Protocol", which is like BGP. The first octet of an OSI > connectionless > > network layer protocol packet isthe NLPI, "Network layer > protocol ID", aka > > NPID or NLPID. I don't recall an IRPD (I thought that was > a transposition > > on your part), so my response was non-sequitur. Where is that > > IRDP defined? > > Jeff, are you talking about the DSAP/SSAP of an IEEE 802.3 > packet? The IDRP > (83) is what identifies an IS-IS packet within an IEEE 802.3 > ethernet frame. > What Jeff is referring to here is: [IS10747] ISO/IEC IS 10747 - Information Processing Systems - Telecommunications and Information Exchange between Systems - Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993. This was OSI's version of an Inter-Domain routing protocol - referred to as IDRP. It was assigned NLPID 0x84 for its PDUs. BGP4 used this an a reference in its development. I don't believe there is any active work on IDRP - but I could be mistaken there. Other folks are undoubtedly more knowledgeable on that score. In terms of an 802.3 packet, an OSI frame - which includes CLNP, ES-IS, and IS-IS PDUs will have the following format: Destination MAC address: 6 bytes Source MAC address: 6 bytes Length: 2 bytes LLC1 Header 3 bytes consisting of: DSAP: 0xFE SSAP: 0xFE Type: 0x3 (Unnumbered Information) Following these 17 bytes will be the start of the payload (or NPDU). The first byte of that payload will be the NLPID of the PDU which is used to identify the protocol: 0x81 CLNS 0x82 ES-IS 0x83 IS-IS 0x84 IDRP Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 00:59:24 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12500 for ; Fri, 10 Aug 2001 00:59:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA00715; Thu, 9 Aug 2001 22:06:26 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id WAA00703 for ; Thu, 9 Aug 2001 22:05:20 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Aug 2001 04:57:39 -0000 X-Apparently-From: Message-ID: <00b701c12159$82d704a0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] NSAP Structure Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 10:25:44 +0530 Content-Transfer-Encoding: 7bit Hi, The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) gives the length of system Identifier to be varying from 1-8 octets. The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into 6 octets in my IS-IS PDUs ?? Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 02:40:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29738 for ; Fri, 10 Aug 2001 02:40:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA01158; Thu, 9 Aug 2001 23:47:25 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by external.juniper.net (8.9.3/8.9.3) with SMTP id XAA01146 for ; Thu, 9 Aug 2001 23:46:49 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Aug 2001 06:39:07 -0000 X-Apparently-From: Message-ID: <004101c12167$af70fc10$da046c6b@Manav> From: "Mareline Sheldon" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Manual Adjacencies Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 12:12:45 +0530 Content-Transfer-Encoding: 7bit The RFC 1142 (7.3.3.1) says "NOTE - Manual End system Adjacencies shall not be included in a level 1 LSPs issued on behalf of a pseudonode, since that would presuppose that all Intermediate systems on a broadcast subnetwork had the same set of manual adjacencies as defined in the ciruit" This is not very clear .. if it is not done so then how do manual adjacencies get advertised on a psedonode ? Please help! /Mary _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 06:22:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02725 for ; Fri, 10 Aug 2001 06:22:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA02263; Fri, 10 Aug 2001 03:30:26 -0700 (PDT) Received: from mailweb24.rediffmail.com ([203.199.83.148]) by external.juniper.net (8.9.3/8.9.3) with SMTP id DAA02248 for ; Fri, 10 Aug 2001 03:29:56 -0700 (PDT) Received: (qmail 7653 invoked by uid 510); 10 Aug 2001 10:23:04 -0000 Message-ID: <20010810102304.7652.qmail@mailweb24.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 10 Aug 2001 10:23:04 -0000 MIME-Version: 1.0 To: From: "Selvam Murugesan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: quoted-printable Subject: [Isis-wg] doubts on IS-IS topology and addressing Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 10 Aug 2001 10:23:04 -0000 Content-Transfer-Encoding: quoted-printable Hi, I need a small clarification on the IS-IS topology and addressing form= ats. = 1. Is it must for Level-1 IS to have a adjacency maintained with a Level-= 2 IS or can the Level-1 IS communicate with a Level-2 IS via Level-1 IS? 2.Regarding the ISO DCC addressing format adopted for Is-IS addresses usi= ng semi-octet decimal digits representation, the DSP is allocated 0-35 di= gits. Assuming CFI =3D1 (single digit), then CDI =3D 3digits,ESI =3D 31 d= igits, which adds up the total digits in the DSP to 35 digits. How is SEL= field of the DSP accomodated in this case? Kindly help me on this reagrds Thanks in advance Regards Manigandan _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 07:02:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03450 for ; Fri, 10 Aug 2001 07:02:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA02447; Fri, 10 Aug 2001 04:09:25 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by external.juniper.net (8.9.3/8.9.3) with SMTP id EAA02435 for ; Fri, 10 Aug 2001 04:08:46 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Aug 2001 11:01:03 -0000 X-Apparently-From: Message-ID: <014801c1218c$46aaeef0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: , "Selvam Murugesan" References: <20010810102304.7652.qmail@mailweb24.rediffmail.com> Subject: Re: [Isis-wg] doubts on IS-IS topology and addressing Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 16:33:56 +0530 Content-Transfer-Encoding: 7bit >1. Is it must for Level-1 IS to have a adjacency maintained with a >Level-2 IS or can the Level-1 IS communicate with a Level-2 IS via >Level-1 IS? When a L1 IS receives a packet, it examines the destination address in the network layer header. If its within its area then routes based on the ID portion of the address. Otherwise, the IS forwards the packet to the closest level 2 IS and if an entry does not exist for it then the packet is either dropped or forwarded to some default IS designated for such purposes. Thus a level 1 IS can communicate with a level 2 IS via a level 1 IS acting as a gateway to the "last resort" ! -- manav _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 10:10:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05177 for ; Fri, 10 Aug 2001 10:09:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA03269; Fri, 10 Aug 2001 07:16:26 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA03256 for ; Fri, 10 Aug 2001 07:15:30 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Anand Ammundi'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] Routing or forwarding 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 10:07:37 -0400 > ps: Though I don't think the spec has anything against ISIS > running over IP, but I doubt if there are any such > implementations on the field. A bit of history on this... There -was- a draft proposal to run ISIS over IP. A number of reasons were put forward for this, including allowing larger LSPs (let IP handle fragmentation) and avoiding something refered to as the "ATM cell tax" that came about if you needed to multiplex two protocols over ATM, and the resulting effect of requiring two ATM cells to hols a TCP Ack. There were folks who implemented this encapsulation. The chief driving force for seemed to be avoiding the cell tax: there were doubts that adding a second layer of fragmentation was a good thing. An alternative proposal to deal with the cell tax was proposed which encodes both IP and ISIS traffic "raw", and demultiplexes based on the difference between the first nibble of the NLPID for ISIS (0x8) and the version number for IP (0x4 or 0x6). This proposal seems to have aged off the list, but gathered support from several vendors. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 10:59:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05810 for ; Fri, 10 Aug 2001 10:59:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03521; Fri, 10 Aug 2001 08:06:26 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03504 for ; Fri, 10 Aug 2001 08:05:26 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7AEvUO26873; Fri, 10 Aug 2001 10:57:31 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAN06757; Fri, 10 Aug 2001 10:57:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20010810103859.099300d0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Mareline Sheldon" From: Jeff Learman Subject: Re: [Isis-wg] Manual Adjacencies Cc: "isis-wg" In-Reply-To: <004101c12167$af70fc10$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 10:49:16 -0400 First, don't rely on RFC 1142, which is a DRAFT standard. There were changes to it before it became ISO 10589, which is what you need to implement. However, this text didn't change -- manual adjacencies must be placed in the LSP of the system that the manual adjacency is configured on, not in the pseudonode LSP. Jeff At 02:42 AM 8/10/2001, Mareline Sheldon wrote: >The RFC 1142 (7.3.3.1) says "NOTE - Manual End system Adjacencies shall not >be included in a level 1 LSPs issued on behalf of a pseudonode, since that >would presuppose that all Intermediate systems on a broadcast subnetwork had >the same set of manual adjacencies as defined in the ciruit" > >This is not very clear .. if it is not done so then how do manual >adjacencies get advertised on a psedonode ? > >Please help! > >/Mary > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:00:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05851 for ; Fri, 10 Aug 2001 11:00:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03540; Fri, 10 Aug 2001 08:07:54 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03509 for ; Fri, 10 Aug 2001 08:05:28 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7AEvVO26878; Fri, 10 Aug 2001 10:57:31 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-121.cisco.com [64.102.83.121]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAN06756; Fri, 10 Aug 2001 10:57:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20010810102634.01e98e18@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manav Bhatia" From: Jeff Learman Subject: Re: [Isis-wg] NSAP Structure Cc: In-Reply-To: <00b701c12159$82d704a0$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 10:50:29 -0400 Friends don't let friends use 8-byte system IDs ;-) RFC 1142 is the draft standard. One of the wonderful things that the ISO committee did was to permit the system ID to be 1-8 bytes, making our lives more enjoyable and increasing employment security for software engineers. The ID size must be constant throughout a routing domain. You need to implement ISO 10589, not the draft standard. Regards, Jeff At 12:55 AM 8/10/2001, Manav Bhatia wrote: >Hi, >The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) >gives the length of system Identifier to be varying from 1-8 octets. >The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into >6 octets in my IS-IS PDUs ?? > >Regards, >Manav Bhatia > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:07:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05949 for ; Fri, 10 Aug 2001 11:07:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03616; Fri, 10 Aug 2001 08:14:26 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03603 for ; Fri, 10 Aug 2001 08:13:26 -0700 (PDT) Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA15252; Fri, 10 Aug 2001 08:05:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20010810100359.02c37b98@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Learman From: Micah Bartell Subject: Re: [Isis-wg] NSAP Structure Cc: "Manav Bhatia" , In-Reply-To: <4.3.2.7.2.20010810102634.01e98e18@dingdong.cisco.com> References: <00b701c12159$82d704a0$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 10:05:40 -0500 To the best of my knowledge, no one has implemented anything but 6 byte systemID's. Also, the sourceID is systemID Length +1. Area addresses however are implemented variable length. /mpb At 10:50 08/10/2001 -0400, Jeff Learman wrote: >Friends don't let friends use 8-byte system IDs ;-) > >RFC 1142 is the draft standard. One of the wonderful things that >the ISO committee did was to permit the system ID to be 1-8 bytes, >making our lives more enjoyable and increasing employment security >for software engineers. The ID size must be constant throughout >a routing domain. > >You need to implement ISO 10589, not the draft standard. > >Regards, >Jeff > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > >Hi, > >The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) > >gives the length of system Identifier to be varying from 1-8 octets. > >The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into > >6 octets in my IS-IS PDUs ?? > > > >Regards, > >Manav Bhatia > > > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > > > > > >_________________________________________________________ > >Do You Yahoo!? > >Get your free @yahoo.com address at http://mail.yahoo.com > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:14:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06029 for ; Fri, 10 Aug 2001 11:14:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03677; Fri, 10 Aug 2001 08:20:26 -0700 (PDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA03662 for ; Fri, 10 Aug 2001 08:19:38 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Aug 2001 15:11:54 -0000 X-Apparently-From: Message-ID: <02ee01c121af$517a5690$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Jeff Learman" , "Micah Bartell" Cc: References: <00b701c12159$82d704a0$da046c6b@Manav> <4.3.2.7.2.20010810100359.02c37b98@cactus.cisco.com> Subject: Re: [Isis-wg] NSAP Structure Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 20:45:35 +0530 Content-Transfer-Encoding: 7bit > To the best of my knowledge, no one has implemented anything but 6 byte > systemID's. But its defined in the RFC .. so there is no garuntee that all systems IDs will fall under 6 bytes ! > > Also, the sourceID is systemID Length +1. Is the +1 for the SEL byte ?? I dont think the SEL byte is included in defining the unique ID of the IS i.e. Source ID ! > > Area addresses however are implemented variable length. Area addresses may computed as (total length - (system ID +1) ) I read it somewhere but its not exactly flashing me where .. Manav > > /mpb > > > At 10:50 08/10/2001 -0400, Jeff Learman wrote: > > >Friends don't let friends use 8-byte system IDs ;-) > > > >RFC 1142 is the draft standard. One of the wonderful things that > >the ISO committee did was to permit the system ID to be 1-8 bytes, > >making our lives more enjoyable and increasing employment security > >for software engineers. The ID size must be constant throughout > >a routing domain. > > > >You need to implement ISO 10589, not the draft standard. > > > >Regards, > >Jeff > > > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > > >Hi, > > >The general structure of the NSAP structure as defined in RFC 1629 (6.2.1) > > >gives the length of system Identifier to be varying from 1-8 octets. > > >The length of the source ID for all the IS-IS PDUs as given in the rfc 1142 > > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this into > > >6 octets in my IS-IS PDUs ?? > > > > > >Regards, > > >Manav Bhatia > > > > > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > > > > > > > > > >_________________________________________________________ > > >Do You Yahoo!? > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:15:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06056 for ; Fri, 10 Aug 2001 11:15:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03704; Fri, 10 Aug 2001 08:22:26 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA03682 for ; Fri, 10 Aug 2001 08:21:10 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id LAA01995; Fri, 10 Aug 2001 11:13:23 -0400 Message-ID: <3B73FA12.C3FFA5D9@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net CC: tgol@laurelnetworks.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Three way handshake draft Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 11:13:22 -0400 Content-Transfer-Encoding: 7bit I was wondering why this draft got expired. Looking at the mail archives, it just passed away silently. Does anybody have an idea? Thanks in advance... -- Tayfun Gol _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:21:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06133 for ; Fri, 10 Aug 2001 11:21:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03766; Fri, 10 Aug 2001 08:28:27 -0700 (PDT) Received: from cactus.cisco.com (cactus.cisco.com [64.101.140.220]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03754 for ; Fri, 10 Aug 2001 08:27:28 -0700 (PDT) Received: from MBARTELL-W2K.cisco.com (dhcp-64-101-135-186.cisco.com [64.101.135.186]) by cactus.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA15808; Fri, 10 Aug 2001 08:19:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20010810101720.022678b0@cactus.cisco.com> X-Sender: mbartell@cactus.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manav Bhatia" From: Micah Bartell Subject: Re: [Isis-wg] NSAP Structure Cc: "Jeff Learman" , In-Reply-To: <02ee01c121af$517a5690$da046c6b@Manav> References: <00b701c12159$82d704a0$da046c6b@Manav> <4.3.2.7.2.20010810100359.02c37b98@cactus.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 10:19:42 -0500 Let me clarify. The sourceID is IDlength (systemID) for LSP's. For SNP's, it is IDlength+1, the +1 is a zero circuit ID. /mpb At 20:45 08/10/2001 +0530, Manav Bhatia wrote: > > To the best of my knowledge, no one has implemented anything but 6 byte > > systemID's. > >But its defined in the RFC .. so there is no garuntee that all systems IDs >will fall under 6 bytes ! > > > > > Also, the sourceID is systemID Length +1. > >Is the +1 for the SEL byte ?? >I dont think the SEL byte is included in defining the unique ID of the IS >i.e. Source ID ! > > > > > Area addresses however are implemented variable length. > >Area addresses may computed as (total length - (system ID +1) ) >I read it somewhere but its not exactly flashing me where .. > >Manav > > > > > /mpb > > > > > > At 10:50 08/10/2001 -0400, Jeff Learman wrote: > > > > >Friends don't let friends use 8-byte system IDs ;-) > > > > > >RFC 1142 is the draft standard. One of the wonderful things that > > >the ISO committee did was to permit the system ID to be 1-8 bytes, > > >making our lives more enjoyable and increasing employment security > > >for software engineers. The ID size must be constant throughout > > >a routing domain. > > > > > >You need to implement ISO 10589, not the draft standard. > > > > > >Regards, > > >Jeff > > > > > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > > > >Hi, > > > >The general structure of the NSAP structure as defined in RFC 1629 >(6.2.1) > > > >gives the length of system Identifier to be varying from 1-8 octets. > > > >The length of the source ID for all the IS-IS PDUs as given in the rfc >1142 > > > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this >into > > > >6 octets in my IS-IS PDUs ?? > > > > > > > >Regards, > > > >Manav Bhatia > > > > > > > >"C is not a big language, and is not well served by a big book." -- >K&R2 > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:24:47 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06178 for ; Fri, 10 Aug 2001 11:24:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03922; Fri, 10 Aug 2001 08:31:31 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03805 for ; Fri, 10 Aug 2001 08:30:36 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id IAA06224; Fri, 10 Aug 2001 08:22:53 -0700 (PDT) From: Mike Truskowski Message-Id: <200108101522.IAA06224@diablo.cisco.com> Subject: Re: [Isis-wg] NSAP Structure To: mnvbhatia@yahoo.com ("Manav Bhatia") Cc: jlearman@cisco.com, mbartell@cisco.com, isis-wg@spider.juniper.net In-Reply-To: <02ee01c121af$517a5690$da046c6b@Manav>; from "Manav Bhatia" at Aug 10, 101 8:14 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 8:22:53 PDT See below... > > > To the best of my knowledge, no one has implemented anything but 6 byte > > systemID's. > > But its defined in the RFC .. so there is no garuntee that all systems IDs > will fall under 6 bytes ! Look, the systemID can be, by ISO, 1-8 bytes. If you want to code for 1-8 bytes.. fine... but what Micah and Jeff are telling you is that the "world" uses 6 byte ids and this is consistant domain wide. > > > > > Also, the sourceID is systemID Length +1. systemID = 6 nsel =1 everything else in front of this is the area address. mwt > > Is the +1 for the SEL byte ?? > I dont think the SEL byte is included in defining the unique ID of the IS > i.e. Source ID ! > > > > > Area addresses however are implemented variable length. > > Area addresses may computed as (total length - (system ID +1) ) > I read it somewhere but its not exactly flashing me where .. > > Manav > > > > > /mpb > > > > > > At 10:50 08/10/2001 -0400, Jeff Learman wrote: > > > > >Friends don't let friends use 8-byte system IDs ;-) > > > > > >RFC 1142 is the draft standard. One of the wonderful things that > > >the ISO committee did was to permit the system ID to be 1-8 bytes, > > >making our lives more enjoyable and increasing employment security > > >for software engineers. The ID size must be constant throughout > > >a routing domain. > > > > > >You need to implement ISO 10589, not the draft standard. > > > > > >Regards, > > >Jeff > > > > > >At 12:55 AM 8/10/2001, Manav Bhatia wrote: > > > >Hi, > > > >The general structure of the NSAP structure as defined in RFC 1629 > (6.2.1) > > > >gives the length of system Identifier to be varying from 1-8 octets. > > > >The length of the source ID for all the IS-IS PDUs as given in the rfc > 1142 > > > >is 6 octets. Now if i have a system ID of 8 octets .. how do i map this > into > > > >6 octets in my IS-IS PDUs ?? > > > > > > > >Regards, > > > >Manav Bhatia > > > > > > > >"C is not a big language, and is not well served by a big book." -- > K&R2 > > > > > > > > > > > > > > > >_________________________________________________________ > > > >Do You Yahoo!? > > > >Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:30:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06251 for ; Fri, 10 Aug 2001 11:30:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03996; Fri, 10 Aug 2001 08:37:27 -0700 (PDT) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03983 for ; Fri, 10 Aug 2001 08:36:43 -0700 (PDT) Received: from mailhost.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA14288; Fri, 10 Aug 2001 08:18:06 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA19467; Fri, 10 Aug 2001 08:26:43 -0700 (PDT) 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 LAA03103; Fri, 10 Aug 2001 11:28:50 -0400 for Received: from nortelnetworks.com (localhost [127.0.0.1]) by lead.engeast (8.9.3+Sun/8.9.1) with ESMTP id LAA08980; Fri, 10 Aug 2001 11:28:25 -0400 (EDT) Message-ID: <3B73FD99.4573767E@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: Tayfun Gol CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Three way handshake draft References: <3B73FA12.C3FFA5D9@laurelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 11:28:25 -0400 Content-Transfer-Encoding: 7bit Tayfun Gol wrote: > I was wondering why this draft got expired. Looking at the mail > archives, it just passed away silently. Does anybody have an idea? > > Thanks in advance... > > -- > > Tayfun Gol > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg Tayfun, Three way handshake draft passed last call in January and was submitted to IESG for information RFC. The draft's expiry date was January 2001 and hence was probably removed from IETF drafts page. Thanks, Rajesh -- ------------------------------------------------------------- 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@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 11:56:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06891 for ; Fri, 10 Aug 2001 11:56:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA04252; Fri, 10 Aug 2001 09:03:26 -0700 (PDT) Received: from mailweb32.rediffmail.com ([203.199.83.152]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA04235 for ; Fri, 10 Aug 2001 09:02:08 -0700 (PDT) Received: (qmail 6236 invoked by uid 510); 10 Aug 2001 15:55:07 -0000 Message-ID: <20010810155507.6235.qmail@mailweb32.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 10 Aug 2001 15:55:07 -0000 MIME-Version: 1.0 To: From: "Selvam Murugesan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: quoted-printable Subject: [Isis-wg] Appropriate standard document for implemention of ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 10 Aug 2001 15:55:07 -0000 Content-Transfer-Encoding: quoted-printable Hi, = I have a confusion on which version of the below stated ISO 10589 st= andards to follow for implementing the ISIS protocol? Which of this has t= he bug-free specifications of this standard? = 1. ISO/IEC 10589:1992 = 2. ISO/IEC 10589:1992/Cor 1:1993 3. ISO/IEC 10589:1992/Cor 2:1996 4. ISO/IEC 10589:1992/Cor 3:1996 5. ISO/IEC 10589:1992/Amd 1:1996 Implementation conformance statement pro= formas 6. ISO/IEC 10589:1992/Amd 2:1999 Extensions for group composition and rel= ated MST multicast routeing. Please help!!! Thanks in advance Regards, Selvam _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 12:28:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07512 for ; Fri, 10 Aug 2001 12:28:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA04463; Fri, 10 Aug 2001 09:35:27 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA04448 for ; Fri, 10 Aug 2001 09:34:11 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Manav Bhatia'" , Jeff Learman , Micah Bartell Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] NSAP Structure 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 12:26:15 -0400 > > To the best of my knowledge, no one has implemented > > anything but 6 byte systemID's. > > But its defined in the RFC .. so there is no garuntee that > all systems IDs will fall under 6 bytes ! You will be within the letter of the spec if you release a version of IS-IS that uses something other than 6 bytes. However, you will have trouble interoperating with any one else, and thus trouble deploying such gear. It is like one of those amusing laws that are left on the books that everyone knows enough to ignore. Unfortunately for those attempting to learn the protocol from the spec, the spec includes facts that just aren't so. This issue pops up on the list from time to time, and serves as a shibboleth. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 12:36:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07793 for ; Fri, 10 Aug 2001 12:36:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA04523; Fri, 10 Aug 2001 09:42:27 -0700 (PDT) Received: from web14913.mail.yahoo.com (web14913.mail.yahoo.com [216.136.225.240]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA04511 for ; Fri, 10 Aug 2001 09:41:49 -0700 (PDT) Message-ID: <20010810163406.63633.qmail@web14913.mail.yahoo.com> Received: from [203.200.20.224] by web14913.mail.yahoo.com; Fri, 10 Aug 2001 09:34:06 PDT From: Manav Bhatia Subject: RE: [Isis-wg] NSAP Structure To: Jeff Parker , Jeff Learman , Micah Bartell Cc: "'isis-wg@spider.juniper.net'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 09:34:06 -0700 (PDT) Thanks a lot for clearing this up ! --- Jeff Parker wrote: > > > To the best of my knowledge, no one has implemented > > > anything but 6 byte systemID's. > > > > But its defined in the RFC .. so there is no garuntee that > > all systems IDs will fall under 6 bytes ! > > You will be within the letter of the spec if you release > a version of IS-IS that uses something other than 6 bytes. > However, you will have trouble interoperating with any > one else, and thus trouble deploying such gear. > > It is like one of those amusing laws that are left on the > books that everyone knows enough to ignore. Unfortunately > for those attempting to learn the protocol from the spec, > the spec includes facts that just aren't so. > > This issue pops up on the list from time to time, and > serves as a shibboleth. > > - jeff parker > - axiowave networks __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 13:19:20 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08593 for ; Fri, 10 Aug 2001 13:19:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA04832; Fri, 10 Aug 2001 10:26:26 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by external.juniper.net (8.9.3/8.9.3) with SMTP id KAA04820 for ; Fri, 10 Aug 2001 10:25:54 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Aug 2001 17:18:10 -0000 X-Apparently-From: Message-ID: <048801c121c0$f495a5d0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] IS TYPE field Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 22:51:49 +0530 Content-Transfer-Encoding: 7bit Hi All, In the Level 1 Link State PDU there is a field IS TYPE. It has two bits where bit 1 set indicates that it is a L1 IS and bit 2 set indicates that it is a L2 IS. The other combinations are unused. What should i set if the IS is L1/L2 ? Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 14:24:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09307 for ; Fri, 10 Aug 2001 14:24:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA05144; Fri, 10 Aug 2001 11:31:26 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA05132 for ; Fri, 10 Aug 2001 11:30:09 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Micah Bartell'" , Swati Rastogi Cc: Mike Truskowski , isis-wg Subject: RE: [Isis-wg] Area Architecture 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 14:22:13 -0400 > > Are you implying that one IS can be > > in multiple areas ?? > No, I am saying that an area can have multiple area addresses. > > /mpb This does sound puzzling, but has a useful application. If you have two ISIS areas, A and B, that you wish to combine into one, you can do this by going to all the routers in area A, one by one, and adding area B. Two routers that share a common area will form an association. This forms a large area with all routers in B, and some in B as well as A. The administrator can now go around and remove area A from all routers. The result is that neither Area A nor Area B are ever split up, even though only one router is changed at a time. There is provision in the spec for configuring a router a third area. This is akin to giving a loan officer a heart. It does the them no good, and just confuses the rest of us. - jeff parker - axiowave networks PS Many of the questions that have appeared on the list in the last week are addressed in Radia Perlman's "Interconnections". Even if you have a copy of the first edition, she wouldn't mind if you rushed out to buy a copy of the new edition. Not only is this an excellent (the only?) source on ISIS, she stoops to discuss OSPF, Bridging, and many other topics. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 15:07:13 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10022 for ; Fri, 10 Aug 2001 15:07:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA05391; Fri, 10 Aug 2001 12:13:28 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA05374 for ; Fri, 10 Aug 2001 12:12:54 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Selvam Murugesan'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] doubts on IS-IS topology and addressing 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 15:04:59 -0400 > 1. Is it must for Level-1 IS to have a adjacency maintained > with a Level-2 IS or can the Level-1 IS communicate with a > Level-2 IS via Level-1 IS? No, yes. In the figure below, IS A can communicate with IS C via IS B. L1 A ====== L1/2 B ==== L2 C > 2.Regarding the ISO DCC addressing format adopted for Is-IS > addresses using semi-octet decimal digits representation, the > DSP is allocated 0-35 digits. Assuming CFI =1 (single digit), > then CDI = 3digits,ESI = 31 digits, which adds up the total > digits in the DSP to 35 digits. How is SEL field of the DSP > accomodated in this case? > > Manigandan There is a great deal of structure embedded in the ISO area field. However, the good news is that routers that don't need to route OSI traffic don't need to pay attention to this, and can treat the addresses as opaque tokens. Likewise, an OSPF area is formated like IP addresses, but is not interpreted as such. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 16:25:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11102 for ; Fri, 10 Aug 2001 16:25:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05768; Fri, 10 Aug 2001 13:32:27 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05756 for ; Fri, 10 Aug 2001 13:31:16 -0700 (PDT) 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 NAA27865; Fri, 10 Aug 2001 13:23:27 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 13:23:27 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A5F1@avalon.pluris.com> From: Les Ginsberg To: "'Selvam Murugesan '" , "'isis-wg@spider.juniper.net '" Subject: RE: [Isis-wg] Appropriate standard document for implemention of I SIS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 13:23:27 -0700 The documents below form a complementary set. The corrigenda include corrections to the text in the 1992 standard. The amendments are additions to the original text. So you must take into account all of the documents. In addition, I would strongly recommend that you utilize the latest second edition draft of ISO 10589, which is freely available from: ftp.cisco.com/pub/rfc/ISO/ ISO10589v2-2001-07-04.pdf Although this draft has yet to be formally approved by ISO, it has virtually completed its public review and is unlikely to undergo further significant revision. It incorporates all of the corrigenda and amendments into a single document - and includes some additional corrections which have never been published in any corrigenda. In addition, it is currently freely available during the review period - something which may not last. (ISO does not routinely make specs available for free) Of course none of this addresses IP specific extensions. For that you will have to consult the plethora of RFCs, drafts, and (in some cases) expired drafts - a list of (most of)which can be found on this group's webpage. I doubt that a specification of a protocol as complex as IS-IS will ever be 100% defect free - this also contributes to job security for protocol designers/implementors. Les -----Original Message----- From: Selvam Murugesan To: isis-wg@spider.juniper.net Sent: 8/10/01 8:55 AM Subject: [Isis-wg] Appropriate standard document for implemention of ISIS Hi, I have a confusion on which version of the below stated ISO 10589 standards to follow for implementing the ISIS protocol? Which of this has the bug-free specifications of this standard? 1. ISO/IEC 10589:1992 2. ISO/IEC 10589:1992/Cor 1:1993 3. ISO/IEC 10589:1992/Cor 2:1996 4. ISO/IEC 10589:1992/Cor 3:1996 5. ISO/IEC 10589:1992/Amd 1:1996 Implementation conformance statement proformas 6. ISO/IEC 10589:1992/Amd 2:1999 Extensions for group composition and related MST multicast routeing. Please help!!! Thanks in advance Regards, Selvam _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 10 16:49:26 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11362 for ; Fri, 10 Aug 2001 16:49:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05901; Fri, 10 Aug 2001 13:52:27 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA05889 for ; Fri, 10 Aug 2001 13:51:46 -0700 (PDT) Message-ID: From: Jeff Parker To: "'isis-wg@spider.juniper.net'" Cc: "'mshand@cisco.com'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] draft-shand-isis-restart Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 10 Aug 2001 16:43:59 -0400 Mike - I have a comment and a couple of questions about your draft, http://search.ietf.org/internet-drafts/draft-shand-isis-restart-01.txt 1) There was a great deal of concern during the discussions of OSPF restart and again about ISIS restart that we should not restart with the routing tables from a router that has crashed. However, there is still benefit in a proposal such as yours. If a router detects memory corruption in a routing task, it may wish to invalidate the route table before crashing so the restart mechanism is not used on reboot. Adding this as a suggestion may aleviate some concerns. However, a bug in the telnet task need not affect the route table. With a good memory architecture, the telnet task may be unable to affect the route table. 2) Assume that you are doing a controlled reboot of a router which takes longer than 30 seconds to reboot. Would you consider sending out hello messages that extend the hold time to cover the expected reboot time? That is, sending out hello messages with a hold time that matches the expected reboot time, rather than sticking with the previous value used. The issue of unreliable transmission arises, but your scheme doesn't require everything to go perfectly to reduce the amount of churn. 3) In your presentation of the draft on Wednesday, you made the observation that since the CSNP was not acknowledged, you needed to add a bit to the restart protocol to acknowledge the CSNP. Is the problem of the unreliable CSNP general enough that a general solution is called for? There are applications in bringing up p2p networks, in more restricted flooding topologies, etc. that would benefit from a reliable CSNP. The CSNP could include a sequence number, and the acknowledgement could be a Hello or an SNP with the right sequence number. (You could even return the CSNP rcvd) Negotiating this capacity could be done dynamically in hello packets, so the sender would know if it was worth resending the CSNP. - jeff parker - axiowave networks - diagnostic: someone who doesn't believe in two gods _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 04:30:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12237 for ; Mon, 13 Aug 2001 04:30:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA22032; Mon, 13 Aug 2001 01:38:27 -0700 (PDT) Received: from web8101.in.yahoo.com (web8101.in.yahoo.com [203.199.70.28]) by external.juniper.net (8.9.3/8.9.3) with SMTP id BAA22020 for ; Mon, 13 Aug 2001 01:37:24 -0700 (PDT) Message-ID: <20010813082919.91929.qmail@web8101.in.yahoo.com> Received: from [203.200.20.224] by web8101.in.yahoo.com; Mon, 13 Aug 2001 09:29:19 BST From: =?iso-8859-1?q?sudhir=20dskjf?= To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [Isis-wg] pseudonode Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 13 Aug 2001 09:29:19 +0100 (BST) Content-Transfer-Encoding: 8bit hi all, i am having some trouble understanding the concept of pseudonode. As far as i have understood pseudonode is the lan itself. but to which system the attached systems report their links. maybe the question is a bit trivial. any help is appreciated. thanks in advance srikrishna ____________________________________________________________ Do You Yahoo!? Send a newsletter, share photos & files, conduct polls, organize chat events. Visit http://in.groups.yahoo.com. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 04:38:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12296 for ; Mon, 13 Aug 2001 04:38:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA22094; Mon, 13 Aug 2001 01:46:27 -0700 (PDT) Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by external.juniper.net (8.9.3/8.9.3) with SMTP id BAA22081 for ; Mon, 13 Aug 2001 01:45:59 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Aug 2001 08:37:55 -0000 X-Apparently-From: Message-ID: <008501c123d3$c37aef90$da046c6b@Manav> From: "Swati Rastogi" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Pseudonode Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 13 Aug 2001 14:11:13 +0530 Content-Transfer-Encoding: 7bit Please help me in figureing out as to how IS-IS operates on a lan. The DR is selected from the number of ISs on the LAN and all the ISs convey the info that they are connected to the pseudonode to the DR only. All manual adjacencies are advertised by the individual ISs only .. i.e this information is multicasted on the LAN. The DR knows which all ISs are there on the lan and its only this information which is included in its CSNP .. PSNPs are issued by the individual ISs as an acknowledgment or when they see that their database differs from that of the DR. Is this correct ?? The reason why the DR is elected is to reduce the number of adjacencies maintained at each end of the IS ? With warm regards, Swati Rastogi _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 05:15:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12574 for ; Mon, 13 Aug 2001 05:15:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA22452; Mon, 13 Aug 2001 02:24:27 -0700 (PDT) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA22440 for ; Mon, 13 Aug 2001 02:23:25 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Aug 2001 09:15:21 -0000 X-Apparently-From: Message-ID: <005601c123d8$fdd18780$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] A doubt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 13 Aug 2001 14:47:53 +0530 Content-Transfer-Encoding: 7bit Hi All, I am referring to ISO/IEC 10589:2001 (E) and in Section 7.3.15.1 ("Action on receipt of the link state PDU") section 9b it says "If the source S of the LSP is an IS or pseudonode for which all but the last octet are equal to the systemID of the receiving IS, and the recveiving IS does not have that LSP in its database .. " My question is that how can an IS receive an LSP issued by itself ?? Please comment. Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 10:05:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20461 for ; Mon, 13 Aug 2001 10:05:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA23689; Mon, 13 Aug 2001 07:13:26 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA23677 for ; Mon, 13 Aug 2001 07:12:33 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Manav Bhatia'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] A doubt 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 13 Aug 2001 10:04:25 -0400 > My question is that how can an IS receive an LSP issued by itself ?? > > Manav Bhatia Here are two scenarios in which a router will receive an LSP with it's SystemId that it has not originated. 1) If router A reboots, there may still be copies of LSPs from the previous run. These will continue to be flooded around the network until the originating router trumps them. 2) It is also possible to have missconfigured a network to have two routers with the same system Id. The protocol deals with the first but is not designed to cope with the second. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 10:38:24 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21255 for ; Mon, 13 Aug 2001 10:38:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA23923; Mon, 13 Aug 2001 07:46:27 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA23910 for ; Mon, 13 Aug 2001 07:45:30 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Swati Rastogi'" , isis-wg Subject: RE: [Isis-wg] Pseudonode 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 13 Aug 2001 10:37:21 -0400 > The DR is selected from the number of ISs on the LAN and all > the ISs convey the info that they are connected to the > pseudonode to the DR only. All manual adjacencies are > advertised by the individual ISs only .. i.e this > information is multicasted on the LAN. So far so good... > The DR knows which all ISs are there > on the lan and its only this information which is included in > its CSNP .. There are two distinct things that the LAN DIS (DR) does 1) Sending periodic CSNPs to keep members of the LAN in sync 2) Acts as representative of the LAN to reduce the amount of adjacencies advertised in LSPs. The CSNP is merely a description of what the sender has in it's LSP database, and has no relation to which IS's are on the LAN. > PSNPs are issued by the individual ISs as an > acknowledgment or when they see > that their database differs from that of the DR. Right. You can use these to "pull" an LSP that you have learned about through a CSNP. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 17:53:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29255 for ; Mon, 13 Aug 2001 17:53:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA25677; Mon, 13 Aug 2001 15:01:27 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA25665 for ; Mon, 13 Aug 2001 15:00:09 -0700 (PDT) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id EC6E8F2C40; Mon, 13 Aug 2001 14:52:02 -0700 (PDT) Message-ID: <3B784784.806519E3@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Rajesh Saluja Cc: Tayfun Gol , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Three way handshake draft References: <3B73FA12.C3FFA5D9@laurelnetworks.com> <3B73FD99.4573767E@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 13 Aug 2001 14:32:52 -0700 Content-Transfer-Encoding: 7bit Rajesh Saluja wrote: > Tayfun Gol wrote: > > > I was wondering why this draft got expired. Looking at the mail > > archives, it just passed away silently. Does anybody have an idea? > > > > Thanks in advance... > > Tayfun (hope you're settling ok in Pitt ;-), there are multiple drafts hanging in last step (look @ upcoming ISIS WG minutes) that were dependent on some TLV number assignment clarification. Given the tlv-codepoints draft that can be referenced now, they should be updated and be avaialble as RFC any minute now ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 21:30:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01356 for ; Mon, 13 Aug 2001 21:30:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA26554; Mon, 13 Aug 2001 18:38:28 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37479 for ; Tue, 31 Jul 2001 08:20:21 -0700 (PDT) Received: from web11206.mail.yahoo.com (web11206.mail.yahoo.com [216.136.131.188]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with SMTP id f6VFAgw31004 for ; Tue, 31 Jul 2001 08:10:42 -0700 (PDT) X-JNPR-Received-From: outside Message-ID: <20010731151349.73282.qmail@web11206.mail.yahoo.com> Received: from [202.9.170.10] by web11206.mail.yahoo.com; Tue, 31 Jul 2001 08:13:49 PDT From: Aravind Ravikumar Subject: Re: [Isis-wg] ISIS-BGP interaction To: Naiming Shen Cc: isis-wg@juniper.net In-Reply-To: <20010730194305.A9649CAB72@prattle.redback.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1920075302-996592429=:73267" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 08:13:49 -0700 (PDT) --0-1920075302-996592429=:73267 Content-Type: text/plain; charset=us-ascii Thanks for your reply,but I would like get more information on the issue I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP IN the charter of Inter-Domain Routing (idr) working group there is a reference to BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents. From what I infer This has been published as rfc 1745.I think that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and "The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.) respectievely Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the above mentioned document. Aravind Naiming Shen wrote: http://www.ietf.org/IESG/actions.html BGP4/IDRP for IP---OSPF Interaction (Historic) ] ]Hi, ] ]Is there any standard document, defining the interaction between integrated I SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone through the minutes of ISIS working group .The strange thing I noticed was tha t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha t the status of ISIS-BGP interaction document is unknown and it needs to be pub lished as as draft\rfc.Can I get more information on this issue. ] ]Aravind ] - Naiming --------------------------------- Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-1920075302-996592429=:73267 Content-Type: text/html; charset=us-ascii

Thanks for your reply,but I would like get more information on the issue

 I tried to retrive the document that you have specified. But it seems that it is not currently available.I had read rfc 1745,but it speaks only about the interaction of OSPF with BGP/IDRP.But what I would like to know is that is there any well defined reference document which describes the interaction between ISIS and BGP

IN  the charter of Inter-Domain Routing (idr) working group there is a reference to
BGP/IDRP -- OSPF Interactions .It is said that this document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents.

From what I infer This has been published as rfc 1745.I think that the two references mentioned as BGP - OSPf interactions and IDRP -ISIS interactions are RFC1403 and "The Technical Design for Routeing Information Exchange between ISIS and IDRP" (Oran, D., Rekhter, Y., Hares, S.)  respectievely

 Since I am interesred in knowing about ISIS -BGP interaction ,I felt that the ISIS-IDRP interaction document will be useful.But I was unable to get the above mentioned document.

Aravind

  Naiming Shen <naiming@redback.com> wrote:


http://www.ietf.org/IESG/actions.html


BGP4/IDRP for IP---OSPF Interaction (Historic)

]
]Hi,
]
]Is there any standard document, defining the interaction between integrated I
SIS and BGP?(something similar to rfc 1745 for OSPf-BGP interaction).I had gone
through the minutes of ISIS working group .The strange thing I noticed was tha
t earlier (upto 94) there were references to ISIS-BGP interaction.But after tha
t it was not mentioned at all.In july 94 meeting's minutes,it was mentioned tha
t the status of ISIS-BGP interaction document is unknown and it needs to be pub
lished as as draft\rfc.Can I get more information on this issue.
]
]Aravind
]

- Naiming


Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/ --0-1920075302-996592429=:73267-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 21:31:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01385 for ; Mon, 13 Aug 2001 21:31:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA26573; Mon, 13 Aug 2001 18:39:51 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA37602 for ; Tue, 31 Jul 2001 08:28:41 -0700 (PDT) Received: from bcn.East.Sun.COM ([129.148.75.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24732; Tue, 31 Jul 2001 09:22:03 -0600 (MDT) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA17445; Tue, 31 Jul 2001 11:22:04 -0400 (EDT) Message-Id: <200107311522.LAA17445@bcn.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Dual IS-IS To: isis-wg@spider.juniper.net, sachidananda_k@hotmail.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: uYLoVynLEMC8vHCYHLIQZQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 31 Jul 2001 11:22:04 -0400 (EDT) From: "Sachidananda K" Is the link state database maintained seperately for both OSI addresses and IP addresses or is it one and the same. Although this is really an implementation issue rather than a protocol issue, I assume the link state database is "one and the same". An LSP basically says "I, router R1, have neighbors R2, R3, and R4, and the IP addresses I'm connected to are x, y, and z, and the CLNP addresses I can reach are A and B". So the same LSP can contain information about multiple address families. One could put information for different address families into different LSP fragments, but I don't see any reason to. The forwarding table is another issue. I'd think it would be more convenient to have separate forwarding tables for each address family, rather than a single lookup engine that would be able to process multiple types of addresses. Are there still networks with both types of addresses? Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 21:32:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01422 for ; Mon, 13 Aug 2001 21:32:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA26600; Mon, 13 Aug 2001 18:40:23 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA59376 for ; Fri, 3 Aug 2001 20:11:08 -0700 (PDT) Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7430sw84630 for ; Fri, 3 Aug 2001 20:00:54 -0700 (PDT) X-JNPR-Received-From: outside Received: from 66-44-90-192.s573.tnt3.lnhva.md.dialup.rcn.com ([66.44.90.192] helo=rcheh) by smtp02.mrf.mail.rcn.net with smtp (Exim 3.32 #2) id 15SrjV-0007Cm-00 ; Fri, 03 Aug 2001 23:04:10 -0400 Message-ID: <003f01c11c91$c4d1bd40$c05a2c42@rcheh> From: "Raymond Cheh" To: Cc: References: <200108040227.TAA19291@mail4.bigmailbox.com> Subject: Re: [Isis-wg] Doubt regarding Default Informatoin Originate MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 3 Aug 2001 23:01:27 -0400 Content-Transfer-Encoding: 7bit That may be useful when one wants to specify a preferred default gateway rather than using the closest attached L12 router. Packets will use the router advertising the default gateway (because that is a route match) before using the ATT bit. Raymond Cheh ----- Original Message ----- From: "R Selvaraj" To: Cc: Sent: Friday, August 03, 2001 10:27 PM Subject: [Isis-wg] Doubt regarding Default Informatoin Originate > Hi, > > I would like to know the advantage of originating default information in L1 LSPs. Since Att bit itself is sufficient for finding default route in a L1 area then what is the significant of originating default informaton in L1 LSPs. > Pls let me clarified. > > Thanks, > Selva. > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 13 21:32:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01432 for ; Mon, 13 Aug 2001 21:32:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA26627; Mon, 13 Aug 2001 18:40:55 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA90093 for ; Wed, 8 Aug 2001 11:40:57 -0700 (PDT) Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id BAC8FF2C4B; Wed, 8 Aug 2001 11:33:26 -0700 (PDT) Message-ID: <3B7187BE.5D719B01@redback.com> From: Acee Lindem Organization: Redback Networks X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Naiming Shen Cc: "Martin, Christian" , "IS-IS WG (E-mail)" , jenny@redback.com Subject: Re: [Isis-wg] RE: draft-shen-isis-ospf-p2p-over-lan-01.txt References: <20010808180824.B0A80F2C4B@prattle.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 08 Aug 2001 14:41:02 -0400 Content-Transfer-Encoding: 7bit Naiming Shen wrote: > > Martin, > some comments inline, thanks. > > ]Folks, > ] > ]I have some comments on the draft that I'd like to address with the WG. I > ]apologize for cutting this so close to the meeting, but this is the first > ]chance I've had to address it. > ] > ]A while back I began considering how IS-IS could be made to support PTP > ]behavior over BMA networks. The driving force behind this was primarily the > ]ability to assign arbitrary, per-neighbor metric information to individual > ]neighbors. A second benefit would be the elimination of pseudonode exposion > ]when a large amount of PTP LAN links were used to interconnect routers. I > ]sent an email detailing the need to the WG, but there was little response. > ]Some notable vendors also displayed little interest. The only suggestion I > ]received, in fact, was to use PPPoE! After reviewing the draft, I have some > ]concern about the utility of the proposal, and whether or not it satisfies a > ]real need. While it does have merit and will help in many situations, the > ]scope should be expanded to address some more complex situations. Comments > ]of course are welcome. > ] > ]In regards to OSPF: > ] > ]OSPF currently supports NBMA networks. What we are attempting to do here is > ]create PtMP (of where MP can be P if there are only two nodes on a LAN) > ]networks out of BMA networks in order to support PTP type behavior, from a > ]Djiktsra perspective, correct? This is in OSPF today. You can build NBNA > ]networks on LANs and specify neighbors explicitly, with associated metrics. > ]The Hello's and LSA exchange is PTP, using ARP for next-hop MAC resoultion > ]based on the configured neighbor IP. As I see it, the only benefit the > ]draft provides is the elimination of DR election (and the corresponding > ]elimination of pseudonodes on PTP links), which can be done by making the > ]interface point-to-multipoint (although requiring configuration). The major > ]vendors support this feature today (I use it!). Martin, As you suggest, OSPF P2P over LAN is similiar to OSPF P2MP and they offer many of the same advantages. The arguments (which some may consider weak) for OSPF P2P over LAN are: 1. It allows a LAN or vLAN that is being used as P2P link to be viewed and configured as one. 2. It allows for unnumbered operation of a LAN or vLAN being used as P2P link. 3. It offers a unified view of the LAN or vLAN across OSPF and ISIS (since ISIS does not have P2MP). Thanks, -- Acee _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 00:12:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05331 for ; Tue, 14 Aug 2001 00:12:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA27414; Mon, 13 Aug 2001 21:20:28 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA27386 for ; Mon, 13 Aug 2001 21:19:28 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Aug 2001 04:11:18 -0000 X-Apparently-From: Message-ID: <010601c12477$ad7775c0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] IIH PDU exchange Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 09:44:53 +0530 Content-Transfer-Encoding: 7bit ISO/IEC 10589 says in section 8.4.2 that "LAN IIH PDUs shall be padded so that the SNSDU containing the IIH PDU as a length of atleast maxsize - 1 octets where maxsize for level 1/2 IIH PDUs is the maximum of - dataLinkBlockSize - originatingL1/2LSPBufferSize" This as i understand, is done to ensure that the adjaceny will only be formed between systems which are capable of exchanging PDUs of length up to maxsize octets. Consider the following scenario. The network is in a congested state and we are bringing up the IS-IS system. All ISs will multicast these max sized IIH packets which will only serve to aggravate the already congested network. Instead of multicasting max sized packets why dont we simply multicast packets and include an additional field where we mention the maximum block size each IS supports. The lower value can always be accepted. This is similiar to how the value of hold timers in BGP is negotiated. Has anyone given a thought to this. Please comment. Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 00:15:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05366 for ; Tue, 14 Aug 2001 00:15:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA27467; Mon, 13 Aug 2001 21:23:27 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA27450 for ; Mon, 13 Aug 2001 21:22:36 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Aug 2001 04:14:27 -0000 X-Apparently-From: Message-ID: <010e01c12478$1e5be960$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Re: IIH PDU exchange Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 09:48:02 +0530 Content-Transfer-Encoding: 7bit Errata .. Please replace "multicast" with "broadcast" Regards, Manav ----- Original Message ----- From: "Manav Bhatia" To: Sent: Tuesday, August 14, 2001 9:44 AM Subject: IIH PDU exchange > ISO/IEC 10589 says in section 8.4.2 that "LAN IIH PDUs shall be padded so > that the SNSDU containing the IIH PDU as a length of atleast maxsize - 1 > octets where maxsize for level 1/2 IIH PDUs is the maximum of > - dataLinkBlockSize > - originatingL1/2LSPBufferSize" > > This as i understand, is done to ensure that the adjaceny will only be > formed between systems which are capable of exchanging PDUs of length up to > maxsize octets. > > Consider the following scenario. > > The network is in a congested state and we are bringing up the IS-IS system. > All ISs will multicast these max sized IIH packets which will only serve to > aggravate the already congested network. Instead of multicasting max sized > packets why dont we simply multicast packets and include an additional field > where we mention the maximum block size each IS supports. The lower value > can always be accepted. This is similiar to how the value of hold timers in > BGP is negotiated. > > Has anyone given a thought to this. > > Please comment. > > Thanks and Regards, > Manav Bhatia > > > > "C is not a big language, and is not well served by a big book." -- K&R2 > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 00:56:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05762 for ; Tue, 14 Aug 2001 00:56:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA27716; Mon, 13 Aug 2001 22:04:28 -0700 (PDT) Received: from mailweb29.rediffmail.com ([203.199.83.149]) by external.juniper.net (8.9.3/8.9.3) with SMTP id WAA27704 for ; Mon, 13 Aug 2001 22:03:29 -0700 (PDT) Received: (qmail 19144 invoked by uid 510); 14 Aug 2001 04:57:48 -0000 Message-ID: <20010814045748.19143.qmail@mailweb29.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 14 Aug 2001 04:57:48 -0000 MIME-Version: 1.0 To: From: "Selvam Murugesan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: quoted-printable Subject: [Isis-wg] trivial doubt on LSP number and sequence number Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 14 Aug 2001 04:57:48 -0000 Content-Transfer-Encoding: quoted-printable Hi, i have a simple doubt.What is the difference between a LSP number of = LSP ID field in the ISIS LSP PDU and Sequence number field? = = Thanks in advance Manigandan M _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 02:04:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19216 for ; Tue, 14 Aug 2001 02:04:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA28035; Mon, 13 Aug 2001 23:12:27 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id XAA28023 for ; Mon, 13 Aug 2001 23:11:35 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Aug 2001 06:03:25 -0000 X-Apparently-From: Message-ID: <01d701c12487$5743a380$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: , "Selvam Murugesan" References: <20010814045748.19143.qmail@mailweb29.rediffmail.com> Subject: Re: [Isis-wg] trivial doubt on LSP number and sequence number Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 11:36:59 +0530 Content-Transfer-Encoding: 7bit Because a link state PDU is limited in size to RecieveLSPBufferSize, it may not be possible to include information of all neighboring systems in a single LSP. So a system issues multiple Lisps to convey this information. Each LSP carries the same sourceID field but sets its own LSP number field individually. This allows the distribution of topology updates to be pipelined. The other end recognizes that they have a common originating source because they all use the same sourceID. Generally adjacencies are assigned to particular LSP numbers. (Ref. 7.3.4.4 ISO/IEC 10589). On the other hand, sequence numbers are used to determine the latest information. Suppose u have some LSP in your database and you receive another update for the same link state. How do you differentiate between the two .. how do you check whether the one you are receiving is the new one .. or the one you have in your database is the latest ?? This is where the sequence numbers come in. Looking at the sequence number you can tell which LSP is the more recent one. Obviously the higher the sequence number, more recent your LSP is ! hope it helps clears smthg .. Manav ----- Original Message ----- From: "Selvam Murugesan" To: Sent: Tuesday, August 14, 2001 10:27 AM Subject: [Isis-wg] trivial doubt on LSP number and sequence number Hi, i have a simple doubt.What is the difference between a LSP number of LSP ID field in the ISIS LSP PDU and Sequence number field? Thanks in advance Manigandan M _________________________________________________________ For Rs. 2,000,000 worth of Aptech scholarships click below http://clients.rediff.com/clients/aptechsch/index.htm _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 11:08:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06857 for ; Tue, 14 Aug 2001 11:08:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA30451; Tue, 14 Aug 2001 08:15:27 -0700 (PDT) Received: from hotmail.com (f34.law3.hotmail.com [209.185.241.34]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA30436 for ; Tue, 14 Aug 2001 08:14:17 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 14 Aug 2001 08:06:06 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 14 Aug 2001 15:06:06 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Aug 2001 15:06:06.0246 (UTC) FILETIME=[A45E4C60:01C124D2] Subject: [Isis-wg] SNPA or IP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 15:06:06 +0000 Hello, According to the RFC 1195, the OSI addresses may be derived from the IP address or the ethernet address. When it is derived from the IP address, the next hop in the IP routing table can be entered as the IP address of the next hop. Whereas if the it is derived from the ethernet address, what do we enter in the IP routing table? I think this a major concern for the Dual IS-IS for the reason that if the in IP the address resolution is dine by ARP in the DLL. Please clarify my doubt in this regard. Thanking you in advance for all the responses. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 11:46:48 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07669 for ; Tue, 14 Aug 2001 11:46:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA30647; Tue, 14 Aug 2001 08:55:27 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA30631 for ; Tue, 14 Aug 2001 08:54:27 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Manav Bhatia'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] IIH PDU exchange 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 11:46:08 -0400 > "LAN IIH PDUs shall be padded... > > Consider the following scenario: The network is in a > congested state and we are bringing up [all] the IS-IS > system[s]. > > Manav Bhatia Manav - There are periodic dicussions on the list about the utility of the padding, and I won't rehash those here. If you have so many IS-IS routers that periodic hello packets are a big problem, then I suspect the LSP exchange that will start once the adjacencies come up will have a greater effect. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 15:38:07 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13606 for ; Tue, 14 Aug 2001 15:38:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA31676; Tue, 14 Aug 2001 12:45:27 -0700 (PDT) Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA31661 for ; Tue, 14 Aug 2001 12:44:07 -0700 (PDT) Received: from tot-mtc-te.proxy.aol.com (tot-mtc-te.proxy.aol.com [64.12.103.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id PAA15372 for ; Tue, 14 Aug 2001 15:35:02 -0400 (EDT) Received: from ma.ultranet.com (ACA20257.ipt.aol.com [172.162.2.87]) by tot-mtc-te.proxy.aol.com (8.10.0/8.10.0) with ESMTP id f7EJWuX01586 for ; Tue, 14 Aug 2001 15:32:57 -0400 (EDT) Message-ID: <3B79A7CB.D886703@ma.ultranet.com> From: David Hudek X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@spider.juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Apparently-From: Hudeks@aol.com Subject: [Isis-wg] ISIS as Pack Mule? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 15:35:56 -0700 Content-Transfer-Encoding: 7bit For various reasons, there would appear to be a growing trend of having ISIS act as a convenient flooding mechanism for conveying different types of information that is essentially a "dont-care" for ISIS itself. Draft RFCs call for data to be added to LSPs that may be of interest to other entities, such as GMPLS or a constraint based SPF, but would not make any difference to a normal ISIS default metric SPF run. When that dont-care data changes within an LSP, a straightforward implementation that compares a modified checksum and/or does a simple byte-wise comparison on received LSPs (as mentioned in 10589) would detect that LSP data had changed, and schedule what will turn out to be an unnecessary SPF run. Even if ISIS would prefer not send updated LSPs very frequently if only non-ISIS data changes, there will be pressure to act in a timely fashion from the point of view of the other entities to convey their changed and changing data rapidly. If this dont-care data changes frequently there would be frequent unnecessary SPF runs (gated by whatever SPF pacing scheme one uses). As more types of dont-care data is loaded aboard LSPs over time, the liklihood of frequent dont-care changes increases. Of course, a receiver could actually intelligently parse each received LSP that differs, comparing fields against the earlier version, and decide for itself if the changes warrant an SPF run, but that seems like a lot of unnecessary extra work given that the originator of an LSP ought to know why they are changing it in the first place and could just simply let everyone else know. I was wondering about the effect of adding a new TLV in which the originator could convey that info. It might be as simple as a yes/no whether or not any change from the LSP with previous seqnum actually mattered to ISIS, or as complex as indicating which entity(ies) might be interested in the change, or something in-between. At first blush, it seems like it would improve scalability, with the only down-side being some security issues (however, none seem insurmountable). Folks can continue to load up ISIS with data only meaningful to other entities, and the extra burden would be generally limited to the flooding aspect, not also unnecessary SPF runs or extra parsing/comparisons. ISIS could even act more responsively to dont-care data changes, updating LSPs somewhat more frequently since their effect would be somewhat mitigated. So of course, the question arises, what's the horrible fatal flaw that's not jumping out just yet? :-) Is this something worth pursuing? Thanks, dave h dhudek@ma.ultranet.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 16:42:29 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14732 for ; Tue, 14 Aug 2001 16:42:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA31999; Tue, 14 Aug 2001 13:50:27 -0700 (PDT) Received: from pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA31979 for ; Tue, 14 Aug 2001 13:49:32 -0700 (PDT) Received: from redback.com ([63.200.51.175]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GI200DAZS4E9A@mta7.pltn13.pbi.net> for isis-wg@spider.juniper.net; Tue, 14 Aug 2001 13:41:03 -0700 (PDT) From: Tony Przygienda Subject: Re: [Isis-wg] ISIS as Pack Mule? To: David Hudek Cc: isis-wg@spider.juniper.net Message-id: <3B79883E.90DC6C77@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: <3B79A7CB.D886703@ma.ultranet.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 13:21:19 -0700 Content-Transfer-Encoding: 7BIT David Hudek wrote: > For various reasons, there would appear to be a growing > trend of having ISIS act as a convenient flooding mechanism > for conveying different types of information that is > essentially a "dont-care" for ISIS itself. Draft RFCs call > for data to be added to LSPs that may be of interest to other > entities, such as GMPLS or a constraint based SPF, but would > not make any difference to a normal ISIS default metric SPF run. > > When that dont-care data changes within an LSP, a straightforward > implementation that compares a modified checksum and/or does a simple > byte-wise comparison on received LSPs (as mentioned in 10589) would > detect that LSP data had changed, and schedule what will turn out to be > an unnecessary SPF run. Even if ISIS would prefer not send updated LSPs > very frequently if only non-ISIS data changes, there will be pressure to > act in a timely fashion from the point of view of the other > entities to convey their changed and changing data rapidly. > If this dont-care data changes frequently there would be frequent > unnecessary SPF runs (gated by whatever SPF pacing scheme one uses). > As more types of dont-care data is loaded aboard LSPs over time, the > liklihood of frequent dont-care changes increases. > > Of course, a receiver could actually intelligently parse > each received LSP that differs, comparing fields against the earlier > version, and decide for itself if the changes warrant an SPF run, > but that seems like a lot of unnecessary extra work given > that the originator of an LSP ought to know why they are > changing it in the first place and could just simply let everyone > else know. > > I was wondering about the effect of adding a new TLV in which > the originator could convey that info. It might be as simple as > a yes/no whether or not any change from the LSP with previous > seqnum actually mattered to ISIS, or as complex as indicating > which entity(ies) might be interested in the change, or something > in-between. The above has been proposed for PNNI years ago which had a somehow similar problem (lots of QoS metrics that when changed will not necessarily trigger computations) and it has not been well received due to several reasons. One of them being that to do things well you need basically a bitfield @ every TLV, sub-TLV, sub-subTLV level which is not very convienent and leads to a complex, easily broken representation. The other problem being that just missing one of those something-changed-bits can lead to catastrophic failures easily that are very hard to track down. Philosophically, it is not a good idea to put redundant data into the protocol messages since you have to account for behavior when the data contradicts itself. Messy stuff ... At least one leading vendor implemented the 'smart parse & figure out changes' thing and it worked very well without a lot of CPU overhead. Yes, some tricky code is involved but that's how protocol implementors make their living and vendors differentiate themselves ... I guess I'm saying my initial reaction is that's an implementation specific thing which we don't govern in the workgroup normally. thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 17:30:35 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15494 for ; Tue, 14 Aug 2001 17:30:34 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA32236; Tue, 14 Aug 2001 14:38:28 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id OAA32224 for ; Tue, 14 Aug 2001 14:37:02 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id RAA00984; Tue, 14 Aug 2001 17:28:45 -0400 Message-ID: <3B79980D.2E7ECD6B@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sachidananda K CC: isis-wg@spider.juniper.net, tgol@laurelnetworks.com Subject: Re: [Isis-wg] SNPA or IP 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 17:28:45 -0400 Content-Transfer-Encoding: 7bit Sachidananda K wrote: > Hello, > > According to the RFC 1195, the OSI addresses may be derived from the IP > address or the ethernet address. > > When it is derived from the IP address, the next hop in the IP routing table > can be entered as the IP address of the next hop. > Sachi, the OSI address is not used to derive the next hop IP address for adjacenct routers. It simply serves the purpose of uniquely identifiying a router from others in a topology. ( This is where you can derive the router's system ID which will be part of the LSP ID for the LSPs the router will generate, you can think of an IS-IS router's system ID analogous to an OSPF router's router ID. ) A router can resolve the next hop IP addresses for its adjacenct routers via the IP interface address TLV sent in the IIH PDUs and populate the routing table accordingly. Hope this helps... Tayfun Gol > > Whereas if the it is derived from the ethernet address, what do we enter in > the IP routing table? I think this a major concern for the Dual IS-IS for > the reason that if the in IP the address resolution is dine by ARP in the > DLL. > > Please clarify my doubt in this regard. > Thanking you in advance for all the responses. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 17:31:47 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15533 for ; Tue, 14 Aug 2001 17:31:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA32271; Tue, 14 Aug 2001 14:40:28 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id OAA32256 for ; Tue, 14 Aug 2001 14:39:53 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id RAA01097; Tue, 14 Aug 2001 17:31:35 -0400 Message-ID: <3B7998B7.70641D11@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Sachidananda K , isis-wg@spider.juniper.net, tgol@laurelnetworks.com Subject: Re: [Isis-wg] SNPA or IP References: <3B79980D.2E7ECD6B@laurelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 17:31:35 -0400 Content-Transfer-Encoding: 7bit Tayfun Gol wrote: > Sachidananda K wrote: > > > Hello, > > > > According to the RFC 1195, the OSI addresses may be derived from the IP > > address or the ethernet address. > > > > When it is derived from the IP address, the next hop in the IP routing table > > can be entered as the IP address of the next hop. > > > > Sachi, the OSI address is not used to derive the next hop IP address for > adjacenct routers. It simply serves the purpose of uniquely identifiying a > router from others in a topology. ( This is where you can derive the router's > system ID which will be part of the LSP ID for the LSPs the router will > generate, you can think of an IS-IS router's system ID analogous to an > OSPF router's router ID. ) > To clarify further, this is at least the case for IP routing if this is all you are concerned about, OSI address surely serves other purposes for OSI forwarding but I am assuming that's not what you are wondering.. > > A router can resolve the next hop IP addresses for its adjacenct routers via > the IP interface address TLV sent in the IIH PDUs and populate the routing > table accordingly. > > Hope this helps... > > Tayfun Gol > > > > > Whereas if the it is derived from the ethernet address, what do we enter in > > the IP routing table? I think this a major concern for the Dual IS-IS for > > the reason that if the in IP the address resolution is dine by ARP in the > > DLL. > > > > Please clarify my doubt in this regard. > > Thanking you in advance for all the responses. > > Sachi > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 17:54:22 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15800 for ; Tue, 14 Aug 2001 17:54:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA32431; Tue, 14 Aug 2001 15:02:28 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA32419 for ; Tue, 14 Aug 2001 15:01:14 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7EMLgi41857 for ; Tue, 14 Aug 2001 15:21:42 -0700 (PDT) X-JNPR-Received-From: outside Received: from snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 14 Aug 2001 14:52:39 -0700 Received: from redback.com ([63.200.51.175]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GI200ID5VG61C@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Tue, 14 Aug 2001 14:52:54 -0700 (PDT) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3B79992B.9E287E89@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: 14 Aug 2001 21:52:39.0703 (UTC) FILETIME=[70007270:01C1250B] Subject: [Isis-wg] tlv codepoints ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 14:33:31 -0700 Content-Transfer-Encoding: 7BIT new version not submitted yet. Will wait 1-2 days on comments before putting out. numbers are _not_ sorted on purpose thanks -- tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Redback Aug 2001 Reserved TLV Codepoints in ISIS Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This draft describes implementation codepoints within IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft summarizes all TLV codepoints that are being used by the protocol and its pending extensions. Przygienda Expires Feb 2002 [Page 1] Internet Draft TLV Codepoints Aug 2001 1. TLV Codepoints reserved ________________________________________________________________________ Name Value IIH LSP SNP Status ________________________________________________________________________ Area Addresses 1 y y n ISO 10589 IIS Neighbors 2 n y n ISO 10589 ES Neighbors 3 n y n ISO 10589 Part. DIS 4 n y n ISO 10589 Prefix Neighbors 5 n y n ISO 10589 IIS Neighbors 6 y n n ISO 10589 Padding 8 y n n ISO 10589 LSP Entries 9 n n y ISO 10589 Authentication 10 y y y ISO 10589 Opt. Checksum 12 y n y IETF-draft TE IIS Neigh. 22 n y n IETF-draft MT-ISN 222 n y n IETF-draft LSPBufferSize 14 y? y n ISO 10589 Rev 2 Draft DECnet Phase IV 42 ? ? ? DEC (ancient) IP Int. Reach 128 n y n RFC 1195 IPv6 IP. Reach 236 n y n IETF-draft Prot. Supported 129 y y n RFC 1195 M-Topologies 229 y y n IETF-draft IP Ext. Address 130 n y n RFC 1195 IDRPI 131 n y y RFC 1195 IP Intf. Address 132 y y n RFC 1195 IPv6 Intf. Addr. 232 y y n IETF-draft illegal 133 n n n RFC 1195 (not used) Router ID 134 n y n IETF-draft TE IP. Reach 135 n y n IETF-draft MT IP. Reach 235 n y n IETF-draft Dynamic Name 137 n y n RFC 2763 3-Way hellos 240 y n n IETF-draft Przygienda Expires Feb 2002 [Page 2] Internet Draft TLV Codepoints Aug 2001 2. Assignment Procedures This document is provided to avoid possible future conflicts in assignment of TLV numbers. It does not constitute or represent any standard or authority assigning TLV numbers. TLV assignment happens on a shared, informational basis between the ISO, SIF and the IETF working groups. The core ISIS protocol is being specified in the ISO standards body, IP extensions to it however are products of the ISIS working group in IETF. Since ISO does not provide a numbering authority and IANA is only responsible for IP related coding points, no plausible central authority to assign TLV numbers exists as of today. This document will be periodically updated by never versions in the fashion of [RP94 ] and successors. 3. Acknowledgments Thanks to Les Ginsberg and others for pointing out details and improving this work. 4. Security Consideration ISIS security applies to the work presented. No specific security issues are being introduced. References [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. INTERNET-RFC, Internet Engineering Task Force, February 1990. [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ISO90] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. Internet Engineering Task Force, October 1994. Przygienda Expires Feb 2002 [Page 3] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 14 19:06:29 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16787 for ; Tue, 14 Aug 2001 19:06:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA32773; Tue, 14 Aug 2001 16:14:28 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA32761 for ; Tue, 14 Aug 2001 16:13:01 -0700 (PDT) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7ENXUi42939 for ; Tue, 14 Aug 2001 16:33:30 -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.2966); Tue, 14 Aug 2001 16:04:00 -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 QAA02280; Tue, 14 Aug 2001 16:04:09 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 16:04:09 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A60A@avalon.pluris.com> From: Les Ginsberg To: "'Tony Przygienda'" , isis-wg@juniper.net Subject: RE: [Isis-wg] tlv codepoints ... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Aug 2001 23:04:00.0686 (UTC) FILETIME=[67AA9CE0:01C12515] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 14 Aug 2001 16:04:08 -0700 Tony - The LSPBuffersize option is NOT included in IIH PDUs. So the definition should look like: LSPBufferSize 14 n y n ISO 10589 Draft Also, while I do not object to some other ordering scheme than straight numerical, I haven't figured out the algorithm you used to order/group the TLVs. Is this one of those pattern recognition tests? Or do you simply feel that chaos is a good thing? Les > -----Original Message----- > From: Tony Przygienda [mailto:prz@redback.com] > Sent: Tuesday, August 14, 2001 2:34 PM > To: isis-wg@juniper.net > Subject: [Isis-wg] tlv codepoints ... > > > new version not submitted yet. Will wait 1-2 days on comments before > putting out. numbers are _not_ sorted on purpose > > thanks > > -- tony > > > > > Internet Engineering Task Force T. > Przygienda > INTERNET DRAFT > Redback > > Aug 2001 > Reserved TLV Codepoints in ISIS > > > > > Status of This Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. Internet-Drafts are > working > documents of the Internet Engineering Task Force (IETF), > its areas, > and its working groups. Note that other groups may also > distribute > working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months > and may be updated, replaced, or obsoleted by other documents at > any time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Copyright Notice Copyright (C) The Internet Society (2000). All > Rights Reserved. > > > > Abstract > > This draft describes implementation codepoints within > IS-IS [ISO90 , Cal90a , Cal90b ] used today by several ISPs for > routing within their clouds. IS-IS is an interior gateway routing > protocol developed originally by OSI and used with IP > extensions as > IGP. This draft summarizes all TLV codepoints that are > being used by > > the protocol and its pending extensions. > > > Przygienda Expires Feb 2002 > [Page 1] > > > Internet Draft TLV Codepoints > Aug 2001 > > 1. TLV Codepoints reserved > > ______________________________________________________________ > __________ > > Name Value IIH LSP SNP Status > > > ______________________________________________________________ > __________ > > Area Addresses 1 y y n ISO 10589 > IIS Neighbors 2 n y n ISO 10589 > ES Neighbors 3 n y n ISO 10589 > Part. DIS 4 n y n ISO 10589 > Prefix Neighbors 5 n y n ISO 10589 > IIS Neighbors 6 y n n ISO 10589 > Padding 8 y n n ISO 10589 > LSP Entries 9 n n y ISO 10589 > Authentication 10 y y y ISO 10589 > > > Opt. Checksum 12 y n y IETF-draft > TE IIS Neigh. 22 n y n IETF-draft > MT-ISN 222 n y n IETF-draft > > > LSPBufferSize 14 y? y n ISO 10589 > Rev 2 Draft > > DECnet Phase IV 42 ? ? ? DEC (ancient) > > > IP Int. Reach 128 n y n RFC 1195 > IPv6 IP. Reach 236 n y n IETF-draft > > > Prot. Supported 129 y y n RFC 1195 > M-Topologies 229 y y n IETF-draft > > > IP Ext. Address 130 n y n RFC 1195 > IDRPI 131 n y y RFC 1195 > > > IP Intf. Address 132 y y n RFC 1195 > IPv6 Intf. Addr. 232 y y n IETF-draft > > > illegal 133 n n n RFC 1195 (not used) > Router ID 134 n y n IETF-draft > > > TE IP. Reach 135 n y n IETF-draft > MT IP. Reach 235 n y n IETF-draft > > > Dynamic Name 137 n y n RFC 2763 > 3-Way hellos 240 y n n IETF-draft > > > > Przygienda Expires Feb 2002 > [Page 2] > > Internet Draft TLV Codepoints > Aug 2001 > > 2. Assignment Procedures > > This document is provided to avoid possible future conflicts in > assignment of TLV numbers. It does not constitute or > represent any > standard or authority assigning TLV numbers. TLV > assignment happens > > on a shared, informational basis between the ISO, SIF and the IETF > working groups. The core ISIS protocol is being specified in the > ISO standards body, IP extensions to it however are > products of the > ISIS working group in IETF. Since ISO does not provide a numbering > authority and IANA is only responsible for IP related > coding points, > > no plausible central authority to assign TLV numbers exists as of > today. > > This document will be periodically updated by never > versions in the > fashion of [RP94 ] and successors. > > > > 3. Acknowledgments > > Thanks to Les Ginsberg and others for pointing out details and > improving this work. > > > > 4. Security Consideration > > ISIS security applies to the work presented. No specific security > issues are being introduced. > > References > > [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. > INTERNET-RFC, Internet Engineering Task Force, February > 1990. > > > [Cal90b] R. Callon. Use of OSI ISIS for Routing in > TCP/IP and Dual > > Environments. INTERNET-RFC, Internet Engineering Task > Force, December 1990. > > > [ISO90] ISO. Information Technology - Telecommunications and > Information Exchange between Systems - > Intermediate System > > to Intermediate System Routing Exchange Protocol for > Use in Conjunction with the Protocol for Providing the > Connectionless-Mode Network Service. ISO, 1990. > > > [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. > Internet Engineering Task Force, October 1994. > > > > Przygienda Expires Feb 2002 > [Page 3] > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 15 07:56:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14485 for ; Wed, 15 Aug 2001 07:56:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA35910; Wed, 15 Aug 2001 05:04:29 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA35898 for ; Wed, 15 Aug 2001 05:03:08 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C12581.12689795" Subject: [Isis-wg] draft-hermelin-ext-lsp-frags-02.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: [Isis-wg] draft-hermelin-ext-lsp-frags-02.txt Thread-Index: AcElgRJjiehYu/U0T0WppYtwwnD9pA== From: "Amir Hermelin" To: "ISIS-wg (E-mail)" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 15 Aug 2001 14:54:43 +0300 This is a multi-part message in MIME format. ------_=_NextPart_001_01C12581.12689795 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, here's a new version of the draft. The main change is the ability to modify the SPF, and include adjacency info in extended LSPs. As you recall, this was discussed a little in the list and somewhat turned down; however, in the last IETF meeting it was agreed that SPF modification is acceptable. The modified mechanism still supports extending LSPs without needed SPF modification. Abstract This document describes a mechanism that allows a system to originate more than 256 LSP fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. -- Amir Hermelin Charlotte's Web Networks Inc. ------_=_NextPart_001_01C12581.12689795 Content-Type: text/plain; name="draft-hermelin-ext-lsp-frags-02.txt" Content-Description: draft-hermelin-ext-lsp-frags-02.txt Content-Disposition: attachment; filename="draft-hermelin-ext-lsp-frags-02.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBbWlyIEhlcm1lbGluDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDaGFybG90dGUncyBXZWIgTmV0d29ya3MNCkV4cGlyYXRpb24g RGF0ZTogRmVicnVhcnkgMjAwMg0KDQoNCiAgICBFeHRlbmRpbmcgdGhlIE51bWJlciBvZiBJUy1J UyBMU1AgRnJhZ21lbnRzIEJleW9uZCB0aGUgMjU2IExpbWl0DQoNCiAgICAgICAgICAgICAgICAg IGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0DQoNCg0KU3RhdHVzDQoNCiAgIFRo aXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0DQoNCiAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAi TVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQi LCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4g dGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBS RkMgMjExOSBbQkNQMTRdLg0KDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGEgc3lzdGVtIHRvIG9yaWdpbmF0ZQ0KICAgbW9y ZSB0aGFuIDI1NiBMU1AgZnJhZ21lbnRzLCBhIGxpbWl0IHNldCBieSB0aGUgb3JpZ2luYWwgSW50 ZXJtZWRpYXRlDQogICBTeXN0ZW0gdG8gSW50ZXJtZWRpYXRlIFN5c3RlbSAoSVMtSVMpIFJvdXRp bmcgcHJvdG9jb2wsIGFzIGRlc2NyaWJlZA0KICAgaW4gSVNPIDEwNTg5LiAgVGhpcyBtZWNoYW5p c20gY2FuIGJlIHVzZWQgaW4gSVAtb25seSwgT1NJLW9ubHksIGFuZA0KICAgZHVhbCByb3V0ZXJz Lg0KDQoNCg0KDQoNCg0KDQpBLiBIZXJtZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0IERyYWZ0ICAgICBk cmFmdC1oZXJtZWxpbi1leHQtbHNwLWZyYWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoN CjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgSW4gdGhlIElTLUlTIHByb3RvY29sLCBhIHN5c3RlbSBm bG9vZHMgaXRzIGxpbmstc3RhdGUgaW5mb3JtYXRpb24gaW4NCiAgIExpbmsgU3RhdGUgUHJvdG9j b2wgRGF0YSBVbml0cywgb3IgTFNQcyBmb3Igc2hvcnQuICBUaGVzZSBsb2dpY2FsDQogICBMU1Bz IGNhbiBiZWNvbWUgcXVpdGUgbGFyZ2UsIHRoZXJlZm9yZSB0aGUgcHJvdG9jb2wgc3BlY2lmaWVz IGEgbWVhbnMNCiAgIG9mIGZyYWdtZW50aW5nIHRoaXMgaW5mb3JtYXRpb24gaW50byBtdWx0aXBs ZSBMU1AgZnJhZ21lbnRzLiAgVGhlDQogICBudW1iZXIgb2YgZnJhZ21lbnRzIGEgc3lzdGVtIGNh biBnZW5lcmF0ZSBpcyBsaW1pdGVkIGJ5IElTTyAxMDU4OQ0KICAgW0lTSVMtSVNPXSB0byAyNTYg ZnJhZ21lbnRzLCB3aGVyZSBlYWNoIGZyYWdtZW50J3Mgc2l6ZSBpcyBhbHNvDQogICBsaW1pdGVk LiAgSGVuY2UsIHRoZXJlIGlzIGEgbGltaXQgb24gdGhlIGFtb3VudCBvZiBsaW5rLXN0YXRlDQog ICBpbmZvcm1hdGlvbiBhIHN5c3RlbSBjYW4gZ2VuZXJhdGUuDQoNCiAgIEEgbnVtYmVyIG9mIGZh Y3RvcnMgY2FuIGNvbnRyaWJ1dGUgdG8gZXhjZWVkaW5nIHRoaXMgbGltaXQ6DQogICAgIC0gIElu dHJvZHVjdGlvbiBvZiBuZXcgVExWcyBhbmQgc3ViLVRMVnMgdG8gYmUgaW5jbHVkZWQgaW4gTFNQ cy4NCiAgICAgLSAgVGhlIHVzZSBvZiBMU1BzIHRvIHByb3BhZ2F0ZSB2YXJpb3VzIHR5cGVzIG9m IGluZm9ybWF0aW9uIChzdWNoDQogICAgIGFzIHRyYWZmaWMtZW5naW5lZXJpbmcgaW5mb3JtYXRp b24pLg0KICAgICAtICBUaGUgZ3Jvd2luZyBzaXplIG9mIHJvdXRlIHRhYmxlcyBhbmQgQVMgdG9w b2xvZ2llcy4NCiAgICAgLSAgRmluZXIgZ3JhbnVsYXJpdHkgcm91dGluZywgYW5kIHRoZSBhYmls aXR5IHRvIGluamVjdCBleHRlcm5hbA0KICAgICByb3V0ZXMgaW50byBhcmVhcyBbRE9NQUlOLVdJ REVdLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB0byByZWxheCB0 aGUgbGltaXQgb24gdGhlIG51bWJlcg0KICAgb2YgTFNQIGZyYWdtZW50cy4NCg0KDQoxLjEgIERl ZmluaXRpb25zIG9mIENvbW1vbmx5IFVzZWQgVGVybXMNCg0KICAgVGhpcyBzZWN0aW9uIHByb3Zp ZGVzIGRlZmluaXRpb25zIGZvciB0ZXJtcyB0aGF0IGFyZSB1c2VkIHRocm91Z2hvdXQNCiAgIHRo ZSB0ZXh0Lg0KDQogICAgIE9yaWdpbmF0aW5nIFN5c3RlbQ0KICAgICAgICBBIHJvdXRlciBydW5u aW5nIHRoZSBJUy1JUyBwcm90b2NvbC4NCg0KICAgICBPcmlnaW5hbCBzeXN0ZW0taWQNCiAgICAg ICAgVGhlIHN5c3RlbS1pZCBvZiBhbiBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgICAgRXh0ZW5k ZWQgc3lzdGVtLWlkDQogICAgICAgIEFuIGFkZGl0aW9uYWwgc3lzdGVtLWlkIHRoYXQgaXMgYXNz aWduZWQgYnkgdGhlIG5ldHdvcmsNCiAgICAgICAgYWRtaW5pc3RyYXRvci4gIEVhY2ggZXh0ZW5k ZWQgc3lzdGVtLWlkIGFsbG93cyBnZW5lcmF0aW9uIG9mIDI1Ng0KICAgICAgICBhZGRpdGlvbmFs LCBvciBleHRlbmRlZCwgTFNQIGZyYWdtZW50cy4gIFRoZSBleHRlbmRlZCBzeXN0ZW0taWQsDQog ICAgICAgIGxpa2UgdGhlIG9yaWdpbmFsIHN5c3RlbS1pZCwgbXVzdCBiZSB1bmlxdWUgdGhyb3Vn aG91dCB0aGUNCiAgICAgICAgcm91dGluZyBkb21haW4uDQoNCiAgICAgVmlydHVhbCBTeXN0ZW0N CiAgICAgICAgVGhlIHN5c3RlbSwgaWRlbnRpZmllZCBieSBhbiBleHRlbmRlZCBzeXN0ZW0taWQs IGFkdmVydGlzZWQgYXMNCiAgICAgICAgb3JpZ2luYXRpbmcgdGhlIGV4dGVuZGVkIExTUCBmcmFn bWVudHMuICBUaGVzZSBmcmFnbWVudHMgc3BlY2lmeQ0KICAgICAgICB0aGUgZXh0ZW5kZWQgc3lz dGVtLWlkIGluIHRoZWlyIExTUCBJRHMuDQoNCiAgICAgT3JpZ2luYWwgTFNQDQoNCg0KDQpBLiBI ZXJtZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAwMiAgICAgICAgICAgICAg ICAgW1BhZ2UgMl0NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1oZXJtZWxpbi1leHQtbHNw LWZyYWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoNCiAgICAgICAgQW4gTFNQIHVzaW5n IHRoZSBvcmlnaW5hbCBzeXN0ZW0taWQgaW4gaXRzIExTUCBJRC4NCg0KICAgICBFeHRlbmRlZCBM U1ANCiAgICAgICAgQW4gTFNQIHVzaW5nIGFuIGV4dGVuZGVkIHN5c3RlbS1pZCBpbiBpdHMgTFNQ IElELg0KDQogICAgIExTUCBzZXQNCiAgICAgICAgQSBncm91cCBvZiBMU1AgZnJhZ21lbnRzIGNv bnN0aXR1dGluZyBhIGxvZ2ljYWwgTFNQLiAgVGhlc2UNCiAgICAgICAgc2hhcmUgYSBzcGVjaWZp YyBzeXN0ZW0taWQgYW5kIHBzZXVkb25vZGUgbnVtYmVyLCBhbmQgZGlmZmVyDQogICAgICAgIG9u bHkgaW4gdGhlaXIgTFNQIChvciBmcmFnbWVudCkgbnVtYmVyLg0KDQogICAgIEV4dGVuZGVkIExT UCBzZXQNCiAgICAgICAgQSBncm91cCBvZiBMU1AgZnJhZ21lbnRzIHVzaW5nIGFuIGV4dGVuZGVk IHN5c3RlbS1pZCwgYW5kDQogICAgICAgIG9yaWdpbmF0ZWQgYnkgdGhlIE9yaWdpbmF0aW5nIFN5 c3RlbS4gIFRoZXNlIGZyYWdtZW50cyBhcHBlYXIgdG8NCiAgICAgICAgb3RoZXIgcm91dGVycyBh cyBoYXZpbmcgYmVlbiBvcmlnaW5hdGVkIGJ5IHRoZSBWaXJ0dWFsIFN5c3RlbQ0KICAgICAgICBp ZGVudGlmaWVkIGJ5IGFuIGV4dGVuZGVkIHN5c3RlbS1pZC4NCg0KICAgICBFeHRlbnNpb24tY2Fw YWJsZSBJUw0KICAgICAgICBBbiBJUyBpbXBsZW1lbnRpbmcgdGhpcyBleHRlbnNpb24uDQoNCg0K MS4yICBPcGVyYXRpb24gTW9kZXMNCg0KICAgVHdvIGFkbWluaXN0cmF0aXZlIG9wZXJhdGlvbiBt b2RlcyBhcmUgcHJvdmlkZWQ6DQoNCiAgICAgICAtIE9wZXJhdGlvbiBNb2RlIDEgcHJvdmlkZXMg YmVoYXZpb3IgdGhhdCBhbGxvd3MgcHJldmlvdXMNCiAgICAgICBpbXBsZW1lbnRhdGlvbnMgdG8g Y29ycmVjdGx5IHByb2Nlc3MgdGhlIGV4dGVuZGVkIGZyYWdtZW50DQogICAgICAgaW5mb3JtYXRp b24sIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbnMgdG8gdGhlIFNQRiBhbGdvcml0aG0uDQogICAg ICAgVGhpcyBtb2RlIGhhcyBzb21lIHJlc3RyaWN0aW9ucyBvbiB3aGF0IG1heSBiZSBhZHZlcnRp c2VkIGluIHRoZQ0KICAgICAgIGV4dGVuZGVkIExTUCBmcmFnbWVudHMuICBOYW1lbHksIG9ubHkg bGVhZiBpbmZvcm1hdGlvbiBtYXkgYmUNCiAgICAgICBhZHZlcnRpc2VkIGluIHRoZSBleHRlbmRl ZCBMU1BzLg0KDQogICAgICAgLSAgT3BlcmF0aW9uIE1vZGUgMiBleHRlbmRzIHRoZSBwcmV2aW91 cyBtb2RlIGFuZCByZWxheGVzIGl0cw0KICAgICAgIGFkdmVydGlzZW1lbnQgcmVzdHJpY3Rpb25z LiAgQW55IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gbWF5IGJlDQogICAgICAgYWR2ZXJ0aXNlZCBp biB0aGUgZXh0ZW5kZWQgTFNQcy4gIEhvd2V2ZXIsIGl0IG1hbmRhdGVzIGEgY2hhbmdlDQogICAg ICAgdG8gdGhlIFNQRiBhbGdvcml0aG0sIGluIGEgd2F5IHRoYXQgaXNuJ3QgY29tcGF0aWJsZSB3 aXRoDQogICAgICAgcHJldmlvdXMgaW1wbGVtZW50YXRpb25zLiAgQW4gTDEgYXJlYSwgb3IgdGhl IEwyIGRvbWFpbiwgY2Fubm90DQogICAgICAgYmUgc3dpdGNoZWQgb3ZlciB0byB3b3JrIGluIE1v ZGUgMiwgdW50aWwgYWxsIHJvdXRlcnMgaW4gdGhhdA0KICAgICAgIGRvbWFpbiBoYXZlIGJlZW4g dXBncmFkZWQuDQoNCiAgIFRoZXNlIG1vZGVzIG1heSBiZSBjb25maWd1cmVkIHBlciBsZXZlbC4g IFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uDQogICB0aGF0IGFuIEwxL0wyIElTIG9wZXJhdGVzIGlu IHRoZSBzYW1lIG1vZGUsIGZvciBib3RoIEwxIGFuZCBMMi4NCg0KDQoxLjMgIE92ZXJ2aWV3DQoN CiAgIFVzaW5nIGFkZGl0aW9uYWwgc3lzdGVtLWlkcyBhc3NpZ25lZCBieSB0aGUgYWRtaW5pc3Ry YXRvciwgdGhlDQogICBPcmlnaW5hdGluZyBTeXN0ZW0gY2FuIGFkdmVydGlzZSB0aGUgZXhjZXNz IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gaW4NCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50 ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAg IEF1Z3VzdCAyMDAxDQoNCg0KICAgZXh0ZW5kZWQgTFNQcyB1bmRlciB0aGVzZSBleHRlbmRlZCBz eXN0ZW0taWRzLiAgSXQgd291bGQgZG8gc28gYXMgaWYNCiAgIG90aGVyIHJvdXRlcnMsIG9yICJW aXJ0dWFsIFN5c3RlbXMiLCB3ZXJlIGFkdmVydGlzaW5nIHRoaXMNCiAgIGluZm9ybWF0aW9uLiAg VGhlc2UgZXh0ZW5kZWQgTFNQcyB3aWxsIGFsc28gaGF2ZSB0aGUgc3BlY2lmaWVkIGxpbWl0DQog ICBvbiB0aGVpciBMU1AgZnJhZ21lbnRzOyBob3dldmVyLCB0aGUgT3JpZ2luYXRpbmcgU3lzdGVt IG1heSBnZW5lcmF0ZQ0KICAgZXh0ZW5kZWQgTFNQcyB1bmRlciBudW1lcm91cyBWaXJ0dWFsIFN5 c3RlbXMuDQoNCiAgIFR3byBuZXcgVExWcyBhcmUgaW50cm9kdWNlZDogdGhlIEV4dGVuZGVkIENh cGFiaWxpdGllcyAoRUMpIFRMViBhbmQNCiAgIHRoZSBTaG9ydC1DaXJjdWl0IElTIE5laWdoYm9y IChTQy1JU04pIFRMVi4gIFRoZXNlIFRMVnMgYXJlIG5lY2Vzc2FyeQ0KICAgdG8gY29ycmVjdGx5 IG9wZXJhdGUgaW4gT3BlcmF0aW9uIE1vZGUgMiwgYnV0IGFyZSBhZHZlcnRpc2VkIGJ5IGFsbA0K ICAgZXh0ZW5zaW9uLWNhcGFibGUgSVNzLCByZWdhcmRsZXNzIG9mIHRoZSBtb2RlIHRoZXkgb3Bl cmF0ZS4NCg0KICAgRm9yIE9wZXJhdGlvbiBNb2RlIDEsIDAtY29zdCBhZGphY2VuY2llcyBhcmUg YWR2ZXJ0aXNlZCBmcm9tIHRoZQ0KICAgT3JpZ2luYXRpbmcgU3lzdGVtIHRvIGl0cyBWaXJ0dWFs IFN5c3RlbShzKS4gIE5vIGFkamFjZW5jaWVzIChvdGhlcg0KICAgdGhhbiBiYWNrIHRvIHRoZSBP cmlnaW5hdGluZyBTeXN0ZW0pIGFyZSBhZHZlcnRpc2VkIGluIHRoZSBleHRlbmRlZA0KICAgTFNQ cy4gIEFzIGEgY29uc2VxdWVuY2UsIHRoZSBWaXJ0dWFsIFN5c3RlbXMgYXJlICdzdHViJywgbWVh bmluZyB0aGV5DQogICBjYW4gb25seSBiZSByZWFjaGVkIHRocm91Z2ggdGhlaXIgT3JpZ2luYXRp bmcgU3lzdGVtLiAgVGhlcmVmb3JlLA0KICAgb2xkZXIgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBu ZWVkIHRvIG1vZGlmeSB0aGVpciBTUEYgY29tcHV0YXRpb24gaW4NCiAgIG9yZGVyIHRvIGNvcnJl Y3RseSBwcm9jZXNzIHRoZXNlIGV4dGVuZGVkIExTUHMuDQoNCiAgIEZvciBib3RoIG1vZGVzLCBz aG9ydC1jaXJjdWl0IGFkamFjZW5jaWVzIGFyZSBhZHZlcnRpc2VkIGJldHdlZW4gdGhlDQogICBP cmlnaW5hdGluZyBTeXN0ZW0gYW5kIGl0cyBWaXJ0dWFsIFN5c3RlbShzKS4gIEV4dGVuc2lvbi1j YXBhYmxlIElTcw0KICAgY2FuIHRoZW4gdXNlIHRoaXMgaW5mb3JtYXRpb24gZHVyaW5nIHRoZWly IFNQRiwgYW5kIGNhbiBjb21iaW5lIHRoZQ0KICAgb3JpZ2luYWwgYW5kIGV4dGVuZGVkIExTUHMg aW50byBvbmUgc2luZ2xlIGxvZ2ljYWwgTFNQLg0KDQogICBOb3RlLCB0aGF0IGluIGVpdGhlciBt b2RlLCBubyBjb25uZWN0aW9ucyBhcmUgYWR2ZXJ0aXNlZCBiZXR3ZWVuIHR3bw0KICAgVmlydHVh bCBTeXN0ZW1zLg0KDQoNCjIuMCAgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMVg0KDQogICBUaGUg cHJvcG9zZWQgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMViBhbGxvd3MgYSByb3V0ZXIgdG8gYWR2 ZXJ0aXNlDQogICBzdXBwb3J0IGZvciB0aGlzIGV4dGVuc2lvbiwgYXMgd2VsbCBhcyBvdGhlciBj YXBhYmlsaXRpZXMgdGhhdCBtaWdodA0KICAgYmUgcHJvdmlkZWQgaW4gdGhlIGZ1dHVyZS4gIFRo aXMgVExWIE1VU1QgYXBwZWFyIG9ubHkgaW4gTFNQIE51bWJlcg0KICAgMDsgaXQgU0hPVUxEIGJl IGlnbm9yZWQgd2hlbiBlbmNvdW50ZXJlZCBpbiBvdGhlciBMU1AgZnJhZ21lbnRzLg0KDQogICBU aGUgdHlwZSBvZiB0aGUgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMViBpcyAyMy4gIFRoZSBib2R5 IGNvbnRhaW5zDQogICBvbmx5IHN1Yi1UTFZzLCBpbiB0aGUgZm9ybToNCiAgICAgMC0yNTUgb2N0 ZXRzIG9mIHN1Yi1UTFZzLA0KICAgICAgICB3aGVyZSBlYWNoIHN1Yi1UTFYgY29uc2lzdHMgb2Yg YSBzZXF1ZW5jZSBvZg0KICAgICAgICAgICAxIG9jdGV0IG9mIHN1Yi10eXBlDQogICAgICAgICAg IDEgb2N0ZXQgb2YgbGVuZ3RoDQogICAgICAgICAgIDAtMjUzIG9jdGV0cyBvZiB2YWx1ZQ0KDQog ICBUaGlzIGJvZHkgY2FuIG9ubHkgYXBwZWFyIG9uY2Ugd2l0aGluIGEgVExWOyB0aGVyZWZvcmUs IHRoZSB0b3RhbA0KICAgbGVuZ3RoIG9mIHRoZSBzdWItVExWcyBjYW4gYmUgaW5mZXJyZWQgZnJv bSB0aGUgbGVuZ3RoIG9mIHRoZSBUTFYNCiAgIGl0c2VsZi4gIFRoaXMgVExWIG1heSBiZSByZXBl YXRlZCBtdWx0aXBsZSB0aW1lcywgdG8gZGVzY3JpYmUgbW9yZQ0KICAgaW5mb3JtYXRpb24gdGhh biBjYW4gZml0IGluIGEgc2luZ2xlIFRMVi4NCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50 ZXJuZXQgRHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAg IEF1Z3VzdCAyMDAxDQoNCg0KICAgSW4gYWRkaXRpb24sIGEgbmV3IHN1Yi1UTFYgZm9yIHRoZSBF eHRlbmRlZCBDYXBhYmlsaXRpZXMgVExWIGlzDQogICBwcm9wb3NlZCBoZXJlLiAgVGhpcyBpcyB0 aGUgRXh0ZW5kZWQgTFNQIEZyYWdtZW50cyBDYXBhYmlsaXR5IHN1Yi0NCiAgIFRMVi4gIFJvdXRl cnMgaW1wbGVtZW50aW5nIHRoaXMgZXh0ZW5zaW9uIE1VU1QgaW5jbHVkZSB0aGUgRXh0ZW5kZWQN CiAgIENhcGFiaWxpdGllcyBUTFYsIGFsb25nIHdpdGggdGhlIEV4dGVuZGVkIExTUCBGcmFnbWVu dHMgQ2FwYWJpbGl0eQ0KICAgc3ViLVRMViwgaW4gYm90aCB0aGVpciBvcmlnaW5hbCBhbmQgZXh0 ZW5kZWQgTFNQcy4NCg0KDQoyLjEgIEV4dGVuZGVkIExTUCBGcmFnbWVudHMgQ2FwYWJpbGl0eSBz dWItVExWDQoNCiAgIFRoZSBzdWItVExWIHR5cGUgaXMgMS4gIFRoZSBsZW5ndGggaXMgMSBvY3Rl dCwgY29uc2lzdGluZyBvZiBmbGFncy4NCg0KICAgICAweDAxICBPcGVyYXRpb24gTW9kZSAyDQoN CiAgICAgICBUaGlzIGZsYWcgaXMgc2V0IGlmIHRoZSBJUyBpcyBvcGVyYXRpbmcgaW4gT3BlcmF0 aW9uIE1vZGUgMiwgYW5kDQogICAgICAgdW5zZXQgb3RoZXJ3aXNlLg0KDQogICAgIDB4MDIgIE9y aWdpbmF0aW5nIFN5c3RlbQ0KDQogICAgICAgVGhpcyBmbGFnIGlzIHNldCBpZiB0aGlzIExTUCBp cyBhbiBvcmlnaW5hbCBMU1AgKHRoYXQgaXMsIHRoZQ0KICAgICAgIHN5c3RlbS1pZCBpcyB0aGUg T3JpZ2luYWwgc3lzdGVtLWlkKSwgYW5kIHVuc2V0IG90aGVyd2lzZS4NCg0KDQozLjAgIFNob3J0 LUNpcmN1aXQgSVMgTmVpZ2hib3IgVExWDQoNCiAgIFRoZSBwcm9wb3NlZCBTaG9ydC1DaXJjdWl0 IElTIE5laWdoYm9yIGFsbG93cyBleHRlbnNpb24tY2FwYWJsZSBJU3MNCiAgIHRvIHJlY29nbml6 ZSBhbGwgZXh0ZW5kZWQgTFNQcyBvZiBhbiBPcmlnaW5hdGluZyBTeXN0ZW0sIGFuZCBjb21iaW5l DQogICB0aGUgb3JpZ2luYWwgYW5kIGV4dGVuZGVkIExTUHMgZm9yIHRoZSBwdXJwb3NlIG9mIFNQ RiBjb21wdXRhdGlvbi4NCg0KICAgVGhlIFNob3J0LUNpcmN1aXQgSVMgTmVpZ2hib3IgVExWIGlz IHR5cGUgMjQsIGFuZCBjb250YWlucyBhIG5ldyBkYXRhDQogICBzdHJ1Y3R1cmUsIGNvbnNpc3Rp bmcgb2Y6DQogICAgIDcgb2N0ZXRzIG9mIHN5c3RlbSBJZCBhbmQgcHNldWRvbm9kZSBudW1iZXIN CiAgICAgMSBvY3RldCBvZiBsZW5ndGggb2Ygc3ViLVRMVnMNCiAgICAgMC0yNDcgb2N0ZXRzIG9m IHN1Yi1UTFZzLA0KICAgICAgICB3aGVyZSBlYWNoIHN1Yi1UTFYgY29uc2lzdHMgb2YgYSBzZXF1 ZW5jZSBvZg0KICAgICAgICAgICAxIG9jdGV0IG9mIHN1Yi10eXBlDQogICAgICAgICAgIDEgb2N0 ZXQgb2YgbGVuZ3RoDQogICAgICAgICAgIDAtMjQ1IG9jdGV0cyBvZiB2YWx1ZQ0KDQogICBXaXRo b3V0IHN1Yi1UTFZzLCB0aGlzIHN0cnVjdHVyZSBjb25zdW1lcyA4IG9jdGV0cyBwZXIgc2hvcnQt Y2lyY3VpdA0KICAgbmVpZ2hib3IuICBUbyBpbmRpY2F0ZSBtdWx0aXBsZSBzaG9ydC1jaXRjdWl0 cywgdGhpcyBzdHJ1Y3R1cmUgY2FuIGJlDQogICByZXBlYXRlZCB3aXRoaW4gdGhlIFNob3J0LUNp cmN1aXQgSVMgTmVpZ2hib3IgVExWLiAgQSBzaW5nbGUgVExWIGNhbg0KICAgZGVzY3JpYmUgdXAg dG8gMzEgc2hvcnQtY2lyY3VpdCBuZWlnaGJvcnMuICBUaGlzIFRMViBtYXkgYmUgcmVwZWF0ZWQN CiAgIG11bHRpcGxlIHRpbWVzIHRvIGRlc2NyaWJlIG1vcmUgU0MtbmVpZ2hib3JzLg0KDQoNCjQu MCAgR2VuZXJhdGluZyBMU1BzDQoNCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAgICAgRXhw aXJlcyBGZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQg RHJhZnQgICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAgIEF1Z3Vz dCAyMDAxDQoNCg0KNC4xICBCb3RoIE9wZXJhdGlvbiBNb2Rlcw0KDQogICBVbmRlciBib3RoIG1v ZGVzLCB0aGUgT3JpZ2luYXRpbmcgU3lzdGVtIE1VU1QgaW5jbHVkZSBjb25uZWN0aXZpdHkNCiAg IGluZm9ybWF0aW9uIGluIGl0cyBvcmlnaW5hbCBMU1BzIHRvIGFsbCBWaXJ0dWFsIFN5c3RlbXMg Zm9yIHdoaWNoDQogICBleHRlbmRlZCBMU1BzIGFyZSBnZW5lcmF0ZWQgYnkgaXQsIGFuZCB2aWNl IHZlcnNhLiAgVGhpcyBpcyB0byBlbnN1cmUNCiAgIG90aGVyIHJvdXRlcnMgY29ycmVjdGx5IHBy b2Nlc3MgdGhlIGV4dHJhIGluZm9ybWF0aW9uIGluIHRoZWlyIFNQRg0KICAgY2FsY3VsYXRpb24u ICBUaGlzIGNvbm5lY3Rpdml0eSBpcyBhZHZlcnRpc2VkIHZpYSBhIG5ldyBTaG9ydC1DaXJjdWl0 DQogICBJUyBOZWlnaGJvciBUTFYuICBGdXJ0aGVybW9yZSwgYW4gT3JpZ2luYXRpbmcgU3lzdGVt IG11c3QgYWR2ZXJ0aXNlDQogICB3aGljaCBtb2RlIGl0IGlzIGN1cnJlbnRseSBvcGVyYXRpbmcg aW4uICBUaGlzIGlzIGRvbmUgdXNpbmcgYSBuZXcNCiAgIEV4dGVuZGVkIENhcGFiaWxpdGllcyBU TFYuDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQogICB8ICBPcmlnaW5hdGluZyBTeXN0ZW0gICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg fCAgc3lzdGVtLWlkID0gUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICgg IGV4dGVuZGVkIHN5c3RlbS1pZHMgPSBTJywgIFMnJyAgKSAgICAgICB8DQogICArLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgL1wg ICAgICAgICAgICAgICAgICAgIHwgICAgL1wNCiAgIFNDLUlTTiB8ICAgIHwgU0MtSVNOICAgICAg IFNDLUlTTiB8ICAgIHwgU0MtSVNODQogICAgICAgICAgfCAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCAgICB8DQogICAgICAgICAgXC8gICB8ICAgICAgICAgICAgICAgICAgICAgXC8gICB8DQog ICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAg VmlydHVhbCBTeXN0ZW0gIHwgICAgICAgfCAgVmlydHVhbCBTeXN0ZW0gIHwNCiAgIHwgIHN5c3Rl bS1pZCA9IFMnICB8ICAgICAgIHwgIHN5c3RlbS1pZCA9IFMnJyB8DQogICArLS0tLS0tLS0tLS0t LS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBGaWd1cmUgMS4gQWR2ZXJ0 aXNpbmcgY29ubmVjdGlvbnMgdG8gVmlydHVhbCBTeXN0ZW1zIHVuZGVyIGJvdGggbW9kZXMNCg0K ICAgV2hlbiBuZXcgZXh0ZW5kZWQgTFNQIGZyYWdtZW50cyBhcmUgZ2VuZXJhdGVkLCB0aGVzZSBm cmFnbWVudHMgc2hvdWxkDQogICBiZSBnZW5lcmF0ZWQgYXMgc3BlY2lmaWVkIGluIElTTyAxMDU4 OSBbSVNJUy1JU09dLiAgRnVydGhlcm1vcmUsIGENCiAgIHN5c3RlbSBTSE9VTEQgdHJlYXQgaXRz IGV4dGVuZGVkIExTUHMgdGhlIHNhbWUgYXMgaXQgdHJlYXRzIGl0cw0KICAgb3JpZ2luYWwgTFNQ cywgd2l0aCB0aGUgZXhjZXB0aW9ucyBub3RlZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLg0K ICAgU3BlY2lmaWNhbGx5LCBjcmVhdGluZywgZmxvb2RpbmcsIHJlbmV3aW5nLCBwdXJnaW5nIGFu ZCBhbGwgb3RoZXINCiAgIG9wZXJhdGlvbnMgYXJlIHNpbWlsYXIgZm9yIGJvdGggb3JpZ2luYWwg YW5kIGV4dGVuZGVkIExTUHMsIHVubGVzcw0KICAgc3RhdGVkIG90aGVyd2lzZS4gIFRoZSBleHRl bmRlZCBMU1BzIHdpbGwgdXNlIG9uZSBvZiB0aGUgZXh0ZW5kZWQNCiAgIHN5c3RlbS1pZHMgY29u ZmlndXJlZCBmb3IgdGhlIHJvdXRlciwgaW4gdGhlaXIgTFNQIElELg0KDQogICBFeHRlbmRlZCBM U1BzIHdpdGggbnVtYmVyIHplcm8gc2hvdWxkIGJlIHJlZ2FyZGVkIGluIHRoZSBzYW1lIHNwZWNp YWwNCiAgIG1hbm5lciBhcyBzcGVjaWZpZWQgaW4gMTA1ODkgZm9yIExTUHMgd2l0aCBudW1iZXIg emVybywgYW5kIHNob3VsZA0KICAgaW5jbHVkZSB0aGUgc2FtZSB0eXBlIG9mIGV4dHJhIGluZm9y bWF0aW9uIGFzIHNwZWNpZmllZCBpbiAxMDU4OSBhbmQNCiAgIFJGQyAxMTk1IFtJU0lTLUlQXS4g IFNvLCBmb3IgZXhhbXBsZSwgd2hlbiBhIHN5c3RlbSByZWlzc3VlcyBpdHMgTFNQDQogICBOdW1i ZXIgemVybyBkdWUgdG8gYW4gYXJlYSBhZGRyZXNzIGNoYW5nZSwgaXQgc2hvdWxkIHJlaXNzdWUg YWxsDQogICBleHRlbmRlZCBMU1BzIHdpdGggbnVtYmVyIHplcm8gYXMgd2VsbC4NCg0KICAgQW4g ZXh0ZW5kZWQgTFNQIE51bWJlciB6ZXJvIE1VU1QgYmUgZ2VuZXJhdGVkIGZvciBldmVyeSBleHRl bmRlZCBMU1ANCiAgIHNldCwgdG8gYWxsb3cgYSByb3V0ZXIncyBTUEYgY2FsY3VsYXRpb24gdG8g Y29uc2lkZXIgdGhvc2UgZnJhZ21lbnRzDQogICBpbiB0aGF0IHNldC4NCg0KDQoNCg0KQS4gSGVy bWVsaW4gICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMDIgICAgICAgICAgICAgICAg IFtQYWdlIDZdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgZHJhZnQtaGVybWVsaW4tZXh0LWxzcC1m cmFncy0wMi50eHQgICAgICAgQXVndXN0IDIwMDENCg0KDQo0LjEuMyAgVGhlIEF0dGFjaGVkIEJp dHMNCg0KICAgVGhlIEF0dGFjaGVkIChBVFQpIGJpdHMgU0hPVUxEIGJlIHNldCB0byB6ZXJvIGZv ciBhbGwgZm91ciBtZXRyaWMNCiAgIHR5cGVzLCBvbiBhbGwgZXh0ZW5kZWQgTFNQcy4gIFRoaXMg aXMgZHVlIHRvIHRoZSBmb2xsb3dpbmc6IGlmIGENCiAgIFZpcnR1YWwgU3lzdGVtIGlzIHJlYWNo YWJsZSwgc28gaXMgaXRzIE9yaWdpbmF0aW5nIFN5c3RlbS4gIEl0IGlzDQogICBwcmVmZXJhYmxl LCB0aGVuLCB0aGF0IGFuIEwxIElTIGNob29zZXMgdGhlIE9yaWdpbmF0aW5nIFN5c3RlbSBhbmQN CiAgIG5vdCB0aGUgVmlydHVhbCBTeXN0ZW0gYXMgaXRzIG5lYXJlc3QgTDIgZXhpdCBwb2ludCwg YXMgY29ubmVjdGl2aXR5DQogICB0byB0aGUgVmlydHVhbCBTeXN0ZW0gaGFzIGEgaGlnaGVyIHBy b2JhYmlsaXR5IG9mIGJlaW5nIGxvc3QgKGENCiAgIHJlc3VsdCBvZiB0aGUgZXh0ZW5kZWQgTFNQ IG5vIGxvbmdlciBiZWluZyBhZHZlcnRpc2VkKS4gIFRoaXMgY291bGQNCiAgIGNhdXNlIHVubmVj ZXNzYXJ5IHByb2Nlc3Npbmcgb24gc29tZSBpbXBsZW1lbnRhdGlvbnMuDQoNCg0KNC4xLjQgIFRo ZSBQYXJ0aXRpb24gUmVwYWlyIEJpdA0KDQogICBUaGUgUGFydGl0aW9uIFJlcGFpciAoUCkgYml0 IFNIT1VMRCBiZSBzZXQgdG8gemVybyBvbiBhbGwgZXh0ZW5kZWQNCiAgIExTUHMuICBUaGlzIGlz IGZvciB0aGUgc2FtZSByZWFzb25zIGFzIGZvciB0aGUgQXR0YWNoZWQgYml0cy4NCg0KDQo0LjEu MSAgRVMgTmVpZ2hib3JzIFRMVg0KDQogICBJU08gMTA1ODkgW0lTSVMtSVNPXSBzZWN0aW9uIDcu My43IHNwZWNpZmllcyBpbnNlcnRpbmcgYW4gRVMgTmVpZ2hib3INCiAgIFRMViBpbiBMMSBMU1Bz LCB3aXRoIHRoZSBzeXN0ZW0gSUQgb2YgdGhlIHJvdXRlci4gIFJGQyAxMTk1IFtJU0lTLUlQXQ0K ICAgcmVsaWV2ZXMgSVAtb25seSByb3V0ZXJzIG9mIHRoaXMgcmVxdWlyZW1lbnQuICBIb3dldmVy LCBmb3Igcm91dGVycw0KICAgdGhhdCBkbyBpbnNlcnQgdGhpcyBFU04gVExWIGluIEwxIExTUHMg KHdoZXRoZXIgSVAtb25seSBvciBPU0ktDQogICBjYXBhYmxlKSwgdGhlbiBpbiBhbiBleHRlbmRl ZCBMU1AsIHRoZSBFU04gVExWIHNob3VsZCBpbmNsdWRlIHRoZQ0KICAgcmVsZXZhbnQgZXh0ZW5k ZWQgc3lzdGVtLWlkLiAgRnVydGhlcm1vcmUsIE9TSS1jYXBhYmxlIHJvdXRlcnMgc2hvdWxkDQog ICBhY2NlcHQgcGFja2V0cyBkZXN0aW5lZCBmb3IgdGhpcyBleHRlbmRlZCBzeXN0ZW0taWQuDQoN Cg0KNC4yICBPcGVyYXRpb24gTW9kZSAxIEFkZGl0aW9ucw0KDQogICBUaGUgZm9sbG93aW5nIGFk ZGl0aW9ucyBhcHBseSBvbmx5IHRvIHJvdXRlcnMgb3BlcmF0aW5nIGluIE1vZGUgMS4NCiAgIFJv dXRlcnMsIHdoaWNoIGFyZSBjb25maWd1cmVkIHRvIG9wZXJhdGUgaW4gT3BlcmF0aW9uIE1vZGUg MiwgTVVTVA0KICAgTk9UIGFwcGx5IHRoZXNlIGFkZGl0aW9ucyB0byB0aGVpciBhZHZlcnRpc2Vt ZW50cy4NCg0KICAgVW5kZXIgT3BlcmF0aW9uIE1vZGUgMSwgdGhlIGFkamFjZW5jaWVzIG11c3Qg YWxzbyBiZSBhZHZlcnRpc2VkIHVzaW5nDQogICB0aGUgc3RhbmRhcmQgbmVpZ2hib3IgVExWcy4g IFRoZSBtZXRyaWMgZm9yIHRoZXNlIGNvbm5lY3Rpb25zIE1VU1QgYmUNCiAgIHplcm8sIHNpbmNl IHRoZSBjb3N0IG9mIHJlYWNoaW5nIGEgVmlydHVhbCBTeXN0ZW0gaXMgdGhlIHNhbWUgYXMgdGhl DQogICBjb3N0IG9mIHJlYWNoaW5nIGl0cyBPcmlnaW5hdGluZyBTeXN0ZW0uDQoNCiAgIFRvIG9s ZGVyIGltcGxlbWVudGF0aW9ucywgVmlydHVhbCBTeXN0ZW1zIHdvdWxkIGFwcGVhciByZWFjaGFi bGUgb25seQ0KICAgdGhyb3VnaCB0aGVpciBPcmlnaW5hdGluZyBTeXN0ZW0sIGhlbmNlIGxvc3Mg b2YgY29ubmVjdGl2aXR5IHRvIHRoZQ0KICAgT3JpZ2luYXRpbmcgU3lzdGVtIG1lYW5zIGxvc3Mg b2YgY29ubmVjdGl2aXR5IHRvIGFsbCBvZiBpdHMNCiAgIGluZm9ybWF0aW9uLCBpbmNsdWRpbmcg dGhhdCBhZHZlcnRpc2VkIGluIGl0cyBleHRlbmRlZCBMU1BzLg0KICAgRnVydGhlcm1vcmUsIHRo ZSBjb3N0IG9mIHJlYWNoaW5nIGluZm9ybWF0aW9uIGFkdmVydGlzZWQgaW4gbm9uLQ0KICAgZXh0 ZW5kZWQgTFNQcyBpcyB0aGUgc2FtZSBhcyB0aGUgY29zdCBvZiByZWFjaGluZyBpbmZvcm1hdGlv bg0KICAgYWR2ZXJ0aXNlZCBpbiB0aGUgbmV3IGV4dGVuZGVkIExTUHMsIHdpdGggYW4gYWRkaXRp b25hbCBob3AuDQoNCg0KDQpBLiBIZXJtZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVh cnkgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0IERyYWZ0ICAgICBk cmFmdC1oZXJtZWxpbi1leHQtbHNwLWZyYWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoN CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8 ICBPcmlnaW5hdGluZyBTeXN0ZW0gICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgc3lz dGVtLWlkID0gUyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICggIGV4dGVu ZGVkIHN5c3RlbS1pZHMgPSBTJywgIFMnJyAgKSAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgIHwgICAgL1wgICAgICAg ICAgICAgICAgICAgIHwgICAgL1wNCiAgIGNvc3Q9MCB8ICAgIHxjb3N0PW1heC0xICAgIGNvc3Q9 MCB8ICAgIHxjb3N0PW1heC0xDQogICAgICAgICAgfCAgICB8ICAgICAgICAgICAgICAgICAgICAg fCAgICB8DQogICAgICAgICAgXC8gICB8ICAgICAgICAgICAgICAgICAgICAgXC8gICB8DQogICAr LS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgVmly dHVhbCBTeXN0ZW0gIHwgICAgICAgfCAgVmlydHVhbCBTeXN0ZW0gIHwNCiAgIHwgIHN5c3RlbS1p ZCA9IFMnICB8ICAgICAgIHwgIHN5c3RlbS1pZCA9IFMnJyB8DQogICArLS0tLS0tLS0tLS0tLS0t LS0tKyAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICBGaWd1cmUgMi4gQWR2ZXJ0aXNp bmcgYWRkaXRpb25hbCBjb25uZWN0aW9ucyB0byBWaXJ0dWFsIFN5c3RlbXMgdW5kZXINCiAgIE9w ZXJhdGlvbiBNb2RlIDENCg0KICAgVW5kZXIgT3BlcmF0aW9uIE1vZGUgMSwgb25seSAibGVhZiIg aW5mb3JtYXRpb24sIGkuZS4gaW5mb3JtYXRpb24NCiAgIHRoYXQgc2VydmVzIG9ubHkgYXMgbGVh dmVzIGluIGEgc2hvcnRlc3QgcGF0aCB0cmVlLCBjYW4gYmUgYWR2ZXJ0aXNlZA0KICAgaW4gZXh0 ZW5kZWQgTFNQcy4NCg0KICAgV2hlbiBhbiBleHRlbmRlZCBMU1AgYmVsb25naW5nIHRvIGV4dGVu ZGVkIHN5c3RlbS1pZCBTJyBpcyBmaXJzdA0KICAgY3JlYXRlZCwgdGhlIG9yaWdpbmFsIExTUCBN VVNUIHNwZWNpZnkgUycgYXMgYSBuZWlnaGJvciwgd2l0aCBtZXRyaWMNCiAgIHNldCB0byB6ZXJv LiAgVGhpcyBpcyB0byBlbnN1cmUgb3RoZXIgcm91dGVycyB3aWxsIGNvbnNpZGVyIHRoZQ0KICAg ZXh0ZW5kZWQgTFNQIGluIHRoZWlyIFNQRiBjb21wdXRhdGlvbnMsIGFzIHdlbGwgYXMgY29uc2lk ZXIgdGhlIGNvc3QNCiAgIG9mIHJlYWNoaW5nIHRoZSBWaXJ0dWFsIFN5c3RlbSBTJyB0aGUgc2Ft ZSBhcyB0aGUgY29zdCBvZiByZWFjaGluZw0KICAgaXRzIE9yaWdpbmF0aW5nIFN5c3RlbS4gIEZ1 cnRoZXJtb3JlLCB0aGUgZXh0ZW5kZWQgTFNQIE1VU1Qgc3BlY2lmeQ0KICAgdGhlIG9yaWdpbmFs IHN5c3RlbS1pZCBhcyBhIG5laWdoYm9yLCB3aXRoIG1ldHJpYyBzZXQgdG8NCiAgIChNYXhMaW5r TWV0cmljIC0gMSkuICBXaGVyZSByZWxldmFudCwgdGhpcyBhZGphY2VuY3kgU0hPVUxEIGJlDQog ICBjb25zaWRlcmVkIGFzIHBvaW50LXRvLXBvaW50Lg0KDQogICBOb3RlLCB0aGF0IHRoZSByZXN0 cmljdGlvbiBzcGVjaWZpZWQgaW4gSVNPIDEwNTg5IHNlY3Rpb24gNy4yLjUNCiAgIGhvbGRzOiAg aWYgYW4gTFNQIE51bWJlciB6ZXJvIG9mIHRoZSBPcmlnaW5hdGluZyBTeXN0ZW0gaXMgbm90DQog ICBwcmVzZW50LCBub25lIG9mIHRoYXQgc3lzdGVtJ3MgbmVpZ2hib3IgZW50cmllcyB3b3VsZCBi ZSBwcm9jZXNzZWQNCiAgIGR1cmluZyBTUEYsIGhlbmNlIG5vbmUgb2YgaXRzIGV4dGVuZGVkIExT UHMgd291bGQgYmUgcHJvY2Vzc2VkIGFzDQogICB3ZWxsLg0KDQoNCjQuMi4xICBJUyBOZWlnaGJv cnMgVExWDQoNCiAgIEFuIEV4dGVuZGVkIExTUCBtdXN0IHNwZWNpZnkgb25seSB0aGUgT3JpZ2lu YXRpbmcgU3lzdGVtIGFzIGENCiAgIG5laWdoYm9yLCB3aXRoIHRoZSBtZXRyaWMgc2V0IHRvIChN YXhMaW5rTWV0cmljIC0gMSkuICBXaGVyZQ0KICAgcmVsZXZhbnQsIHRoaXMgYWRqYWNlbmN5IHNo b3VsZCBiZSBjb25zaWRlcmVkIGFzIHBvaW50LXRvLXBvaW50Lg0KICAgT3RoZXIgbmVpZ2hib3Jz IE1VU1QgTk9UIGJlIHNwZWNpZmllZCBpbiBhbiBFeHRlbmRlZCBMU1AsIGFzIHRoaXMNCiAgIHdv dWxkIG5vdCBzYXRpc2Z5IHRoZSBiaS1kaXJlY3Rpb25hbGl0eSBjaGVjayBpbiB0aGUgU1BGIGNv bXB1dGF0aW9uLg0KDQoNCg0KDQoNCkEuIEhlcm1lbGluICAgICAgICAgICAgICAgRXhwaXJlcyBG ZWJydWFyeSAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQgRHJhZnQg ICAgIGRyYWZ0LWhlcm1lbGluLWV4dC1sc3AtZnJhZ3MtMDIudHh0ICAgICAgIEF1Z3VzdCAyMDAx DQoNCg0KNS4gIFB1cmdpbmcgRXh0ZW5kZWQgTFNQIEZyYWdtZW50cw0KDQogICBJU08gMTA1ODkg W0lTSVMtSVNPXSBzZWN0aW9uIDcuMy40LjQgbm90ZSAyMSBzdWdnZXN0cyB0aGF0IGFuDQogICBp bXBsZW1lbnRhdGlvbiBrZWVwcyB0aGUgbnVtYmVyIG9mIExTUCBmcmFnbWVudHMgd2l0aGluIGEg Y2VydGFpbg0KICAgbGltaXQgYmFzZWQgb24gdGhlIG9wdGltYWwgKG1pbmltYWwpIG51bWJlciBv ZiBmcmFnbWVudHMgbmVlZGVkLg0KICAgU2VjdGlvbiA3LjMuNC42IGFsc28gcmVjb21tZW5kcyB0 aGF0IGFuIElTIHB1cmdlIGl0cyBlbXB0eSBMU1BzIHRvDQogICBjb25zZXJ2ZSByZXNvdXJjZXMu ICBUaGVzZSByZWNvbW1lbmRhdGlvbnMgaG9sZCBmb3IgdGhlIGV4dGVuZGVkIExTUA0KICAgZnJh Z21lbnRzIGFzIHdlbGwuICBIb3dldmVyLCBhbiBleHRlbmRlZCBMU1AgTnVtYmVyIHplcm8gc2hv dWxkIG5vdA0KICAgYmUgcHVyZ2VkIHVudGlsIGFsbCBvZiB0aGUgZnJhZ21lbnRzIGluIGl0cyBz ZXQgKGkuZS4gYmVsb25naW5nIHRvIGENCiAgIHBhcnRpY3VsYXIgZXh0ZW5kZWQgc3lzdGVtLWlk KSwgYXJlIGVtcHR5IGFzIHdlbGwuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgaW1wbGVtZW50YXRp b25zIGNvbnNpZGVyIHRoZSBmcmFnbWVudHMgaW4gdGhlaXIgU1BGIGNvbXB1dGF0aW9ucywgYXMN CiAgIHNwZWNpZmllZCBpbiBzZWN0aW9uIDcuMi41Lg0KDQogICBXaGVuIGFsbCB0aGUgZXh0ZW5k ZWQgTFNQIGZyYWdtZW50cyBvZiBhIHBhcnRpY3VsYXIgZXh0ZW5kZWQgc3lzdGVtLQ0KICAgaWQg UycgaGF2ZSBiZWVuIHB1cmdlZCwgdGhlIE9yaWdpbmF0aW5nIFN5c3RlbSBTSE9VTEQgcmVtb3Zl IHRoZQ0KICAgbmVpZ2hib3IgaW5mb3JtYXRpb24gdG8gUycgZnJvbSBpdHMgb3JpZ2luYWwgTFNQ cyAoZm9yIGJvdGggSVMgYW5kDQogICBTaG9ydC1DaXJjdWl0KS4NCg0KDQo2LiAgTW9kaWZpY2F0 aW9ucyB0byB0aGUgU1BGDQoNCiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgbW9kaWZpY2F0aW9u cyB0byB0aGUgU1BGIHJ1bm5pbmcgb24gcm91dGVycw0KICAgaW1wbGVtZW50aW5nIHRoaXMgZXh0 ZW5zaW9uLg0KDQogICBBIHJvdXRlciBvcGVyYXRpbmcgaW4gTW9kZSAxLCBhbmQgcHJvY2Vzc2lu ZyBhbiBMU1Agb2YgYW5vdGhlciByb3V0ZXINCiAgIG9wZXJhdGluZyBpbiBNb2RlIDEsIE1BWSBp Z25vcmUgdGhlc2UgbW9kaWZpY2F0aW9ucyBhbmQgcnVuIGEgbm9ybWFsDQogICBTUEYuICBUaGlz IGlzIGNvbnNpc3RlbnQgd2l0aCBvdGhlciBub24tZXh0ZW5zaW9uLWNhcGFibGUgcm91dGVycyBp bg0KICAgdGhlIG5ldHdvcmsuDQoNCiAgIEEgcm91dGVyIG9wZXJhdGluZyBpbiBNb2RlIDIsIG9y IHByb2Nlc3NpbmcgYW4gTFNQIG9mIGFub3RoZXIgcm91dGVyDQogICBvcGVyYXRpbmcgaW4gTW9k ZSAyLCBNVVNUIHJ1biB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbnMgdG8gdGhlIFNQRi4NCg0K ICAgV2hlbiBjb25zaWRlcmluZyBMU1BzIG9mIGFuIGV4dGVuc2lvbi1jYXBhYmxlIElTLCB0aGUg b3JpZ2luYWwgYW5kDQogICBleHRlbmRlZCBMU1BzIGFyZSBjb21iaW5lZCB0byBmb3JtIG9uZSBs YXJnZSBsb2dpY2FsIExTUC4gIElmIHRoZSBMU1ANCiAgIGlzIE9wZXJhdGlvbmFsIE1vZGUgMSwg YW5kIHRoZXJlIGFyZSBhZGphY2VuY2llcyBiZXR3ZWVuIHRoZSBvcmlnaW5hbA0KICAgYW5kIGV4 dGVuZGVkIExTUHMsIHRoZXNlIGFyZSBpZ25vcmVkLiAgVGhpcyBjaGVjayBjb3VsZCBiZSBlYXNp bHkNCiAgIGRvbmUgKGFzIHRoZSBMU1BzIGFyZSB0aWVkIHRvZ2V0aGVyKSwgYW5kIGRvZXNuJ3Qg Y29tcGxpY2F0ZSB0aGUgU1BGLg0KDQogICBJZiB0aGUgTFNQIG51bWJlciAwIG9mIHRoZSBvcmln aW5hbCBMU1Agc2V0IGlzIG1pc3NpbmcsIGFsbCBvZiB0aGUNCiAgIExTUHMgZ2VuZXJhdGVkIGJ5 IHRoYXQgT3JpZ2luYXRpbmcgU3lzdGVtIChleHRlbmRlZCBhcyB3ZWxsKSBNVVNUIE5PVA0KICAg YmUgY29uc2lkZXJlZCBpbiB0aGUgU1BGLiAgVGhpcyBpcyBlYXNpbHkgZGV0ZXJtaW5lZCBmcm9t IHRoZQ0KICAgRXh0ZW5kZWQgQ2FwYWJpbGl0aWVzIFRMVi4gIElmIGFuIExTUCBudW1iZXIgMCBv ZiBhbiBleHRlbmRlZCBMU1Agc2V0DQogICBpcyBtaXNzaW5nLCBvbmx5IHRoYXQgTFNQIHNldCBN VVNUIE5PVCBiZSBjb25zaWRlcmVkIGluIHRoZSBTUEYuDQoNCiAgIE5vdGUsIHRoYXQgdGhlIGFi b3ZlIGJlaGF2aW9yIGlzIGNvbnNpc3RlbnQgd2l0aCBob3cgcHJldmlvdXMNCiAgIGltcGxlbWVu dGF0aW9ucyB3aWxsIGludGVycHJldCBNb2RlIDEgTFNQcy4NCg0KDQoNCg0KQS4gSGVybWVsaW4g ICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIwMDIgICAgICAgICAgICAgICAgIFtQYWdl IDldDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgZHJhZnQtaGVybWVsaW4tZXh0LWxzcC1mcmFncy0w Mi50eHQgICAgICAgQXVndXN0IDIwMDENCg0KDQo3LiAgRm9ybWluZyBBZGphY2VuY2llcw0KDQog ICBJdCBzaG91bGQgYmUgbm90ZWQsIHRoYXQgYW4gSVMgbXVzdCB1c2UgdGhlIHN5c3RlbS1pZCBv ZiB0aGUgTFNQIHRoYXQNCiAgIHdpbGwgaW5jbHVkZSBhIG5laWdoYm9yLCB3aGVuIGZvcm1pbmcg YW4gYWRqYWNlbmN5IHdpdGggdGhhdA0KICAgbmVpZ2hib3IuICBUaGF0IGlzLCBpZiBhIG5laWdo Ym9yIGlzIHRvIGJlIGluY2x1ZGVkIGluIGV4dGVuZGVkIExTUA0KICAgUycsIHRoZW4gUycgc2hv dWxkIGJlIHVzZWQgYXMgdGhlIHN5c3RlbS1pZCBpbiBJUyBIZWxsb3MgWzNdIGFuZCBJUy0NCiAg IElTIEhlbGxvcyB3aGVuIGZvcm1pbmcgYW4gYWRqYWNlbmN5IHdpdGggdGhhdCBuZWlnaGJvci4g IFRoaXMgaXMNCiAgIHJlZ2FyZGxlc3Mgb2YgdGhlIE9wZXJhdGlvbmFsIE1vZGUuICBPZiBjb3Vy c2UsIGluIE1vZGUgMSB0aGlzIG1lYW5zDQogICB0aGF0IG9ubHkgdGhlIG9yaWdpbmFsIHN5c3Rl bS1pZCB3aWxsIGJlIHVzZWQgd2hlbiBzZW5kaW5nIGhlbGxvcy4NCg0KDQo4LiAgVHJhbnNpdGlv bmluZyB0aGUgTmV0d29yaw0KDQogICBBcyBub3RlZCBlYXJsaWVyLCBpbiBvcmRlciB0byBjb3Jy ZWN0bHkgcnVuIGluIE9wZXJhdGlvbiBNb2RlIDIsIGFsbA0KICAgSVNzIGluIGFuIGFyZWEgbXVz dCBiZSBleHRlbnNpb24tY2FwYWJsZS4gSG93ZXZlciwgaXQgaXMgcG9zc2libGUgdG8NCiAgIHRy YW5zaXRpb24gYSBsaXZlIG5ldHdvcmssIHVzaW5nIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQogICAg IC0gVXBncmFkZSB0aGUgcm91dGVycywgb25lLWJ5LW9uZSwgdG8gcnVuIHRoaXMgZXh0ZW5zaW9u IGluDQogICAgIE9wZXJhdGlvbiBNb2RlIDEuIFRoZSBvdGhlciBub24tZXh0ZW5zaW9uLWNhcGFi bGUgcm91dGVycyB3aWxsDQogICAgIGludGVyb3BlcmF0ZSBjb3JyZWN0bHkuDQogICAgIC0gV2hl biBhbGwgcm91dGVycyBhcmUgZXh0ZW5zaW9uLWNhcGFibGUsIGNvbmZpZ3VyZSB0aGVtIG9uZS1i eS1vbmUNCiAgICAgdG8gcnVuIGluIE9wZXJhdGlvbiBNb2RlIDIuICBBbGwgZXh0ZW5zaW9uLWNh cGFibGUgcm91dGVycw0KICAgICBpbnRlcm9wZXJhdGUgY29ycmVjdGx5LCByZWdhcmRsZXNzIG9m IHdoYXQgbW9kZSB0aGV5J3JlIHJ1biBpbi4NCg0KDQo5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMNCg0KICAgVGhpcyBkb2N1bWVudCByYWlzZXMgbm8gbmV3IHNlY3VyaXR5IGlzc3VlcyBmb3Ig SVMtSVMuDQoNCg0KMTAuICBBY2tub3dsZWRnbWVudHMNCg0KICAgVGhlIGF1dGhvciB3b3VsZCBs aWtlIHRvIHRoYW5rIFRvbnkgTGksIFJhZGlhIFBlcmxtYW4sIGFuZCBNaWtlIFNoYW5kDQogICBm b3IgaGVscGZ1bCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgb24gdGhlIHN1YmplY3QuDQoNCg0K MTEuICBSZWZlcmVuY2VzDQoNCiAgIFtJU0lTLUlTT10gSVNPIDEwNTg5LCAiSW50ZXJtZWRpYXRl IFN5c3RlbSB0byBJbnRlcm1lZGlhdGUgU3lzdGVtDQogICBJbnRyYS1Eb21haW4gUm91dGVpbmcg RXhjaGFuZ2UgUHJvdG9jb2wgZm9yIHVzZSBpbiBDb25qdW5jdGlvbiB3aXRoDQogICB0aGUgUHJv dG9jb2wgZm9yIFByb3ZpZGluZyB0aGUgQ29ubmVjdGlvbmxlc3MtbW9kZSBOZXR3b3JrIFNlcnZp Y2UNCiAgIChJU08gODQ3MykiDQoNCiAgIFtJU0lTLUlQXSBSRkMgMTE5NSwgIlVzZSBvZiBPU0kg SVMtSVMgZm9yIHJvdXRpbmcgaW4gVENQL0lQIGFuZCBkdWFsDQogICBlbnZpcm9ubWVudHMiLCBS LlcuIENhbGxvbiwgRGVjLiAxOTkwDQoNCiAgIFtFUy1JU10gSVNPIDk1NDIsICJFbmQgU3lzdGVt IHRvIEludGVybWVkaWF0ZSBTeXN0ZW0gUm91dGVpbmcNCiAgIEV4Y2hhbmdlIFByb3RvY29sIGZv ciBVc2UgaW4gQ29uanVuY3Rpb24gd2l0aCB0aGUgUHJvdG9jb2wgZm9yDQoNCg0KDQpBLiBIZXJt ZWxpbiAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMjAwMiAgICAgICAgICAgICAgICBb UGFnZSAxMF0NCgwNCkludGVybmV0IERyYWZ0ICAgICBkcmFmdC1oZXJtZWxpbi1leHQtbHNwLWZy YWdzLTAyLnR4dCAgICAgICBBdWd1c3QgMjAwMQ0KDQoNCiAgIFByb3ZpZGluZyB0aGUgQ29ubmVj dGlvbmxlc3MtTW9kZSBOZXR3b3JrIFNlcnZpY2UgKElTTyA4NDczKSIsIE1hcmNoDQogICAxOTg4 DQoNCiAgIFtET01BSU4tV0lERV0gUkZDIDI5NjYsICJEb21haW4td2lkZSBQcmVmaXggRGlzdHJp YnV0aW9uIHdpdGggVHdvLQ0KICAgTGV2ZWwgSVMtSVMiLCBULiBMaSwgVC4gUHJ6eWdpZW5kYSwg SC4gU21pdCwgT2N0b2JlciAyMDAwDQoNCiAgIFtCQ1AxNF0gUkZDIDIxMTksICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50DQogICBMZXZlbHMiLCBTLiBC cmFkbmVyLCBNYXJjaCAxOTk3DQoNCg0KMTIuICBBdXRob3IncyBBZGRyZXNzDQoNCiAgIEFtaXIg SGVybWVsaW4NCiAgIENoYXJsb3R0ZSdzIFdlYiBOZXR3b3JrcywgSW5jLg0KICAgMiBIYSdtYWRh IFN0Lg0KICAgUE9CIDY1MA0KICAgWW9rbmVhbSwgMjA2OTINCiAgIElTUkFFTA0KDQogICBFbWFp bDogYW1pckBjd250LmNvbQ0KICAgUGhvbmU6ICs5NzIgNCA5NTkyMjAzDQogICBGYXg6ICAgKzk3 MiA0IDk1OTMzMjUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KQS4gSGVybWVsaW4gICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDIw MDIgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQo= ------_=_NextPart_001_01C12581.12689795-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 16 15:29:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20641 for ; Thu, 16 Aug 2001 15:29:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA43393; Thu, 16 Aug 2001 12:37:28 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA43381 for ; Thu, 16 Aug 2001 12:36:20 -0700 (PDT) Message-ID: From: Jeff Parker To: "'gash@att.com'" Cc: "'isis-wg@spider.juniper.net'" , "'amaunder@Sanera.net'" , "'OSPF@DISCUSS.MICROSOFT.COM'" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Comments on < draft-ash-ospf-isis-congestion-control-00.txt > Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 16 Aug 2001 15:27:44 -0400 Jerry - I've been reading your draft < draft-ash-ospf-isis-congestion-control-00.txt > with interest. Here are a few editorial comments. I also have some questions about your scenarios in order to reproduce them here. I think it would be good to have a well understood stress test that reflects an interesting test case, rather than another round of line-rate forwarding or connections per second test. > b) how a node might control its workload once congestion is detected, > such as through > * the throttling of new connection setups, topology-status updates, > and Hello updates with the use of automatic congestion control mechanisms, 1) Perhaps the title should mention PNNI: I'm not sure which connection setups you would want to restrict in OSPF or ISIS. 2) I'm not sure that you really mean "throttling... Hello updates". In your next paragraph, you advocate special handling of Hello Messages to assure they go through. > * Inability to segment the network (into smaller "peer groups") to aid > in the LS protocol recovery I'm not sure what you are asking for here. There is no obstacle in either OSPF or ISIS to create small peer groups. In fact, your sample has very small (4) peer groups. Do you want to reconfigure on the fly? Do you want more levels of hierarchy? > 2.2 Vendor Analysis of Product Performance > Various vendors and service providers were asked to analyze their product > with reference to how their LS protocol recovers from a total network > failure, that is, loss of all database information in the specified > scenario. The specification of the failure presented to the vendors made > the following assumptions: > 1. 400 node network is considered > a) 100 backbone nodes > b) 3 edge nodes per backbone node (Edge single homed) > c) Each backbone node is connected to no more than 10 nodes (maximum > node adjacency is 13, which defines a sparse network) > 1. There are 101 areas > a) 1 backbone area with 100 backbone nodes > b) 100 edge areas, each with 3 nodes, all homed on the backbone peer > group > 1. 1,000,000 addresses are advertised in the network > 2. maximum node adjacency is 13 > a) sparse network I found the numbering confusing, and don't know if this is one specification or three. This might mean * 300 Edge Nodes * 100 Backbone nodes. - Each backbone node connects to 3 edge nodes - Each backbone node connects to 10 other backbone nodes - Each cluster of 3 edge nodes and backbone router forms a single unique area - Each edge node advertises 3.333K routes but other configurations are possible. I would be interested to know how your backbone routers are connected to each other. > During the study, a TSU > storm of size X is created at instant of time 100 seconds where storm-size > is defined as the number of TSUs generated during a storm. Three cases are > considered with X = 300, 600 and 900 respectively. Can you clarify who originates these 300*X packets? Is it the edge routers? What are the sizes of the packets, and what are the contents? For example, I assume that you don't simply have two versions of each edge router's topology and send one then the other. These details are probably in the paper [choudhury] cited. Is that paper publically available yet? Perhaps you could define the test you describe in enough detail to provide an interesting synthetic test of general utility. I'm sure AT&T would love to push back this test from your labs to your suppliers. If the description is clear cut enough, some of the test vendors might be able to produce equipment that could direct such a storm at a device under test. May I be the first to suggest the name "Link Adjacency Stability Test, G. Ash Switch Profiler", or LAST GASP. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 11:04:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04508 for ; Fri, 17 Aug 2001 11:04:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48029; Fri, 17 Aug 2001 08:11:29 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48017 for ; Fri, 17 Aug 2001 08:10:59 -0700 (PDT) Received: (qmail 65984 invoked from network); 17 Aug 2001 15:02:26 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Aug 2001 15:02:26 -0000 From: "Ken Larmer" To: "Isis-Wg@Spider. Juniper. Net" Cc: "Ken Larmer" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [Isis-wg] Action on receipt of LSP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 11:04:24 -0400 Content-Transfer-Encoding: 7bit Hi, ISO-10589 states the action to take when receiving certain LSPs (Newer, Same, Older...). The specification does not state what to do when you receive a LSP, which contains the same LSPID, Sequence Number but with different Remaining Lifetime values, i.e. the LSP Database Entry has Remaining Lifetime = 0 and the received LSP has Remaining Lifetime = 1199. What should we do in this situation? Should we return the expired LSP to the source? Cheers, Ken _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 11:31:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05327 for ; Fri, 17 Aug 2001 11:31:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48213; Fri, 17 Aug 2001 08:39:29 -0700 (PDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48201 for ; Fri, 17 Aug 2001 08:38:26 -0700 (PDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7HFTlg10223 for ; Fri, 17 Aug 2001 11:29:51 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28500; Fri, 17 Aug 2001 17:29:22 +0200 (MET DST) Cc: "Isis-Wg@Spider. Juniper. Net" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA28483; Fri, 17 Aug 2001 17:29:20 +0200 (MET DST) Message-ID: <3B7D3850.BBF4D8B0@lucent.com> From: Erik Hietbrink Organization: Lucent Technologies X-Mailer: Mozilla 4.73C-CCK-MCD EMS-1.5/4.72 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ken Larmer Original-CC: "Isis-Wg@Spider. Juniper. Net" Subject: Re: [Isis-wg] Action on receipt of LSP 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 17:29:20 +0200 Content-Transfer-Encoding: 7bit Ken Larmer wrote: > > Hi, > > ISO-10589 states the action to take when receiving certain LSPs (Newer, > Same, Older...). The specification does not state what to do when you > receive a LSP, which contains the same LSPID, Sequence Number but with > different Remaining Lifetime values, i.e. the LSP Database Entry has > Remaining Lifetime = 0 and the received LSP has Remaining Lifetime = 1199. > What should we do in this situation? Should we return the expired LSP to the > source? > > Cheers, > Ken No, 10589, section 7.3.16.3 states "if the remaining lifetime of the received LSP is non-zero, but there is an LSP in the database with the same sequence number and zero remaining lifetime, the LSP in the database shall be considered most recent. Otherwise, the LSP with the larger sequence number shall be considered the most recent." Regards, Erik _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 11:34:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05430 for ; Fri, 17 Aug 2001 11:34:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48283; Fri, 17 Aug 2001 08:43:29 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48250 for ; Fri, 17 Aug 2001 08:42:08 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23843; Fri, 17 Aug 2001 11:33:32 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05659; Fri, 17 Aug 2001 11:33:37 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Aug 2001 11:33:34 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55509980@VIE-MSGUSR-01> From: "Sunkad, Ravindra" To: "'Ken Larmer'" , "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] Action on receipt of LSP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 11:33:32 -0400 Ken, Here's an excerpt from 7.3.16.3 "If the Remaining Lifetime in a received LSP or in an LSP entry in a received SNP is non-zero, but there is an LSP in the database with the same sequence number and zero Remaining Lifetime, the LSP in the database shall be considered most recent. Otherwise, the PDU with the larger sequence number shall be considered the most recent." Ravi > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Friday, August 17, 2001 11:04 AM > To: Isis-Wg@Spider. Juniper. Net > Cc: Ken Larmer > Subject: [Isis-wg] Action on receipt of LSP > > > Hi, > > ISO-10589 states the action to take when receiving > certain LSPs (Newer, > Same, Older...). The specification does not state what to do when you > receive a LSP, which contains the same LSPID, Sequence Number but with > different Remaining Lifetime values, i.e. the LSP Database Entry has > Remaining Lifetime = 0 and the received LSP has Remaining > Lifetime = 1199. > What should we do in this situation? Should we return the > expired LSP to the > source? > > Cheers, > Ken > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 11:37:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05501 for ; Fri, 17 Aug 2001 11:37:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48324; Fri, 17 Aug 2001 08:45:30 -0700 (PDT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA48298 for ; Fri, 17 Aug 2001 08:44:09 -0700 (PDT) Received: (qmail 66180 invoked from network); 17 Aug 2001 15:35:36 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Aug 2001 15:35:36 -0000 From: "Ken Larmer" To: "Erik Hietbrink" Cc: "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] Action on receipt of LSP Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <3B7D3850.BBF4D8B0@lucent.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 11:37:35 -0400 Content-Transfer-Encoding: 7bit Thanks Eric, I missed that! Cheers, Ken > -----Original Message----- > From: Erik Hietbrink [mailto:ehietbrink@lucent.com] > Sent: Friday, August 17, 2001 11:29 AM > To: Ken Larmer > Cc: Isis-Wg@Spider. Juniper. Net > Subject: Re: [Isis-wg] Action on receipt of LSP > > > Ken Larmer wrote: > > > > Hi, > > > > ISO-10589 states the action to take when receiving > certain LSPs (Newer, > > Same, Older...). The specification does not state what to do when you > > receive a LSP, which contains the same LSPID, Sequence Number but with > > different Remaining Lifetime values, i.e. the LSP Database Entry has > > Remaining Lifetime = 0 and the received LSP has Remaining > Lifetime = 1199. > > What should we do in this situation? Should we return the > expired LSP to the > > source? > > > > Cheers, > > Ken > > No, 10589, section 7.3.16.3 states "if the remaining lifetime of the > received LSP is non-zero, but there is an LSP in the database with the > same sequence number and zero remaining lifetime, the LSP in the > database shall be considered most recent. Otherwise, the LSP with the > larger sequence number shall be considered the most recent." > > Regards, > Erik > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 11:59:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06376 for ; Fri, 17 Aug 2001 11:59:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA48508; Fri, 17 Aug 2001 09:08:29 -0700 (PDT) Received: from tonga.force10networks.com (corp.force10networks.com [206.54.51.125]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA48496 for ; Fri, 17 Aug 2001 09:07:18 -0700 (PDT) Received: by tonga.force10networks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 08:58:57 -0700 Message-ID: <5A063B55DDB6D411937100D0B7C84E38017A6B6F@tonga.force10networks.com> From: Nageswara Soma To: "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] Action on receipt of LSP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 08:58:54 -0700 What if received LSP has a different life time than the one in LSP database? Note that both life times are non-zero. I had come across such case against a test suite. It regenerated an LSP with different content with same sequence number. Thanks Nageswara > -----Original Message----- > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > Sent: Friday, August 17, 2001 8:34 AM > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Ken, > > Here's an excerpt from 7.3.16.3 > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > received SNP is non-zero, but there is an LSP in the database > with the same > sequence number and zero Remaining Lifetime, the LSP in the > database shall > be considered most recent. Otherwise, the PDU with the > larger sequence > number shall be considered the most recent." > > Ravi > > > -----Original Message----- > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > Sent: Friday, August 17, 2001 11:04 AM > > To: Isis-Wg@Spider. Juniper. Net > > Cc: Ken Larmer > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > Hi, > > > > ISO-10589 states the action to take when receiving > > certain LSPs (Newer, > > Same, Older...). The specification does not state what to > do when you > > receive a LSP, which contains the same LSPID, Sequence > Number but with > > different Remaining Lifetime values, i.e. the LSP Database Entry has > > Remaining Lifetime = 0 and the received LSP has Remaining > > Lifetime = 1199. > > What should we do in this situation? Should we return the > > expired LSP to the > > source? > > > > Cheers, > > Ken > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 14:19:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11442 for ; Fri, 17 Aug 2001 14:19:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA49092; Fri, 17 Aug 2001 11:27:29 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA49080 for ; Fri, 17 Aug 2001 11:26:31 -0700 (PDT) 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 LAA20747; Fri, 17 Aug 2001 11:17:50 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 11:17:50 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAC2D7A0@avalon.pluris.com> From: Satish Dattatri To: "'Nageswara Soma'" , "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] Action on receipt of LSP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 11:17:41 -0700 Hi Soma, Hopefully the checksum would be different in that case also. 7.3.16.2: Now there are 2 cases the LSP being a (a) local one: bump the seq# and regenerate (b) non-local LSP: purge the LSP since there is no reliable way to tell which is more recent. I think this needs to be done also, could not find the ref in the spec: If the checksum happens also to be same then unless an implementation does a diff (either on the raw PDU or the contents)it will take it to be a duplicate reception of same LSP and ignore. On doing a diff in your case, the LSP will be purged becoz of the different content. Satish -----Original Message----- From: Nageswara Soma [mailto:nsoma@force10networks.com] Sent: Friday, August 17, 2001 8:59 AM To: Isis-Wg@Spider. Juniper. Net Subject: RE: [Isis-wg] Action on receipt of LSP What if received LSP has a different life time than the one in LSP database? Note that both life times are non-zero. I had come across such case against a test suite. It regenerated an LSP with different content with same sequence number. Thanks Nageswara > -----Original Message----- > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > Sent: Friday, August 17, 2001 8:34 AM > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Ken, > > Here's an excerpt from 7.3.16.3 > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > received SNP is non-zero, but there is an LSP in the database > with the same > sequence number and zero Remaining Lifetime, the LSP in the > database shall > be considered most recent. Otherwise, the PDU with the > larger sequence > number shall be considered the most recent." > > Ravi > > > -----Original Message----- > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > Sent: Friday, August 17, 2001 11:04 AM > > To: Isis-Wg@Spider. Juniper. Net > > Cc: Ken Larmer > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > Hi, > > > > ISO-10589 states the action to take when receiving > > certain LSPs (Newer, > > Same, Older...). The specification does not state what to > do when you > > receive a LSP, which contains the same LSPID, Sequence > Number but with > > different Remaining Lifetime values, i.e. the LSP Database Entry has > > Remaining Lifetime = 0 and the received LSP has Remaining > > Lifetime = 1199. > > What should we do in this situation? Should we return the > > expired LSP to the > > source? > > > > Cheers, > > Ken > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 15:28:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13617 for ; Fri, 17 Aug 2001 15:28:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA49411; Fri, 17 Aug 2001 12:37:29 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA49399 for ; Fri, 17 Aug 2001 12:36:52 -0700 (PDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA15139; Fri, 17 Aug 2001 15:28:11 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03562; Fri, 17 Aug 2001 15:28:16 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Aug 2001 15:28:13 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55509984@VIE-MSGUSR-01> From: "Sunkad, Ravindra" To: "'Satish Dattatri'" , "'Nageswara Soma'" , "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] Action on receipt of LSP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 15:28:12 -0400 The "Remaining Lifetime" field is not used in checksum computation. So, it's possible that the received LSP has the same seq. no. and the same checksum (and the same contents except Rem. Life Time). In that case I would think the IS would just treat it as receiving an LSP "equal" to it's copy. Ravi > -----Original Message----- > From: Satish Dattatri [mailto:satish@pluris.com] > Sent: Friday, August 17, 2001 2:18 PM > To: 'Nageswara Soma'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Hi Soma, > Hopefully the checksum would be different in that case also. > 7.3.16.2: > Now there are 2 cases the LSP being a > (a) local one: bump the seq# and regenerate > (b) non-local LSP: purge the LSP since there is no reliable way > to tell which is more recent. > > I think this needs to be done also, could not find the ref in > the spec: > If the checksum happens also to be same then unless an implementation > does a diff (either on the raw PDU or the contents)it will take it to > be a duplicate reception of same LSP and ignore. On doing a diff in > your case, the LSP will be purged becoz of the different content. > > Satish > > -----Original Message----- > From: Nageswara Soma [mailto:nsoma@force10networks.com] > Sent: Friday, August 17, 2001 8:59 AM > To: Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > What if received LSP has a different life time than > the one in LSP database? Note that both life times are non-zero. > I had come across such case against a test suite. It regenerated > an LSP with different content with same sequence number. > > Thanks > Nageswara > > > -----Original Message----- > > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > > Sent: Friday, August 17, 2001 8:34 AM > > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > > Subject: RE: [Isis-wg] Action on receipt of LSP > > > > > > Ken, > > > > Here's an excerpt from 7.3.16.3 > > > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > > received SNP is non-zero, but there is an LSP in the database > > with the same > > sequence number and zero Remaining Lifetime, the LSP in the > > database shall > > be considered most recent. Otherwise, the PDU with the > > larger sequence > > number shall be considered the most recent." > > > > Ravi > > > > > -----Original Message----- > > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > > Sent: Friday, August 17, 2001 11:04 AM > > > To: Isis-Wg@Spider. Juniper. Net > > > Cc: Ken Larmer > > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > > > > Hi, > > > > > > ISO-10589 states the action to take when receiving > > > certain LSPs (Newer, > > > Same, Older...). The specification does not state what to > > do when you > > > receive a LSP, which contains the same LSPID, Sequence > > Number but with > > > different Remaining Lifetime values, i.e. the LSP > Database Entry has > > > Remaining Lifetime = 0 and the received LSP has Remaining > > > Lifetime = 1199. > > > What should we do in this situation? Should we return the > > > expired LSP to the > > > source? > > > > > > Cheers, > > > Ken > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 17 19:30:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17083 for ; Fri, 17 Aug 2001 19:30:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA50367; Fri, 17 Aug 2001 16:38:29 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA50355 for ; Fri, 17 Aug 2001 16:37:57 -0700 (PDT) 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 QAA12548; Fri, 17 Aug 2001 16:29:14 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 16:29:14 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAC2D7A2@avalon.pluris.com> From: Satish Dattatri To: "'Sunkad, Ravindra'" , Satish Dattatri , "'Nageswara Soma'" , "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] Action on receipt of LSP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 17 Aug 2001 16:29:06 -0700 But in case of Soma's question a test suite generated a LSP with same seq# but different contents in the LSP. And you are right life time *cannot* be a factor to decide which is newer (see b in the old mail). This commonly happens when same LSP is recvd from 2 neighbor's. Satish -----Original Message----- From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] Sent: Friday, August 17, 2001 12:28 PM To: 'Satish Dattatri'; 'Nageswara Soma'; Isis-Wg@Spider. Juniper. Net Subject: RE: [Isis-wg] Action on receipt of LSP The "Remaining Lifetime" field is not used in checksum computation. So, it's possible that the received LSP has the same seq. no. and the same checksum (and the same contents except Rem. Life Time). In that case I would think the IS would just treat it as receiving an LSP "equal" to it's copy. Ravi > -----Original Message----- > From: Satish Dattatri [mailto:satish@pluris.com] > Sent: Friday, August 17, 2001 2:18 PM > To: 'Nageswara Soma'; Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > Hi Soma, > Hopefully the checksum would be different in that case also. > 7.3.16.2: > Now there are 2 cases the LSP being a > (a) local one: bump the seq# and regenerate > (b) non-local LSP: purge the LSP since there is no reliable way > to tell which is more recent. > > I think this needs to be done also, could not find the ref in > the spec: > If the checksum happens also to be same then unless an implementation > does a diff (either on the raw PDU or the contents)it will take it to > be a duplicate reception of same LSP and ignore. On doing a diff in > your case, the LSP will be purged becoz of the different content. > > Satish > > -----Original Message----- > From: Nageswara Soma [mailto:nsoma@force10networks.com] > Sent: Friday, August 17, 2001 8:59 AM > To: Isis-Wg@Spider. Juniper. Net > Subject: RE: [Isis-wg] Action on receipt of LSP > > > What if received LSP has a different life time than > the one in LSP database? Note that both life times are non-zero. > I had come across such case against a test suite. It regenerated > an LSP with different content with same sequence number. > > Thanks > Nageswara > > > -----Original Message----- > > From: Sunkad, Ravindra [mailto:Ravindra.Sunkad@marconi.com] > > Sent: Friday, August 17, 2001 8:34 AM > > To: 'Ken Larmer'; Isis-Wg@Spider. Juniper. Net > > Subject: RE: [Isis-wg] Action on receipt of LSP > > > > > > Ken, > > > > Here's an excerpt from 7.3.16.3 > > > > "If the Remaining Lifetime in a received LSP or in an LSP entry in a > > received SNP is non-zero, but there is an LSP in the database > > with the same > > sequence number and zero Remaining Lifetime, the LSP in the > > database shall > > be considered most recent. Otherwise, the PDU with the > > larger sequence > > number shall be considered the most recent." > > > > Ravi > > > > > -----Original Message----- > > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > > Sent: Friday, August 17, 2001 11:04 AM > > > To: Isis-Wg@Spider. Juniper. Net > > > Cc: Ken Larmer > > > Subject: [Isis-wg] Action on receipt of LSP > > > > > > > > > Hi, > > > > > > ISO-10589 states the action to take when receiving > > > certain LSPs (Newer, > > > Same, Older...). The specification does not state what to > > do when you > > > receive a LSP, which contains the same LSPID, Sequence > > Number but with > > > different Remaining Lifetime values, i.e. the LSP > Database Entry has > > > Remaining Lifetime = 0 and the received LSP has Remaining > > > Lifetime = 1199. > > > What should we do in this situation? Should we return the > > > expired LSP to the > > > source? > > > > > > Cheers, > > > Ken > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Aug 19 05:46:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10477 for ; Sun, 19 Aug 2001 05:46:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA60553; Sun, 19 Aug 2001 02:54:30 -0700 (PDT) Received: from ams2eusosrv15.ams.ops.eu.uu.net (ams2eusosrv15.ams.ops.eu.uu.net [146.188.99.70]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA60541 for ; Sun, 19 Aug 2001 02:53:35 -0700 (PDT) Received: from ams2eusosrv20.ams.ops.eu.uu.net by ams2eusosrv15.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv20.ams.ops.eu.uu.net [146.188.99.75]) id QQlcss13987 for ; Sun, 19 Aug 2001 09:44:38 GMT Received: from eunoc235.ams.ops.eu.uu.net by ams2eusosrv20.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: eunoc235.ams.ops.eu.uu.net [146.188.96.158]) id QQlcss26429 for ; Sun, 19 Aug 2001 09:44:34 GMT Received: from localhost by eunoc235.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: jgreenha@localhost) id QQlcss25727; Sun, 19 Aug 2001 09:44:34 GMT From: John Greenhalgh X-Sender: jgreenha@eunoc235.ams.ops.eu.uu.net To: isis-wg@spider.juniper.net In-Reply-To: <200108111904.MAA13253@external.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Isis-wg] Initialisation question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 19 Aug 2001 09:44:34 +0000 (GMT) Hi, I'm looking through ISO 10589 and trying to understand how routers learn the link state database once adjacencies have been formed. For broadcast I gather that the CSNP from the DIS will initiate an update, but what about on point-to-point? Any pointers gladly received! TIA, John _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Aug 19 08:09:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11235 for ; Sun, 19 Aug 2001 08:09:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA61203; Sun, 19 Aug 2001 05:18:30 -0700 (PDT) Received: from ams2eusosrv9.ams.ops.eu.uu.net (ams2eusosrv9.ams.ops.eu.uu.net [146.188.99.14]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA61191 for ; Sun, 19 Aug 2001 05:17:39 -0700 (PDT) Received: from ams2eusosrv1.ams.ops.eu.uu.net by ams2eusosrv9.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: ams2eusosrv1.ams.ops.eu.uu.net [146.188.99.6]) id QQlctc02267; Sun, 19 Aug 2001 12:08:51 GMT Received: from eunoc235.ams.ops.eu.uu.net by ams2eusosrv1.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: eunoc235.ams.ops.eu.uu.net [146.188.96.158]) id QQlctc19184; Sun, 19 Aug 2001 12:08:26 GMT Received: from localhost by eunoc235.ams.ops.eu.uu.net with ESMTP (peer crosschecked as: jgreenha@localhost) id QQlctc26205; Sun, 19 Aug 2001 12:08:26 GMT From: John Greenhalgh X-Sender: jgreenha@eunoc235.ams.ops.eu.uu.net To: Hannes Gredler cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Initialisation question In-Reply-To: <20010819133122.A12669@juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 19 Aug 2001 12:08:26 +0000 (GMT) Thanks, Sorry I should have said that I'd read that bit, but I'm still not clear exactly what happens. I guess that once two routers are adjacent they exchange CSNPs and then send PSNPs for any LSPs they are short of or are old? Correct? Thanks, John On Sun, 19 Aug 2001, Hannes Gredler wrote: > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: > | Hi, > | > | I'm looking through ISO 10589 and trying to understand how routers learn > | the link state database once adjacencies have been formed. For broadcast I > | gather that the CSNP from the DIS will initiate an update, but what about > | on point-to-point? Any pointers gladly received! > > john, > > take a look at paragraph 7.3.20.2.e where it says: > > [ ... ] CSNPs are transmited on > point-to-point circuits at initialisation. > > HTH, > > /hannes > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 01:57:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26973 for ; Mon, 20 Aug 2001 01:57:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA65398; Sun, 19 Aug 2001 23:06:29 -0700 (PDT) Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA61029 for ; Sun, 19 Aug 2001 04:40:11 -0700 (PDT) Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id NAA12675; Sun, 19 Aug 2001 13:31:22 +0200 From: Hannes Gredler To: John Greenhalgh Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Initialisation question Message-ID: <20010819133122.A12669@juniper.net> References: <200108111904.MAA13253@external.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jgreenha@eu.uu.net on Sun, Aug 19, 2001 at 09:44:34AM +0000 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 19 Aug 2001 13:31:22 +0200 On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: | Hi, | | I'm looking through ISO 10589 and trying to understand how routers learn | the link state database once adjacencies have been formed. For broadcast I | gather that the CSNP from the DIS will initiate an update, but what about | on point-to-point? Any pointers gladly received! john, take a look at paragraph 7.3.20.2.e where it says: [ ... ] CSNPs are transmited on point-to-point circuits at initialisation. HTH, /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 01:59:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27188 for ; Mon, 20 Aug 2001 01:59:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA65420; Sun, 19 Aug 2001 23:08:22 -0700 (PDT) Received: from ghostrider.gredler.at (ghostrider.gredler.at [193.83.223.228]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA61718 for ; Sun, 19 Aug 2001 07:23:16 -0700 (PDT) Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id QAA12752; Sun, 19 Aug 2001 16:14:18 +0200 From: Hannes Gredler To: John Greenhalgh Cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Initialisation question Message-ID: <20010819161418.A12747@juniper.net> References: <20010819133122.A12669@juniper.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jgreenha@eu.uu.net on Sun, Aug 19, 2001 at 12:08:26PM +0000 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 19 Aug 2001 16:14:18 +0200 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii correct - for your convenience i have attached a tcpdump to see what happens; /hannes On Sun, Aug 19, 2001 at 12:08:26PM +0000, John Greenhalgh wrote: | | Thanks, | | Sorry I should have said that I'd read that bit, but I'm still not | clear exactly what happens. I guess that once two routers are adjacent | they exchange CSNPs and then send PSNPs for | any LSPs they are short of or are old? Correct? | | Thanks, | John | | | On Sun, 19 Aug 2001, Hannes Gredler wrote: | | > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: | > | Hi, | > | | > | I'm looking through ISO 10589 and trying to understand how routers learn | > | the link state database once adjacencies have been formed. For broadcast I | > | gather that the CSNP from the DIS will initiate an update, but what about | > | on point-to-point? Any pointers gladly received! | > | > john, | > | > take a look at paragraph 7.3.20.2.e where it says: | > | > [ ... ] CSNPs are transmited on | > point-to-point circuits at initialisation. | > | > HTH, | > | > /hannes | > | | _______________________________________________ | Isis-wg mailing list - Isis-wg@external.juniper.net | http://external.juniper.net/mailman/listinfo/isis-wg --PNTmBPCT7hxwcZjr Content-Type: application/octet-stream Content-Disposition: attachment; filename="hannes-isis-ppp-tcpdump.1500" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAANwFAAAJAAAAcW7QOk9cCgAOAAAADgAAABgAAAAAAAAA/wPAIQEi AAoFBjrat2hzbtA641wKAA4AAAAOAAAAGAAAAAAAZ2j/A8AhASMACgUGOtq3aHVu0DpxXQoA DgAAAA4AAAAYAAAAAAAAAP8DwCEBJAAKBQY62rdod27QOgpeCgAOAAAADgAAABgAAAAAAGdo /wPAIQElAAoFBjrat2h5btA6l14KAA4AAAAOAAAAGAAAAAAAAAD/A8AhASYACgUGOtq3aHtu 0DovXwoADgAAAA4AAAAYAAAAAABnaP8DwCEBJwAKBQY62rdofW7QOr9fCgAOAAAADgAAABgA AAAAAAAA/wPAIQEoAAoFBjrat2h/btA6V2AKAA4AAAAOAAAAGAAAAAAAZ2j/A8AhASkACgUG Otq3aIFu0DrqYAoADgAAAA4AAAAYAAAAAAAAAP8DwCEBKgAKBQY62rdog27QOndhCgAOAAAA DgAAABgAAAAAAGdo/wPAIQErAAoFBjrat2iFbtA6E2IKAA4AAAAOAAAAGAAAAAAAAAD/A8Ah ASwACgUGOtq3aIdu0DqvYgoADgAAAA4AAAAYAAAAAABnaP8DwCEBLQAKBQY62rdoiW7QOjhj CgAOAAAADgAAABgAAAAAAAAA/wPAIQEuAAoFBjrat2iJbtA622UKAA4AAAAOAAAAGAABAAAA BAP/A8AhAi4ACgUGOtq3aIlu0DqCQwwADgAAAA4AAAAYAAEAAAAAAv8DwCEBOgAKBQY61Q/V iW7QOoxDDAAOAAAADgAAABgAAAAAAAAA/wPAIQI6AAoFBjrVD9WJbtA6xkMMAAgAAAAIAAAA GAAAAAAA////A4AhAS8ABIlu0DrOQwwACAAAAAgAAAAYAAAAAAAAAv8DgCMBMAAEiW7QOtND DAAIAAAACAAAABgAAAAAAAAB/wOCgQExAASJbtA6NUcMAAgAAAAIAAAAGAABAAAAzIT/A4Ah ATsABIlu0DpBRwwACAAAAAgAAAAYAAAAAAALIP8DgCECOwAEiW7QOl9HDAAIAAAACAAAABgA AQAAANHM/wOAIwE8AASJbtA6YkcMAAgAAAAIAAAAGAAAAAAABAr/A4AjAjwABIlu0Dp2RwwA CAAAAAgAAAAYAAEAAADMS/8DgoEBPQAEiW7QOnlHDAAIAAAACAAAABgAAAAAAAAA/wOCgQI9 AASJbtA6aEwMAAgAAAAIAAAAGAABAAAA////A4AhAi8ABIlu0DqZTAwACAAAAAgAAAAYAAEA AAAKCv8DgCMCMAAEiW7QOpxMDAAIAAAACAAAABgAAQAAAAAA/wOCgQIxAASRbtA6fc4EANgF AADYBQAAGAABAAAAZ2j/AwAjgxQBABEBAAADAAAAAACJABsF1AHwAQKBAcyEBMCoyQEBBANF AAEI/xIThATQERITiQlNNS1EdWJsaW6AGACAgIDQERIT/////wqAgIDAqMkA////AIcRAAAA ACDQERITAAAAChjAqMkD/////xSAgIAKCgwA/////BSAgIAKCgwE/////BSAgIAKCg4A//// /Ic/AAAAACDQERITAAAAFCABAQEBAAAACiACAgICAAAAFCADAwMDAAAAFB4KCgwAAAAAFB4K CgwEAAAAFB4KCg4ADAAAAAAUHgoKDAQAAAAUHgoKDgACDAAKgICAAAIAAgACABYXAAIAAgAC AAAACgwGBMCoyQEIBMCoyRQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAI/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAj/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACKcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJJu 0DrgOQMA2AUAANgFAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwXUAfABAYEBzIQE wKjJFAEEA0UAAQj/AACJAAAAAACiOsUCaQABAAEAAQAAAAAA73KQBK4AAgACAAIAAAAAARTR UgJtAAMAAwADAAAAAADzhRyACgoOAP////wKgICAAQEBAf////8KgICAAwMDA/////8KgICA wKjJAP///wCHPgAAAAAgAgICAgAAAAoeCgoMAAAAAAoeCgoMBAAAAAoeCgoOAAAAAAogAQEB AQAAAAogAwMDAwAAAAoYwKjJCgwGCAQKCgwFCyBLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cxL k9HMS5PRzAoES5PRzAkES5PRzAMEAAAEAIA8AICAgAICAgL/////CoCAgAoKDAD////8CP+A gAoKDAT////8CoCAgAoKDgD////8CoCAgMCoyQD///8AhywAAAAAIAICAgIAAAAKHgoKDAAA AAAKHgoKDAQAAAAKHgoKDgAAAAAKGMCoyQAACh4KCgwAAAAAChjAqMkAAAAKHgoKDAQAAAAK HgoKDgAAAAAKHgoKDAQAAAAKHgoKDgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI/wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACP8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI pwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAk27QOi1vAwDYBQAA2AUAABgAAQAAAGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbBdQB 8AEBgQHMhATAqMkBAQQDRQABCP8SE4QE0BESE4kJTTUtRHVibGlugBgAgICA0BESE/////8K gICAwKjJAP///wCHEQAAAAAg0BESEwAAAAoYwKjJA/////8UgICACgoMAP////wUgICACgoM BP////wUgICACgoOAP////yHPwAAAAAg0BESEwAAABQgAQEBAQAAAAogAgICAgAAABQgAwMD AwAAABQeCgoMAAAAABQeCgoMBAAAABQeCgoOAAwAAAAAFB4KCgwEAAAAFB4KCg4AAgwACoCA gAACAAIAAgAWFwACAAIAAgAAAAoMBgTAqMkBCATAqMkUAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAI/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACP8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAI/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAinAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACUbtA6jYgDACoAAAAqAAAAGAAAAAAAAAD/AwAjgxQBABEBAAADAAIA AgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAGVbtA6G7sDACoAAAAqAAAAGAABAAAAZ2j/AwAj gxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAGYbtA6tokDAGcAAABnAAAA GAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAAAAAAAP//////////CUADzgAAAAAA iQAAAAAAojrFAl4AAQABAAEAAAAAAO9ykASrAAIAAgACAAAAAAEVKJICYgADAAMAAwAAAAAA 84UcmG7QOtuJAwBHAAAARwAAABgAAAAAAICA/wMAI4MhAQAZAQAAAEMAAgACAAIBAAAAAAAA AAD//////////wkgA9QAAAAAAIkAAAAAAKsgwwStAAIAAgACAAAAAAEOWJ2ZbtA6YG4DACcA AAAnAAAAGAABAAAAZ2j/AwAjgxEBABoBAAAAIwAAAAAAiQAJEAPSAAIAAgACAAAAAAEQHaKZ btA6eW4DACcAAAAnAAAAGAABAAAAboD/AwAjgxEBABsBAAAAIwAAAAAAiQAJEAPSAAIAAgAC AAAAAAEIZpWZbtA6U7wDAGcAAABnAAAAGAABAAAAgID/AwAjgyEBABgBAAAAYwAAAAAAiQAA AAAAAAAAAP//////////CUAEqwAAAAAAiQAAAAAApjLJAlsAAQABAAEAAAAAAO9ykAPSAAIA AgACAAAAAAEQHaICXwADAAMAAwAAAAAA84UcmW7QOmu8AwBHAAAARwAAABgAAQAAAAAC/wMA I4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKsAAAAAAIkAAAAAALAe0wPS AAIAAgACAAAAAAEIZpWabtA6N2MDACcAAAAnAAAAGAAAAAAAAAD/AwAjgxEBABoBAAAAIwAC AAIAAgEJEAPMAAAAAACJAAAAAACiOsWabtA6XmMDACcAAAAnAAAAGAAAAAAAAQD/AwAjgxEB ABsBAAAAIwACAAIAAgEJEAPSAAAAAACJAAAAAACrIMObbtA6Kn4JACoAAAAqAAAAGAAAAAAA Z2j/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAGcbtA6UMYIACoA AAAqAAAAGAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANF AAGdbtA6KIsDAJ8BAACfAQAAGAAAAAAAACP/AwAjgxsBABIBAAABmwSmAAIAAgACAAAAAAEV KJIDAQQDRQABgQHMhgQCAgIChAQCAgICiQhNMTAtT3NsbwItAAqAgIAAAwADAAMACoCAgAAB AAEAAQAKgICAAAEAAQABAAqAgIAAAAAAAIkAFsQAAwADAAMAAAAKDAYECgoOAQgECgoOAgAB AAEAAQAAAApABgQKCgwCCAQKCgwBCyBLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cxLk9HMS5PR zAoES5PRzAkES5PRzAMEAAAEAAABAAEAAQAAAApABgQKCgwGCAQKCgwFCyBLk9HMS5PRzEuT 0cxLk9HMS5PRzEuT0cxLk9HMS5PRzAoES5PRzAkES5PRzAMEAAAEAAAAAAAAiQAAAAoMBgTA qMkUCATAqMkBgDwAgICAAgICAv////8KgICACgoMAP////wKgICACgoMBP////wKgICACgoO AP////wKgICAwKjJAP///wCHLAAAAAAgAgICAgAAAAoeCgoMAAAAAAoeCgoMBAAAAAoeCgoO AAAAAAoYwKjJnW7QOu0RBQAQAQAAEAEAABgAAAAAAAAA/wMAI4MbAQAUAQAAAQwEqAACAAIA AgAAAAABDlidAwEEA0UAAYEBzIYEAgICAoQEAgICAokITTEwLU9zbG+AYACAgIACAgIC//// /wqAgIAKCgwA/////AqAgIAKCgwE/////AqAgIAKCg4A/////AqAgIABAQEB/////wqAgIAD AwMD/////wqAgIDAqMkA////AAqAgIDQERIT/////4dHAAAAACACAgICAAAACh4KCgwAAAAA Ch4KCgwEAAAACh4KCg4AAAAACiABAQEBAAAACiADAwMDAAAAChjAqMkAAAAKINAREhMCDAAK gICAAAAAAACJABYXAAAAAACJAAAACgwGBMCoyRQIBMCoyQGebtA6wUgDACcAAAAnAAAAGAAB AAAAZ2j/AwAjgxEBABoBAAAAIwAAAAAAiQAJEASkAAIAAgACAAAAAAEVKJKebtA620gDACcA AAAnAAAAGAABAAAAboD/AwAjgxEBABsBAAAAIwAAAAAAiQAJEASmAAIAAgACAAAAAAEOWJ2e btA6n5YDAJMAAACTAAAAGAABAAAAgID/AwAjgxsBABIBAAAAjwSmAAAAAACJAAAAAACmMskD AQQDRQABgQHMhgTQERIThATQERITiQlNNS1EdWJsaW6AGACAgIDQERIT/////wqAgIDAqMkA ////AIcRAAAAACDQERITAAAAChjAqMkCDAAKgICAAAIAAgACABYXAAIAAgACAAAACgwGBMCo yQEIBMCoyRSebtA6pNkDAGcAAABnAAAAGAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEA AAAAAAAAAP//////////CUAEpAAAAAAAiQAAAAAApjLJAlgAAQABAAEAAAAAAO9ykASlAAIA AgACAAAAAAEVKJICXAADAAMAAwAAAAAA84Ucnm7QOs/ZAwBHAAAARwAAABgAAAAAAAAA/wMA I4MhAQAZAQAAAEMAAgACAAIBAAAAAAAAAAD//////////wkgA84AAAAAAIkAAAAAAKsgwwSn AAIAAgACAAAAAAEOWJ2ebtA6qR0FABEBAAARAQAAGAABAAAAAAD/AwAjgxsBABQBAAABDQSs AAAAAACJAAAAAACxFMkDAQQDRQABgQHMhgTQERIThATQERITiQlNNS1EdWJsaW6AYACAgIDQ ERIT/////wqAgIDAqMkA////ABSAgIABAQEB/////wqAgIACAgIC/////xSAgIADAwMD//// /xSAgIAKCgwA/////BSAgIAKCgwE/////BSAgIAKCg4A/////IdHAAAAACDQERITAAAAChjA qMkAAAAUIAEBAQEAAAAKIAICAgIAAAAUIAMDAwMAAAAUHgoKDAAAAAAUHgoKDAQAAAAUHgoK DgACDAAKgICAAAIAAgACABYXAAIAAgACAAAACgwGBMCoyQEIBMCoyRSfbtA66N0BACcAAAAn AAAAGAAAAAAAAAD/AwAjgxEBABoBAAAAIwACAAIAAgEJEASkAAAAAACJAAAAAACmMsmfbtA6 Ct4BACcAAAAnAAAAGAAAAAAAAAD/AwAjgxEBABsBAAAAIwACAAIAAgEJEASqAAAAAACJAAAA AACxFMmfbtA6fb4DAGcAAABnAAAAGAABAAAAT3P/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAA AAAAAP//////////CUAEpQAAAAAAiQAAAAAApjLJAlUAAQABAAEAAAAAAO9ykASiAAIAAgAC AAAAAAEVKJICWQADAAMAAwAAAAAA84Ucn27QOpW+AwBHAAAARwAAABgAAQAAAMxL/wMAI4Mh AQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKsAAAAAAIkAAAAAALEUyQSlAAIA AgACAAAAAAEOWJ2kbtA6aAYCACoAAAAqAAAAGAAAAAAAZ2j/AwAjgxQBABEBAAADAAIAAgAC ABsAJgHwAQCBAcyEBMCoyRQBBANFAAGkbtA6L8ADAGcAAABnAAAAGAABAAAAACP/AwAjgyEB ABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEoAAAAAAAiQAAAAAApjLJAlAAAQAB AAEAAAAAAO9ykASdAAIAAgACAAAAAAEVKJICVAADAAMAAwAAAAAA84UcpG7QOkjAAwBHAAAA RwAAABgAAQAAAICA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKYA AAAAAIkAAAAAALEUyQSgAAIAAgACAAAAAAEOWJ2kbtA6MNYLACoAAAAqAAAAGAABAAAAAAD/ AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAGpbtA6zcEDAGcAAABn AAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEmwAA AAAAiQAAAAAApjLJAksAAQABAAEAAAAAAO9ykASYAAIAAgACAAAAAAEVKJICTwADAAMAAwAA AAAA84UcqW7QOubBAwBHAAAARwAAABgAAQAAAAEA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAA AAAAAAD//////////wkgBKEAAAAAAIkAAAAAALEUyQSbAAIAAgACAAAAAAEOWJ2sbtA6kfwH ABwAAAAcAAAAGAAAAAAAAAD/AwAjghgBAAQAePeUCkUAAQACAAIAAgDGAgA8rG7QOtDmCAAq AAAAKgAAABgAAAAAAGdo/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQD RQABrW7QOhGKAgAqAAAAKgAAABgAAQAAAAAA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEA gQHMhATAqMkBAQQDRQABrm7QOm/DAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMA AAAAAIkAAAAAAAAAAAD//////////wlABJYAAAAAAIkAAAAAAKYyyQJGAAEAAQABAAAAAADv cpAEkwACAAIAAgAAAAABFSiSAkoAAwADAAMAAAAAAPOFHK5u0DqHwwMARwAAAEcAAAAYAAEA AABPc/8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIAScAAAAAACJAAAA AACxFMkElgACAAIAAgAAAAABDlidsm7QOli4AwBnAAAAZwAAABgAAAAAAGdo/wMAI4MhAQAY AQAAAGMAAgACAAIBAAAAAAAAAAD//////////wlABJAAAAAAAIkAAAAAAKYyyQJEAAEAAQAB AAAAAADvcpAEkQACAAIAAgAAAAABFSiSAkgAAwADAAMAAAAAAPOFHLJu0DqBuAMARwAAAEcA AAAYAAAAAAABAP8DACODIQEAGQEAAABDAAIAAgACAQAAAAAAAAAA//////////8JIASXAAAA AACJAAAAAACxFMkEkwACAAIAAgAAAAABDlids27QOhDFAwBnAAAAZwAAABgAAQAAAAAA/wMA I4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABJEAAAAAAIkAAAAAAKYyyQJB AAEAAQABAAAAAADvcpAEjgACAAIAAgAAAAABFSiSAkUAAwADAAMAAAAAAPOFHLNu0DooxQMA RwAAAEcAAAAYAAEAAABPc/8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8J IASXAAAAAACJAAAAAACxFMkEkQACAAIAAgAAAAABDlidtW7QOh3fAAAqAAAAKgAAABgAAQAA AGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABtW7QOvNuBwAc AAAAHAAAABgAAQAAAAAA/wMAI4IYAQAEAHgn4QpFAAEAAAAAAIkAxgIAPLVu0DpbwggAKgAA ACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UA Abhu0DqbxgMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA //////////8JQASMAAAAAACJAAAAAACmMskCPAABAAEAAQAAAAAA73KQBIkAAgACAAIAAAAA ARUokgJAAAMAAwADAAAAAADzhRy4btA6tMYDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkB AAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEkgAAAAAAiQAAAAAAsRTJBIwAAgACAAIA AAAAAQ5Ynbxu0Dr4Jw4AKgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAm AfABAIEBzIQEwKjJAQEEA0UAAb1u0DpJyAMAZwAAAGcAAAAYAAEAAAAAAP8DACODIQEAGAEA AABjAAAAAACJAAAAAAAAAAAA//////////8JQASHAAAAAACJAAAAAACmMskCNwABAAEAAQAA AAAA73KQBIQAAgACAAIAAAAAARUokgI7AAMAAwADAAAAAADzhRy9btA6T8gDAEcAAABHAAAA GAABAAAAAAH/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEjQAAAAAA iQAAAAAAsRTJBIcAAgACAAIAAAAAAQ5Ynb1u0Dqopg0AKgAAACoAAAAYAAAAAABnaP8DACOD FAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAcJu0DrhyQMAZwAAAGcAAAAY AAEAAAAAAP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQASCAAAAAACJ AAAAAACmMskCMgABAAEAAQAAAAAA73KQBH8AAgACAAIAAAAAARUokgI2AAMAAwADAAAAAADz hRzCbtA6+skDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAA AP//////////CSAEiAAAAAAAiQAAAAAAsRTJBIIAAgACAAIAAAAAAQ5YncRu0DrrWAEAKgAA ACoAAAAYAAEAAABnaP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UA AcVu0Dp12AkAKgAAACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEB zIQEwKjJFAEEA0UAAcZu0DoUvgMAZwAAAGcAAAAYAAAAAAAAAP8DACODIQEAGAEAAABjAAIA AgACAQAAAAAAAAAA//////////8JQAR8AAAAAACJAAAAAACmMskCMAABAAEAAQAAAAAA73KQ BH0AAgACAAIAAAAAARUokgI0AAMAAwADAAAAAADzhRzGbtA6O74DAEcAAABHAAAAGAAAAAAA AAH/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP//////////CSAEgwAAAAAAiQAAAAAA sRTJBH8AAgACAAIAAAAAAQ5Yncdu0DqCywMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEA AABjAAAAAACJAAAAAAAAAAAA//////////8JQAR9AAAAAACJAAAAAACmMskCLQABAAEAAQAA AAAA73KQBHoAAgACAAIAAAAAARUokgIxAAMAAwADAAAAAADzhRzHbtA6mssDAEcAAABHAAAA GAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEgwAAAAAA iQAAAAAAsRTJBH0AAgACAAIAAAAAAQ5Ynctu0DrojwQAKgAAACoAAAAYAAEAAAAAAP8DACOD FAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UAAcxu0Do1zQMAZwAAAGcAAAAY AAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAR4AAAAAACJ AAAAAACmMskCKAABAAEAAQAAAAAA73KQBHUAAgACAAIAAAAAARUokgIsAAMAAwADAAAAAADz hRzMbtA6TM0DAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAA AP//////////CSAEfgAAAAAAiQAAAAAAsRTJBHgAAgACAAIAAAAAAQ5Ync1u0Dq1sgAAKgAA ACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UA AdFu0DrJzgMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA //////////8JQARzAAAAAACJAAAAAACmMskCIwABAAEAAQAAAAAA73KQBHAAAgACAAIAAAAA ARUokgInAAMAAwADAAAAAADzhRzRbtA64c4DAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkB AAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEeQAAAAAAiQAAAAAAsRTJBHMAAgACAAIA AAAAAQ5YndJu0Do7Vg4AKgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAm AfABAIEBzIQEwKjJAQEEA0UAAdVu0DrOsAIAKgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEA AAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAdZu0Dp59wMAZwAAAGcAAAAYAAEAAAAA AP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQARuAAAAAACJAAAAAACm MskCHgABAAEAAQAAAAAA73KQBGsAAgACAAIAAAAAARUokgIiAAMAAwADAAAAAADzhRzWbtA6 kfcDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP////// ////CSAEdAAAAAAAiQAAAAAAsRTJBG4AAgACAAIAAAAAAQ5Yndpu0DriwwMAZwAAAGcAAAAY AAAAAABnaP8DACODIQEAGAEAAABjAAIAAgACAQAAAAAAAAAA//////////8JQARoAAAAAACJ AAAAAACmMskCHAABAAEAAQAAAAAA73KQBGkAAgACAAIAAAAAARUokgIgAAMAAwADAAAAAADz hRzabtA6CsQDAEcAAABHAAAAGAAAAAAAAQD/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAA AP//////////CSAEbwAAAAAAiQAAAAAAsRTJBGsAAgACAAIAAAAAAQ5Yndpu0DpYGwYAKgAA ACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UA Adtu0DoD0gMAZwAAAGcAAAAYAAEAAAAAAP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA //////////8JQARpAAAAAACJAAAAAACmMskCGQABAAEAAQAAAAAA73KQBGYAAgACAAIAAAAA ARUokgIdAAMAAwADAAAAAADzhRzbbtA6G9IDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkB AAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEbwAAAAAAiQAAAAAAsRTJBGkAAgACAAIA AAAAAQ5Yndxu0DpFUwEAKgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEAAAMAAgACAAIAGwAm AfABAIEBzIQEwKjJFAEEA0UAAeBu0DrJ0wMAZwAAAGcAAAAYAAEAAAAAAP8DACODIQEAGAEA AABjAAAAAACJAAAAAAAAAAAA//////////8JQARkAAAAAACJAAAAAACmMskCFAABAAEAAQAA AAAA73KQBGEAAgACAAIAAAAAARUokgIYAAMAAwADAAAAAADzhRzgbtA61dMDAEcAAABHAAAA GAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEagAAAAAA iQAAAAAAsRTJBGQAAgACAAIAAAAAAQ5YneFu0DrhKgkAKgAAACoAAAAYAAEAAABnaP8DACOD FAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UAAeNu0DqhGAIAKgAAACoAAAAY AAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAeVu0Dqv 1QMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////// //8JQARfAAAAAACJAAAAAACmMskCDwABAAEAAQAAAAAA73KQBFwAAgACAAIAAAAAARUokgIT AAMAAwADAAAAAADzhRzlbtA6yNUDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAA AAAAiQAAAAAAAAAAAP//////////CSAEZQAAAAAAiQAAAAAAsRTJBF8AAgACAAIAAAAAAQ5Y nehu0DrzDQgAHAAAABwAAAAYAAAAAAAAAP8DACOCGAEABAB495QKRQABAAIAAgACAMYCADzq btA6PHsAACoAAAAqAAAAGAABAAAAZ2j/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyE BMCoyQEBBANFAAHqbtA659YDAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAA iQAAAAAAAAAAAP//////////CUAEWgAAAAAAiQAAAAAApjLJAgoAAQABAAEAAAAAAO9ykARX AAIAAgACAAAAAAEVKJICDgADAAMAAwAAAAAA84Uc6m7QOv/WAwBHAAAARwAAABgAAQAAAAAB /wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBGAAAAAAAIkAAAAAALEU yQRaAAIAAgACAAAAAAEOWJ3rbtA6VEgGAJMAAACTAAAAGAABAAAAAAD/AwAjgxsBABIBAAAA jwSuAAAAAACJAAAAAACnMMoDAQQDRQABgQHMhgTQERIThATQERITiQlNNS1EdWJsaW6AGACA gIDQERIT/////wqAgIDAqMkA////AIcRAAAAACDQERITAAAAChjAqMkCDAAKgICAAAIAAgAC ABYXAAIAAgACAAAACgwGBMCoyQEIBMCoyRTsbtA6rLsAACoAAAAqAAAAGAAAAAAAZ2j/AwAj gxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAHsbtA6rywDACcAAAAnAAAA GAAAAAAAAAD/AwAjgxEBABoBAAAAIwACAAIAAgEJEASsAAAAAACJAAAAAACnMMrubtA6pckD AGcAAABnAAAAGAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAAAAAAAP////////// CUAEqgAAAAAAiQAAAAAApzDKAggAAQABAAEAAAAAAO9ykARVAAIAAgACAAAAAAEVKJICDAAD AAMAAwAAAAAA84Uc7m7QOsvJAwBHAAAARwAAABgAAAAAAAAC/wMAI4MhAQAZAQAAAEMAAgAC AAIBAAAAAAAAAAD//////////wkgBFsAAAAAAIkAAAAAALEUyQRXAAIAAgACAAAAAAEOWJ3v btA6k9gDAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP// ////////CUAEqwAAAAAAiQAAAAAApzDKAgUAAQABAAEAAAAAAO9ykARSAAIAAgACAAAAAAEV KJICCQADAAMAAwAAAAAA84Uc727QOqrYAwBHAAAARwAAABgAAQAAAAEA/wMAI4MhAQAZAQAA AEMAAAAAAIkAAAAAAAAAAAD//////////wkgBFsAAAAAAIkAAAAAALEUyQRVAAIAAgACAAAA AAEOWJ3xbtA6Yu4CACoAAAAqAAAAGAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHw AQCBAcyEBMCoyQEBBANFAAHxbtA6hoIHABwAAAAcAAAAGAABAAAAAAD/AwAjghgBAAQAeCfh CkUAAQAAAAAAiQDGAgA89G7QOjDaAwBnAAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMA AAAAAIkAAAAAAAAAAAD//////////wlABKYAAAAAAIkAAAAAAKcwygIAAAEAAQABAAAAAADv cpAETQACAAIAAgAAAAABFSiSAgQAAwADAAMAAAAAAPOFHPRu0DpH2gMARwAAAEcAAAAYAAEA AAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIARWAAAAAACJAAAA AACxFMkEUAACAAIAAgAAAAABDlid9G7QOgANCgAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQAR AQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQAB+W7QOtTbAwBnAAAAZwAAABgAAQAA AGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABKEAAAAAAIkAAAAA AKcwygH7AAEAAQABAAAAAADvcpAESAACAAIAAgAAAAABFSiSAf8AAwADAAMAAAAAAPOFHPlu 0Dru2wMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//// //////8JIARRAAAAAACJAAAAAACxFMkESwACAAIAAgAAAAABDlid+W7QOtrsBAAqAAAAKgAA ABgAAQAAAAAA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQAB+27Q OpduCwAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATA qMkUAQQDRQAB/m7QOmndAwBnAAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkA AAAAAAAAAAD//////////wlABJwAAAAAAIkAAAAAAKcwygH2AAEAAQABAAAAAADvcpAEQwAC AAIAAgAAAAABFSiSAfoAAwADAAMAAAAAAPOFHP5u0DqB3QMARwAAAEcAAAAYAAEAAAABAP8D ACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIARMAAAAAACJAAAAAACxFMkE RgACAAIAAgAAAAABDlidAW/QOrGqCQAqAAAAKgAAABgAAQAAAAAA/wMAI4MUAQARAQAAAwAA AAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABAm/QOmPPAwBnAAAAZwAAABgAAAAAAAAA/wMA I4MhAQAYAQAAAGMAAgACAAIBAAAAAAAAAAD//////////wlABJYAAAAAAIkAAAAAAKcwygH0 AAEAAQABAAAAAADvcpAEQQACAAIAAgAAAAABFSiSAfgAAwADAAMAAAAAAPOFHAJv0DqJzwMA RwAAAEcAAAAYAAAAAAAAAf8DACODIQEAGQEAAABDAAIAAgACAQAAAAAAAAAA//////////8J IARHAAAAAACJAAAAAACxFMkEQwACAAIAAgAAAAABDlidAm/QOjv3DAAqAAAAKgAAABgAAAAA AGdo/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABA2/QOiDfAwBn AAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlA BJcAAAAAAIkAAAAAAKcwygHxAAEAAQABAAAAAADvcpAEPgACAAIAAgAAAAABFSiSAfUAAwAD AAMAAAAAAPOFHANv0Do43wMARwAAAEcAAAAYAAEAAAAAAf8DACODIQEAGQEAAABDAAAAAACJ AAAAAAAAAAAA//////////8JIARHAAAAAACJAAAAAACxFMkEQQACAAIAAgAAAAABDlidCG/Q OszgAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD///// /////wlABJIAAAAAAIkAAAAAAKcwygHsAAEAAQABAAAAAADvcpAEOQACAAIAAgAAAAABFSiS AfAAAwADAAMAAAAAAPOFHAhv0Drn4AMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABD AAAAAACJAAAAAAAAAAAA//////////8JIARCAAAAAACJAAAAAACxFMkEPAACAAIAAgAAAAAB DlidCG/QOh0EDwAqAAAAKgAAABgAAQAAAGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEA gQHMhATAqMkBAQQDRQABCW/QOsQKDgAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwAC AAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABDW/QOm8JBABnAAAAZwAAABgAAQAAAGdo/wMA I4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABI0AAAAAAIkAAAAAAKcwygHn AAEAAQABAAAAAADvcpAENAACAAIAAgAAAAABFSiSAesAAwADAAMAAAAAAPOFHA1v0DqJCQQA RwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8J IAQ9AAAAAACJAAAAAACxFMkENwACAAIAAgAAAAABDlidEW/QOs5DDgAqAAAAKgAAABgAAQAA AAAA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABEm/QOgQLBABn AAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlA BIgAAAAAAIkAAAAAAKcwygHiAAEAAQABAAAAAADvcpAELwACAAIAAgAAAAABFSiSAeYAAwAD AAMAAAAAAPOFHBJv0DodCwQARwAAAEcAAAAYAAEAAAAAAf8DACODIQEAGQEAAABDAAAAAACJ AAAAAAAAAAAA//////////8JIAQ4AAAAAACJAAAAAACxFMkEMgACAAIAAgAAAAABDlidEm/Q OiNsBgAqAAAAKgAAABgAAAAAAP///wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATA qMkUAQQDRQABFm/QOjLVAwBnAAAAZwAAABgAAAAAAGdo/wMAI4MhAQAYAQAAAGMAAgACAAIB AAAAAAAAAAD//////////wlABIIAAAAAAIkAAAAAAKcwygHgAAEAAQABAAAAAADvcpAELQAC AAIAAgAAAAABFSiSAeQAAwADAAMAAAAAAPOFHBZv0Dpa1QMARwAAAEcAAAAYAAAAAAABAP8D ACODIQEAGQEAAABDAAIAAgACAQAAAAAAAAAA//////////8JIAQzAAAAAACJAAAAAACxFMkE LwACAAIAAgAAAAABDlidF2/QOrzlAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMA AAAAAIkAAAAAAAAAAAD//////////wlABIMAAAAAAIkAAAAAAKcwygHdAAEAAQABAAAAAADv cpAEKgACAAIAAgAAAAABFSiSAeEAAwADAAMAAAAAAPOFHBdv0DrV5QMARwAAAEcAAAAYAAEA AAABAP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIAQzAAAAAACJAAAA AACxFMkELQACAAIAAgAAAAABDlidGW/QOlrFDgAqAAAAKgAAABgAAQAAAGdo/wMAI4MUAQAR AQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABG2/QOsNLBAAqAAAAKgAAABgAAAAA AAAA/wMAI4MUAQARAQAAAwACAAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABHG/QOjnnAwBn AAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlA BH4AAAAAAIkAAAAAAKcwygHYAAEAAQABAAAAAADvcpAEJQACAAIAAgAAAAABFSiSAdwAAwAD AAMAAAAAAPOFHBxv0DpX5wMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABDAAAAAACJ AAAAAAAAAAAA//////////8JIAQuAAAAAACJAAAAAACxFMkEKAACAAIAAgAAAAABDlidIW/Q OuzoAwBnAAAAZwAAABgAAQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD///// /////wlABHkAAAAAAIkAAAAAAKcwygHTAAEAAQABAAAAAADvcpAEIAACAAIAAgAAAAABFSiS AdcAAwADAAMAAAAAAPOFHCFv0DoE6QMARwAAAEcAAAAYAAEAAAABAP8DACODIQEAGQEAAABD AAAAAACJAAAAAAAAAAAA//////////8JIAQpAAAAAACJAAAAAACxFMkEIwACAAIAAgAAAAAB DlidIm/QOqrgBwAqAAAAKgAAABgAAQAAAGdo/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEA gQHMhATAqMkBAQQDRQABI2/QOoOLDAAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwAC AAIAAgAbACYB8AEAgQHMhATAqMkUAQQDRQABJG/QOjYfCAAcAAAAHAAAABgAAAAAAAAA/wMA I4IYAQAEAHj3lApFAAEAAgACAAIAxgIAPCZv0Dqe6gMAZwAAAGcAAAAYAAEAAABnaP8DACOD IQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAR0AAAAAACJAAAAAACnMMoBzgAB AAEAAQAAAAAA73KQBBsAAgACAAIAAAAAARUokgHSAAMAAwADAAAAAADzhRwmb9A6tuoDAEcA AABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAE JAAAAAAAiQAAAAAAsRTJBB4AAgACAAIAAAAAAQ5YnSpv0DrSswMAZwAAAGcAAAAYAAAAAAAA AP8DACODIQEAGAEAAABjAAIAAgACAQAAAAAAAAAA//////////8JQARuAAAAAACJAAAAAACn MMoBzAABAAEAAQAAAAAA73KQBBkAAgACAAIAAAAAARUokgHQAAMAAwADAAAAAADzhRwqb9A6 97MDAEcAAABHAAAAGAAAAAAAAQD/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP////// ////CSAEHwAAAAAAiQAAAAAAsRTJBBsAAgACAAIAAAAAAQ5YnStv0Do97AMAZwAAAGcAAAAY AAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQARvAAAAAACJ AAAAAACnMMoByQABAAEAAQAAAAAA73KQBBYAAgACAAIAAAAAARUokgHNAAMAAwADAAAAAADz hRwrb9A6V+wDAEcAAABHAAAAGAABAAAAAQD/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAA AP//////////CSAEHwAAAAAAiQAAAAAAsRTJBBkAAgACAAIAAAAAAQ5YnStv0DqAlQcAKgAA ACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEEA0UA ASxv0DoZrAcAKgAAACoAAAAYAAAAAAAAAP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEB zIQEwKjJFAEEA0UAAS1v0DpLlgcAHAAAABwAAAAYAAEAAABnaP8DACOCGAEABAB4J+EKRQAB AAAAAACJAMYCADwwb9A60u0DAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAA iQAAAAAAAAAAAP//////////CUAEagAAAAAAiQAAAAAApzDKAcQAAQABAAEAAAAAAO9ykAQR AAIAAgACAAAAAAEVKJIByAADAAMAAwAAAAAA84UcMG/QOurtAwBHAAAARwAAABgAAQAAAAEA /wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBBoAAAAAAIkAAAAAALEU yQQUAAIAAgACAAAAAAEOWJ0zb9A6SHkDACoAAAAqAAAAGAABAAAAZ2j/AwAjgxQBABEBAAAD AAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAEzb9A6yGMEABEBAAARAQAAGAABAAAAAAD/ AwAjgxsBABQBAAABDQSuAAAAAACJAAAAAACyEsoDAQQDRQABgQHMhgTQERIThATQERITiQlN NS1EdWJsaW6AYACAgIDQERIT/////wqAgIDAqMkA////ABSAgIABAQEB/////wqAgIACAgIC /////xSAgIADAwMD/////xSAgIAKCgwA/////BSAgIAKCgwE/////BSAgIAKCg4A/////IdH AAAAACDQERITAAAAChjAqMkAAAAUIAEBAQEAAAAKIAICAgIAAAAUIAMDAwMAAAAUHgoKDAAA AAAUHgoKDAQAAAAUHgoKDgACDAAKgICAAAIAAgACABYXAAIAAgACAAAACgwGBMCoyQEIBMCo yRQzb9A6ALMOACoAAAAqAAAAGAAAAAAAAAD/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCB AcyEBMCoyRQBBANFAAE0b9A6GXoEACcAAAAnAAAAGAAAAAAAAAD/AwAjgxEBABsBAAAAIwAC AAIAAgEJEASrAAAAAACJAAAAAACyEso1b9A6Re8DAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEB ABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEZQAAAAAAiQAAAAAApzDKAb8AAQAB AAEAAAAAAO9ykAQMAAIAAgACAAAAAAEVKJIBwwADAAMAAwAAAAAA84UcNW/QOnUWBABHAAAA RwAAABgAAQAAAHVi/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKwA AAAAAIkAAAAAALISygQPAAIAAgACAAAAAAEOWJ06b9A6FvEDAGcAAABnAAAAGAABAAAAAAD/ AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEYAAAAAAAiQAAAAAApzDK AboAAQABAAEAAAAAAO9ykAQHAAIAAgACAAAAAAEVKJIBvgADAAMAAwAAAAAA84UcOm/QOi7x AwBHAAAARwAAABgAAQAAAAEA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD///////// /wkgBKcAAAAAAIkAAAAAALISygQKAAIAAgACAAAAAAEOWJ07b9A64jECACoAAAAqAAAAGAAA AAAAZ2j/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAE8b9A62eMA ACoAAAAqAAAAGAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEB BANFAAE+b9A6seADAGcAAABnAAAAGAAAAAAAZ2j/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAA AAAAAP//////////CUAEWgAAAAAAiQAAAAAApzDKAbgAAQABAAEAAAAAAO9ykAQFAAIAAgAC AAAAAAEVKJIBvAADAAMAAwAAAAAA84UcPm/QOtngAwBHAAAARwAAABgAAAAAAHVi/wMAI4Mh AQAZAQAAAEMAAgACAAIBAAAAAAAAAAD//////////wkgBKIAAAAAAIkAAAAAALISygQHAAIA AgACAAAAAAEOWJ0/b9A6r/IDAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAA iQAAAAAAAAAAAP//////////CUAEWwAAAAAAiQAAAAAApzDKAbUAAQABAAEAAAAAAO9ykAQC AAIAAgACAAAAAAEVKJIBuQADAAMAAwAAAAAA84UcP2/QOsfyAwBHAAAARwAAABgAAQAAAAEA /wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBKIAAAAAAIkAAAAAALIS ygQFAAIAAgACAAAAAAEOWJ1Cb9A6M6kCACoAAAAqAAAAGAAAAAAAZ2j/AwAjgxQBABEBAAAD AAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAFEb9A6S7sCACoAAAAqAAAAGAABAAAAAAD/ AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAFEb9A6TfQDAGcAAABn AAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEVgAA AAAAiQAAAAAApzDKAbAAAQABAAEAAAAAAO9ykAP9AAIAAgACAAAAAAEVKJIBtAADAAMAAwAA AAAA84UcRG/QOmT0AwBHAAAARwAAABgAAQAAAAAB/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAA AAAAAAD//////////wkgBJ0AAAAAAIkAAAAAALISygQAAAIAAgACAAAAAAEOWJ1Jb9A6+PUD AGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP////////// CUAEUQAAAAAAiQAAAAAApzDKAasAAQABAAEAAAAAAO9ykAP4AAIAAgACAAAAAAEVKJIBrwAD AAMAAwAAAAAA84UcSW/QOhH2AwBHAAAARwAAABgAAQAAAHVi/wMAI4MhAQAZAQAAAEMAAAAA AIkAAAAAAAAAAAD//////////wkgBJgAAAAAAIkAAAAAALISygP7AAIAAgACAAAAAAEOWJ1J b9A6ugsNABABAAAQAQAAGAAAAAAAAAD/AwAjgxsBABQBAAABDASuAAIAAgACAAAAAAEPVp4D AQQDRQABgQHMhgQCAgIChAQCAgICiQhNMTAtT3Nsb4BgAICAgAICAgL/////CoCAgAoKDAD/ ///8CoCAgAoKDAT////8CoCAgAoKDgD////8CoCAgAEBAQH/////CoCAgAMDAwP/////CoCA gMCoyQD///8ACoCAgNAREhP/////h0cAAAAAIAICAgIAAAAKHgoKDAAAAAAKHgoKDAQAAAAK HgoKDgAAAAAKIAEBAQEAAAAKIAMDAwMAAAAKGMCoyQAAAAog0BESEwIMAAqAgIAAAAAAAIkA FhcAAAAAAIkAAAAKDAYEwKjJFAgEwKjJAUpv0DqdIQwAKgAAACoAAAAYAAAAAABnaP8DACOD FAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAUpv0DqggQwAJwAAACcAAAAY AAEAAAAAAP8DACODEQEAGwEAAAAjAAAAAACJAAkQBKwAAgACAAIAAAAAAQ9Wnktv0DoF8w4A KgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfABAIEBzIQEwKjJAQEE A0UAAU5v0Drq9wMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAA AAAA//////////8JQARMAAAAAACJAAAAAACnMMoBpgABAAEAAQAAAAAA73KQA/MAAgACAAIA AAAAARUokgGqAAMAAwADAAAAAADzhRxOb9A6AvgDAEcAAABHAAAAGAABAAAAdWL/AwAjgyEB ABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEkwAAAAAAiQAAAAAAshLKBKgAAgAC AAIAAAAAAQ9WnlJv0DpZvwMAZwAAAGcAAAAYAAAAAAAAAP8DACODIQEAGAEAAABjAAIAAgAC AQAAAAAAAAAA//////////8JQARGAAAAAACJAAAAAACnMMoBpAABAAEAAQAAAAAA73KQA/EA AgACAAIAAAAAARUokgGoAAMAAwADAAAAAADzhRxSb9A6fr8DAEcAAABHAAAAGAAAAAAAgID/ AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP//////////CSAEjgAAAAAAiQAAAAAAshLK BKYAAgACAAIAAAAAAQ9WnlJv0DquPQkAKgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEAAAMA AgACAAIAGwAmAfABAIEBzIQEwKjJFAEEA0UAAVJv0DrODg0AMQEAADEBAAAYAAAAAAAAAP8D ACODGwEAEgEAAAEtBKwAAQABAAEAAAAAAPBwkQEBBANFAAGBAcyGBAEBAQGEBAEBAQGJB001 LU5pY2WAJACAgIABAQEB/////wqAgIAKCgwA/////AqAgIAKCgwE/////IcbAAAAACABAQEB AAAACh4KCgwAAAAACh4KCgwEAhcACoCAgAACAAIAAgAKgICAAAIAAgACABaWAAIAAgACAAAA CkAGBAoKDAEIBAoKDAILIEuT0cxLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cxLk9HMCgRLk9HM CQRLk9HMAwQAAAQAAAIAAgACAAAACkAGBAoKDAUIBAoKDAYLIEuT0cxLk9HMS5PRzEuT0cxL k9HMS5PRzEuT0cxLk9HMCgRLk9HMCQRLk9HMAwQAAAQAU2/QOjv5AwBnAAAAZwAAABgAAQAA AAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABEcAAAAAAIkAAAAA AKcwygSqAAEAAQABAAAAAADwcJED7gACAAIAAgAAAAABFSiSAaUAAwADAAMAAAAAAPOFHFNv 0DpT+QMARwAAAEcAAAAYAAEAAAAAI/8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//// //////8JIASOAAAAAACJAAAAAACyEsoEowACAAIAAgAAAAABD1aeU2/QOi7BCwAnAAAAJwAA ABgAAQAAAAAA/wMAI4MRAQAaAQAAACMAAAAAAIkACRAEqgABAAEAAQAAAAAA8HCRU2/QOjo2 DAAqAAAAKgAAABgAAQAAAAEA/wMAI4MUAQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkB AQQDRQABWG/QOvP6AwBnAAAAZwAAABgAAQAAAGdo/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAA AAAAAAD//////////wlABEIAAAAAAIkAAAAAAKcwygSlAAEAAQABAAAAAADwcJED6QACAAIA AgAAAAABFSiSAaAAAwADAAMAAAAAAPOFHFhv0DoO+wMARwAAAEcAAAAYAAEAAABpY/8DACOD IQEAGQEAAABDAAAAAACJAAAAAAAAAAAA//////////8JIASJAAAAAACJAAAAAACyEsoEngAC AAIAAgAAAAABD1aeW2/QOic3BAAqAAAAKgAAABgAAAAAAAAA/wMAI4MUAQARAQAAAwACAAIA AgAbACYB8AEAgQHMhATAqMkUAQQDRQABW2/QOrs0DgAqAAAAKgAAABgAAQAAAGdo/wMAI4MU AQARAQAAAwAAAAAAiQAbACYB8AEAgQHMhATAqMkBAQQDRQABXW/QOoD8AwBnAAAAZwAAABgA AQAAAAAA/wMAI4MhAQAYAQAAAGMAAAAAAIkAAAAAAAAAAAD//////////wlABD0AAAAAAIkA AAAAAKcwygSgAAEAAQABAAAAAADwcJED5AACAAIAAgAAAAABFSiSAZsAAwADAAMAAAAAAPOF HF1v0DqZ/AMARwAAAEcAAAAYAAEAAACAgP8DACODIQEAGQEAAABDAAAAAACJAAAAAAAAAAAA //////////8JIASEAAAAAACJAAAAAACyEsoEmQACAAIAAgAAAAABD1aeYG/QOo0wCAAcAAAA HAAAABgAAAAAAGdo/wMAI4IYAQAEAHj3lApFAAEAAgACAAIAxgIAPGJv0Do4/gMAZwAAAGcA AAAYAAEAAAAAAP8DACODIQEAGAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAQ4AAAA AACJAAAAAACnMMoEmwABAAEAAQAAAAAA8HCRA98AAgACAAIAAAAAARUokgGWAAMAAwADAAAA AADzhRxib9A6Uf4DAEcAAABHAAAAGAABAAAAgID/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAA AAAAAP//////////CSAEfwAAAAAAiQAAAAAAshLKBJQAAgACAAIAAAAAAQ9WnmJv0DoB6A4A KgAAACoAAAAYAAAAAABnaP8DACODFAEAEQEAAAMAAgACAAIAGwAmAfABAIEBzIQEwKjJFAEE A0UAAWNv0DpTLQAAKgAAACoAAAAYAAEAAAAAAP8DACODFAEAEQEAAAMAAAAAAIkAGwAmAfAB AIEBzIQEwKjJAQEEA0UAAWZv0DohxQMAZwAAAGcAAAAYAAAAAAAAAP8DACODIQEAGAEAAABj AAIAAgACAQAAAAAAAAAA//////////8JQAQyAAAAAACJAAAAAACnMMoEmQABAAEAAQAAAAAA 8HCRA90AAgACAAIAAAAAARUokgGUAAMAAwADAAAAAADzhRxmb9A6R8UDAEcAAABHAAAAGAAA AAAAgID/AwAjgyEBABkBAAAAQwACAAIAAgEAAAAAAAAAAP//////////CSAEegAAAAAAiQAA AAAAshLKBJIAAgACAAIAAAAAAQ9Wnmdv0DrR/wMAZwAAAGcAAAAYAAEAAABnaP8DACODIQEA GAEAAABjAAAAAACJAAAAAAAAAAAA//////////8JQAQzAAAAAACJAAAAAACnMMoElgABAAEA AQAAAAAA8HCRA9oAAgACAAIAAAAAARUokgGRAAMAAwADAAAAAADzhRxnb9A66f8DAEcAAABH AAAAGAABAAAAaWP/AwAjgyEBABkBAAAAQwAAAAAAiQAAAAAAAAAAAP//////////CSAEegAA AAAAiQAAAAAAshLKBI8AAgACAAIAAAAAAQ9Wnmlv0Dq4qQcAHAAAABwAAAAYAAEAAAAAAP8D ACOCGAEABAB4J+EKRQABAAAAAACJAMYCADxqb9A6F+4MACoAAAAqAAAAGAAAAAAAZ2j/AwAj gxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAFrb9A6I8gCACoAAAAqAAAA GAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAFsb9A6 VgEEAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP////// ////CUAELgAAAAAAiQAAAAAApzDKBJEAAQABAAEAAAAAAPBwkQPVAAIAAgACAAAAAAEVKJIB jAADAAMAAwAAAAAA84UcbG/QOm4BBABHAAAARwAAABgAAQAAAICA/wMAI4MhAQAZAQAAAEMA AAAAAIkAAAAAAAAAAAD//////////wkgBHUAAAAAAIkAAAAAALISygSKAAIAAgACAAAAAAEP Vp5tb9A6fPMKAMkAAADJAAAAGAAAAAAAZ2j/AwAjgxsBABIBAAAAxQSsAAMAAwADAAAAAAD0 gx0BAQQDRQABgQHMhgQDAwMDhAQDAwMDiQpNMjAtVmllbm5hgBgAgICAAwMDA/////8KgICA CgoOAP////yHEgAAAAAgAwMDAwAAAAoeCgoOAAIMAAqAgIAAAgACAAIAFksAAgACAAIAAAAK QAYECgoOAggECgoOAQsgS5PRzEuT0cxLk9HMS5PRzEuT0cxLk9HMS5PRzEuT0cwKBEuT0cwJ BEuT0cwDBAAAAABub9A6hKsHACcAAAAnAAAAGAABAAAAAgD/AwAjgxEBABoBAAAAIwAAAAAA iQAJEASqAAMAAwADAAAAAAD0gx1xb9A6BQMEAGcAAABnAAAAGAABAAAAAAD/AwAjgyEBABgB AAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEKQAAAAAAiQAAAAAApzDKBIwAAQABAAEA AAAAAPBwkQPQAAIAAgACAAAAAAEVKJIEpwADAAMAAwAAAAAA9IMdcW/QOh4DBABHAAAARwAA ABgAAQAAAICA/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBHAAAAAA AIkAAAAAALISygSFAAIAAgACAAAAAAEPVp5xb9A6cIwNACoAAAAqAAAAGAAAAAAAZ2j/AwAj gxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANFAAFzb9A6jxUOACoAAAAqAAAA GAABAAAAAAD/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAF2b9A6 nAQEAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP////// ////CUAEJAAAAAAAiQAAAAAApzDKBIcAAQABAAEAAAAAAPBwkQPLAAIAAgACAAAAAAEVKJIE ogADAAMAAwAAAAAA9IMddm/QOrQEBABHAAAARwAAABgAAQAAAAAC/wMAI4MhAQAZAQAAAEMA AAAAAIkAAAAAAAAAAAD//////////wkgBGsAAAAAAIkAAAAAALISygSAAAIAAgACAAAAAAEP Vp56b9A658oDAGcAAABnAAAAGAAAAAAAAAD/AwAjgyEBABgBAAAAYwACAAIAAgEAAAAAAAAA AP//////////CUAEHgAAAAAAiQAAAAAApzDKBIUAAQABAAEAAAAAAPBwkQPJAAIAAgACAAAA AAEVKJIEoAADAAMAAwAAAAAA9IMdem/QOg3LAwBHAAAARwAAABgAAAAAAICA/wMAI4MhAQAZ AQAAAEMAAgACAAIBAAAAAAAAAAD//////////wkgBGYAAAAAAIkAAAAAALISygR+AAIAAgAC AAAAAAEPVp56b9A69xgEACoAAAAqAAAAGAAAAAAAqMn/AwAjgxQBABEBAAADAAIAAgACABsA JgHwAQCBAcyEBMCoyRQBBANFAAF7b9A6XAYEAGcAAABnAAAAGAABAAAAZ2j/AwAjgyEBABgB AAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEHwAAAAAAiQAAAAAApzDKBIIAAQABAAEA AAAAAPBwkQPGAAIAAgACAAAAAAEVKJIEnQADAAMAAwAAAAAA9IMde2/QOnUGBABHAAAARwAA ABgAAQAAAAAC/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAAAAD//////////wkgBGYAAAAA AIkAAAAAALISygR7AAIAAgACAAAAAAEPVp58b9A6eM0CACoAAAAqAAAAGAABAAAAAAD/AwAj gxQBABEBAAADAAAAAACJABsAJgHwAQCBAcyEBMCoyQEBBANFAAGAb9A6/QcEAGcAAABnAAAA GAABAAAAZ2j/AwAjgyEBABgBAAAAYwAAAAAAiQAAAAAAAAAAAP//////////CUAEGgAAAAAA iQAAAAAApzDKBH0AAQABAAEAAAAAAPBwkQPBAAIAAgACAAAAAAEVKJIEmAADAAMAAwAAAAAA 9IMdgG/QOhUIBABHAAAARwAAABgAAQAAAAAC/wMAI4MhAQAZAQAAAEMAAAAAAIkAAAAAAAAA AAD//////////wkgBGEAAAAAAIkAAAAAALISygR2AAIAAgACAAAAAAEPVp6Bb9A6IEYCACoA AAAqAAAAGAAAAAAAAAD/AwAjgxQBABEBAAADAAIAAgACABsAJgHwAQCBAcyEBMCoyRQBBANF AAGDb9A6nr8KACoAAAAqAAAAGAABAAAAZ2j/AwAjgxQBABEBAAADAAAAAACJABsAJgHwAQCB AcyEBMCoyQEBBANFAAE= --PNTmBPCT7hxwcZjr-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 06:26:28 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10177 for ; Mon, 20 Aug 2001 06:26:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA66736; Mon, 20 Aug 2001 03:35:30 -0700 (PDT) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by external.juniper.net (8.9.3/8.9.3) with SMTP id DAA66721 for ; Mon, 20 Aug 2001 03:34:54 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Aug 2001 10:26:00 -0000 X-Apparently-From: Message-ID: <005d01c12963$0f49a3f0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Cc: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] OSPF and IS-IS Scalability Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 15:41:47 +0530 Content-Transfer-Encoding: 7bit Hi Dave OR if anybody else can clear this point .. I was going through your presentation archived at nanog where you have compared the two link state protocols viz IS-IS and OSPF .. I am working on IS-IS and am not much aware of OSPF and i was looking at the scalabilities issues related to both of the protocols. There you have said that the problem with OSPF is that in theory OSPF topology is limited to how much we can stuff in the router LSA as each router gets one router LSA and it cant be bigger than the biggest of the IP datagram (64K) and so can contain some O(5000) links. And the problem you said with IS-IS is the number of LSPs a single router can issue which is 256. My question is that how can we say that in OSPF a router has to stuff all its link database in ** one ** LSA. We have the mechanism of I-bit and the M-bit wherein we control the division of a large topological database description into multiple messages. Can you please throw some light on this. Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 09:57:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20923 for ; Mon, 20 Aug 2001 09:57:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA67599; Mon, 20 Aug 2001 07:06:30 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by external.juniper.net (8.9.3/8.9.3) with SMTP id HAA67587 for ; Mon, 20 Aug 2001 07:05:17 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 20 Aug 2001 13:56:21 -0000 X-Apparently-From: Message-ID: <002701c12980$72129e20$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Manral, Vishwas" Cc: References: Subject: Re: [Isis-wg] OSPF and IS-IS Scalability Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 19:30:05 +0530 Content-Transfer-Encoding: 7bit Hi Manral, I was able to do this calculation but what i wanted to ask was .. Where is it mentioned that a router can originate only one-router LSA for each area it is connected to .. as i understand during the database exchange process the routers form a master/slave relationship, the master being first to transmit. The master sends database description packets to the slave to describe its database of link state information. Flags in database description packets indicate whether they are form the master or slave (the M/S bit), the first such packet (the I bit) and if there are more packets to come (the M bit). Database exchange is complete when a router recieves a database description packet from its neighbor with the M bit off. If this is so then there is no limit on the size of the LSAs an OSPF router can advertise. I am copying it on to the list so that others can chime in and help us out .. Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: "'Manav Bhatia'" Cc: Sent: Monday, August 20, 2001 5:02 PM Subject: RE: [Isis-wg] OSPF and IS-IS Scalability > Hi Manav/Dave, > > Well each router can originate only one router LSA for each area it is > connected to. > > Each link in the router can take up at most 24 bytes. The maximum size of a > ospf LS-Update packet is 2^16, as the packet length of the ospf header is 24 > bytes. So the total number of links maximum is about 2^16/ 24 is > approximately equal to 2730. > > However if we take the minimum link size per link in the router lsa, then > the max is about 2730 * 2, or O(5000). > > Tell me Dave where i m wrong, or is it the IP packet we are talking about? > > Thanks, > Vishwas > > > > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Monday, August 20, 2001 3:42 PM > To: isis-wg@spider.juniper.net > Cc: dkatz@juniper.com > Subject: [Isis-wg] OSPF and IS-IS Scalability > > > Hi Dave OR if anybody else can clear this point .. > > I was going through your presentation archived at nanog where you have > compared the two link state protocols viz IS-IS and OSPF .. I am working on > IS-IS and am not much aware of OSPF and i was looking at the scalabilities > issues related to both of the protocols. There you have said that the > problem with OSPF is that in theory OSPF topology is limited to how much we > can stuff in the router LSA as each router gets one router LSA and it cant > be bigger than the biggest of the IP datagram (64K) and so can contain some > O(5000) links. > And the problem you said with IS-IS is the number of LSPs a single router > can issue which is 256. My question is that how can we say that in OSPF a > router has to stuff all its link database in ** one ** LSA. We have the > mechanism of I-bit and the M-bit wherein we control the division of a large > topological database description into multiple messages. > > Can you please throw some light on this. > > Thanks and Regards, > Manav Bhatia > "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 18:09:36 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05560 for ; Mon, 20 Aug 2001 18:09:35 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69611; Mon, 20 Aug 2001 15:18:31 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69599 for ; Mon, 20 Aug 2001 15:17:35 -0700 (PDT) Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f7KM8Zj14870; Mon, 20 Aug 2001 15:08:35 -0700 From: Henk Smit Message-Id: <200108202208.f7KM8Zj14870@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Initialisation question To: hannes@juniper.net (Hannes Gredler) Cc: jgreenha@eu.uu.net (John Greenhalgh), isis-wg@spider.juniper.net In-Reply-To: <20010819161418.A12747@juniper.net> from "Hannes Gredler" at Aug 19, 2001 04:14:18 PM X-Mailer: ELM [version 2.5 PL3] 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 15:08:35 -0700 (PDT) Content-Transfer-Encoding: 7bit > | Sorry I should have said that I'd read that bit, but I'm still not > | clear exactly what happens. I guess that once two routers are adjacent > | they exchange CSNPs and then send PSNPs for > | any LSPs they are short of or are old? Correct? You have been reading rfc2328, haven't you. :-) > correct - for your convenience i have attached a tcpdump > to see what happens; Sorry, this is not correct. When a p2p adjacency comes up, both routers: 1) for each LSP in the LSPDB, set the SRM bit for this interface 2) send a CSNP (note, can consist of multiple packets) 3) wait for a while to give the other router some time to send a CSNP 4) hopefully receive a CNSP 5) when they receive the CSNP from the other side, clear the SRM bit for all LSPs that the other router already seems to have 6) send all LSPs that still have the SRM bit set If the CSNP from the other router gets lost somewhere, you will end up sending all LSPs. This might be some unnecessary work, but it will guarantee that the LSPDBs will be in sync. henk. > > | > | > | On Sun, 19 Aug 2001, Hannes Gredler wrote: > | > | > On Sun, Aug 19, 2001 at 09:44:34AM +0000, John Greenhalgh wrote: > | > | Hi, > | > | > | > | I'm looking through ISO 10589 and trying to understand how routers learn > | > | the link state database once adjacencies have been formed. For broadcast I > | > | gather that the CSNP from the DIS will initiate an update, but what about > | > | on point-to-point? Any pointers gladly received! > | > > | > john, > | > > | > take a look at paragraph 7.3.20.2.e where it says: > | > > | > [ ... ] CSNPs are transmited on > | > point-to-point circuits at initialisation. > | > > | > HTH, > | > > | > /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 18:18:29 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05720 for ; Mon, 20 Aug 2001 18:18:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69697; Mon, 20 Aug 2001 15:27:30 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69685 for ; Mon, 20 Aug 2001 15:26:21 -0700 (PDT) Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f7KMGiL14888; Mon, 20 Aug 2001 15:16:44 -0700 From: Henk Smit Message-Id: <200108202216.f7KMGiL14888@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] OSPF and IS-IS Scalability To: mnvbhatia@yahoo.com Cc: VishwasM@netplane.com (Manral Vishwas), isis-wg@spider.juniper.net In-Reply-To: <002701c12980$72129e20$da046c6b@Manav> from "Manav Bhatia" at Aug 20, 2001 07:30:05 PM X-Mailer: ELM [version 2.5 PL3] 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 15:16:44 -0700 (PDT) Content-Transfer-Encoding: 7bit This seems a question for the ospf mailinglist ..... In OSPF there is no limit to the number of LSAs in the LSDB. The I/M bit mechanism you describe helps in that respect. But the problem is that even though the LSDB can contain as many packets as you want, each packet is limited in size to 64K. The description of a single router *has* to be done in one single router LSA. That means the router LSA can not be bigger than 64KB, or you will not be able to send it to your neighbors. The only way an OSPF router can advertise which routers it is directly adjacent to, is by including those inside its router LSA. So if the router LSA can only be 64KB, the number of neighbors that can be advertised is limited. Henk. > Hi Manral, > I was able to do this calculation but what i wanted to ask was .. > Where is it mentioned that a router can originate only one-router LSA for > each area it is connected to .. as i understand during the database exchange > process the routers form a master/slave relationship, the master being first > to transmit. The master sends database description packets to the slave to > describe its database of link state information. Flags in database > description packets indicate whether they are form the master or slave (the > M/S bit), the first such packet (the I bit) and if there are more packets to > come (the M bit). Database exchange is complete when a router recieves a > database description packet from its neighbor with the M bit off. > > If this is so then there is no limit on the size of the LSAs an OSPF router > can advertise. > > I am copying it on to the list so that others can chime in and help us out > .. > > Regards, > Manav > > ----- Original Message ----- > From: "Manral, Vishwas" > To: "'Manav Bhatia'" > Cc: > Sent: Monday, August 20, 2001 5:02 PM > Subject: RE: [Isis-wg] OSPF and IS-IS Scalability > > > > Hi Manav/Dave, > > > > Well each router can originate only one router LSA for each area it is > > connected to. > > > > Each link in the router can take up at most 24 bytes. The maximum size of > a > > ospf LS-Update packet is 2^16, as the packet length of the ospf header is > 24 > > bytes. So the total number of links maximum is about 2^16/ 24 is > > approximately equal to 2730. > > > > However if we take the minimum link size per link in the router lsa, then > > the max is about 2730 * 2, or O(5000). > > > > Tell me Dave where i m wrong, or is it the IP packet we are talking about? > > > > Thanks, > > Vishwas > > > > > > > > -----Original Message----- > > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > > Sent: Monday, August 20, 2001 3:42 PM > > To: isis-wg@spider.juniper.net > > Cc: dkatz@juniper.com > > Subject: [Isis-wg] OSPF and IS-IS Scalability > > > > > > Hi Dave OR if anybody else can clear this point .. > > > > I was going through your presentation archived at nanog where you have > > compared the two link state protocols viz IS-IS and OSPF .. I am working > on > > IS-IS and am not much aware of OSPF and i was looking at the scalabilities > > issues related to both of the protocols. There you have said that the > > problem with OSPF is that in theory OSPF topology is limited to how much > we > > can stuff in the router LSA as each router gets one router LSA and it cant > > be bigger than the biggest of the IP datagram (64K) and so can contain > some > > O(5000) links. > > And the problem you said with IS-IS is the number of LSPs a single router > > can issue which is 256. My question is that how can we say that in OSPF a > > router has to stuff all its link database in ** one ** LSA. We have the > > mechanism of I-bit and the M-bit wherein we control the division of a > large > > topological database description into multiple messages. > > > > Can you please throw some light on this. > > > > Thanks and Regards, > > Manav Bhatia > > "C is not a big language, and is not well served by a big book." -- K&R2 > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 18:38:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06212 for ; Mon, 20 Aug 2001 18:38:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69833; Mon, 20 Aug 2001 15:47:31 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69816 for ; Mon, 20 Aug 2001 15:46:56 -0700 (PDT) Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f7KMbwe14947; Mon, 20 Aug 2001 15:37:58 -0700 From: Henk Smit Message-Id: <200108202237.f7KMbwe14947@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Doubts on Traffic Engineering To: sachidananda_k@hotmail.com (Sachidananda K) Cc: isis-wg@spider.juniper.net In-Reply-To: from "Sachidananda K" at Aug 08, 2001 02:23:14 PM X-Mailer: ELM [version 2.5 PL3] 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 15:37:58 -0700 (PDT) Content-Transfer-Encoding: 7bit > Hello, > I have some doubts related to the traffic engineering related draft > associated with IS - IS. According to the Draft > draft-ietf-isis-traffic-03.txt, certain TLVs are modified to add Information > on traffic Engineering. > These are: > 1. IS Reachability TLV > 2. IP Reachability TLV > > My questions: > Queries Regarding the Extended IS Reachability TLV > ------------------------------------------------------------- > 1. Sub TLV: 3 Description: Administrative Group > Query: > a. Who assigns the Adminstrative Group for the Router. Is it a configurable > parameter ? Quote: 4.1 Sub-TLV 3: Administrative group (color, resource class) The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Answer: the network administrator. Note, "Adminstrative Group" is not something assigned to a router. It is assigned to a link. > b. Is this sub-TLV a must or optional ? All sub-TLVs of TLV22 are optional. > ------------------------------------------------------------- > 2. Sub TLV: 9, 10 & 11 > Query: > a. How do we come to know about the Maximum Link bandwidth of the Link ? It is defined by the layer2 properties of the link (example: ethernet is 10 Mbps), or configured by the network administator. > b. Are there any Functional Computation for this purpose ? No idea. Don't think so. > c. Or can this be included as a configurable Parameter? Yes. > d. Is this sub-TLV a must or optional ? All sub-TLVs of TLV22 are optional. > -------------------------------------------------------------- > 3. Sub TLV: 18 Description: Traffic Engineering Default metric > Query: > a. Is this a configurable Parameter ? Yes. > b. Is this sub-TLV optional or must ? All sub-TLVs of TLV22 are optional. > ------------------------------------------------------------ > Queries Regarding Extended IP Reachability TLV > Are there any sub-TLVs defined for this TLV after the publishing of the > draft ? Not that I know of. You can check the drafts yourself at: http://www.ietf.org/html.charters/isis-charter.html > ------------------------------------------------------------ > I was also wondering if the implementation compliant with this draft is to > transmit all the TLVs (IP internal reachibility, IP external reachibility > and IP extended reachibility) or should it transmit either 2 or 1 of these > depending on circumstances. Depends on circumstances. To make use of the wider metrics of the newer TLVs, all routers inside an area (or participating in the L2 backbone) must understand the new TLVs. Once all routers are upgraded and configured to understand the new TLVs, then there is no benefit anymore in advertising the older type TLVs. So typically you will see routers only advertise both old and new TLVs during a (short) transition period. > Can you please suggest any standard/draft that answers all my questions if > at all there is any. > > I shall be obliged to receive early response. > Thanking you in advance for all the responses. > Sachi It would be nice if you would ask these questions from an email account that shows us who you are. Hotmail addresses are a bit impersonal. Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 18:48:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06335 for ; Mon, 20 Aug 2001 18:48:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69924; Mon, 20 Aug 2001 15:57:31 -0700 (PDT) Received: from redd3174.procket.com (flowpoint.procket.com [209.140.237.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA69912 for ; Mon, 20 Aug 2001 15:56:35 -0700 (PDT) Received: (from henk@localhost) by redd3174.procket.com (8.11.0/8.9.3) id f7KMkvg14996; Mon, 20 Aug 2001 15:46:57 -0700 From: Henk Smit Message-Id: <200108202246.f7KMkvg14996@redd3174.procket.com> X-Confidential: Procket Confidential/Need to know Subject: Re: [Isis-wg] Routing or forwarding To: jparker@axiowave.com (Jeff Parker) Cc: Anand@ambernetworks.com ('Anand Ammundi'), isis-wg@spider.juniper.net ('isis-wg@spider.juniper.net') In-Reply-To: from "Jeff Parker" at Aug 10, 2001 10:07:37 AM X-Mailer: ELM [version 2.5 PL3] 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 15:46:57 -0700 (PDT) Content-Transfer-Encoding: 7bit > An alternative proposal to deal with the cell tax was > proposed which encodes both IP and ISIS traffic "raw", > and demultiplexes based on the difference between > the first nibble of the NLPID for ISIS (0x8) and > the version number for IP (0x4 or 0x6). This proposal > seems to have aged off the list, but gathered support > from several vendors. I wrote the draft for that proposal when I was at a previous job. At the time I contacted a few large ISPs that had ATM backbones. Nobody seemed to be really interested to save some bandwidth. Some because they had enough bandwidth, some because they were planning to move to PacketOverSonet (and MPLS). So I never commited the changes to my former employer's software. And because my idea had no been deployed, I let the draft die. Are there really people using this hack to run ISIS and IP over one aal5mux VC ? I'd be very interested to hear from them. Thanks, Henk. > > ps: Though I don't think the spec has anything against ISIS > > running over IP, but I doubt if there are any such > > implementations on the field. > > A bit of history on this... > > There -was- a draft proposal to run ISIS over IP. A number > of reasons were put forward for this, including allowing > larger LSPs (let IP handle fragmentation) and avoiding > something refered to as the "ATM cell tax" that came about > if you needed to multiplex two protocols over ATM, and the > resulting effect of requiring two ATM cells to hols a TCP > Ack. There were folks who implemented this encapsulation. > > The chief driving force for seemed to be avoiding > the cell tax: there were doubts that adding a second > layer of fragmentation was a good thing. > > An alternative proposal to deal with the cell tax was > proposed which encodes both IP and ISIS traffic "raw", > and demultiplexes based on the difference between > the first nibble of the NLPID for ISIS (0x8) and > the version number for IP (0x4 or 0x6). This proposal > seems to have aged off the list, but gathered support > from several vendors. > > - jeff parker > - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 20 18:58:04 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06566 for ; Mon, 20 Aug 2001 18:58:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA70022; Mon, 20 Aug 2001 16:07:31 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA70010 for ; Mon, 20 Aug 2001 16:06:53 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Henk Smit'" , Jeff Parker Cc: Anand@ambernetworks.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Routing or forwarding 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 18:57:40 -0400 > > An alternative proposal to deal with the cell tax was > > proposed which ... demultiplexes based on the ... > > the first nibble > > I wrote the draft for that proposal when I was at a previous job. > At the time I contacted a few large ISPs that had ATM backbones. > Nobody seemed to be really interested to save some bandwidth. > Some because they had enough bandwidth, some because they were > planning to move to PacketOverSonet (and MPLS). > So I never commited the changes to my former employer's software. > And because my idea had no been deployed, I let the draft die. > > Are there really people using this hack to run ISIS and IP over > one aal5mux VC ? I'd be very interested to hear from them. > Thanks, > > Henk. Henk - And I was counting your former employer as one vendor! In a previous life, I heard from ISPs that were interested in removing the ATM cell tax, and suspect that concern remains. We all know that not everything that is requested and delivered is deployed. I have heard more than one vendor discuss your proposal with interest. I don't know of any deployments. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 02:25:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00575 for ; Tue, 21 Aug 2001 02:25:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA71819; Mon, 20 Aug 2001 23:34:31 -0700 (PDT) Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA71807 for ; Mon, 20 Aug 2001 23:33:12 -0700 (PDT) Received: from narayananl ([10.110.8.191]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GIEN0E00.47K for ; Tue, 21 Aug 2001 14:21:50 +0800 Message-ID: <001a01c12a0a$1f4a7f20$bf086e0a@huawei.com> Reply-To: "Lakshminarayanan Rajamanickam" From: "Lakshminarayanan Rajamanickam" To: Organization: FS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C12A4D.2C9CB380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Isis-wg] P2MP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 14:25:49 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C12A4D.2C9CB380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, I have some doubts related to ISIS over NBMA networks: why doesn't ISIS support the *real* NBMA directly (not supporting p2mp! = but treating it as a collection of p2p circuits) are there any major(!) protocol changes need to be done to ISIS for = supporting NBMA p2mp? also i would like to know if there is any vendor supporting this = feature(p2mp support)? any response in this regard would be of great helpful thanks in advance, lakshminarayan r ------=_NextPart_000_0017_01C12A4D.2C9CB380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
I have some doubts related to ISIS = over NBMA=20 networks:
why doesn't ISIS support the *real* = NBMA directly=20 (not supporting p2mp! 
but treating it as a collection of p2p=20 circuits)
are there any major(!) = protocol changes=20 need to be done to ISIS for supporting NBMA p2mp?
also i would like to know=20 if there is any vendor supporting this feature(p2mp=20 support)?
any response in this regard would be of = great=20 helpful
 
thanks in advance,
lakshminarayan r
 
------=_NextPart_000_0017_01C12A4D.2C9CB380-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 02:49:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01081 for ; Tue, 21 Aug 2001 02:49:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA71977; Mon, 20 Aug 2001 23:58:31 -0700 (PDT) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA71960 for ; Mon, 20 Aug 2001 23:57:24 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7L6mO094680; Mon, 20 Aug 2001 23:48:24 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id XAA19125; Mon, 20 Aug 2001 23:48:24 -0700 (PDT) Message-Id: <200108210648.XAA19125@cirrus.juniper.net> From: Dave Katz To: eta_narayananl@partner.huawei.com CC: isis-wg@spider.juniper.net In-reply-to: <001a01c12a0a$1f4a7f20$bf086e0a@huawei.com> (eta_narayananl@partner.huawei.com) Subject: Re: [Isis-wg] P2MP Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 20 Aug 2001 23:48:24 -0700 (PDT) ISIS predated much of the growth of NBMA networks. Having said that, I've always maintained that OSPF's P2MP mode is essentially a hack for vendors that did not allow the creation of virtual point-to-point interfaces over NBMA at the system level, since this is effectively what P2MP mode emulates. It would probably be a smaller hack to ISIS to support this than it was to OSPF (since ISIS couldn't care less about IP subnets, as far as its own operation is concerned) but there doesn't seem to be any real call for it. why doesn't ISIS support the *real* NBMA directly (not supporting p2mp! = but treating it as a collection of p2p circuits) are there any major(!) protocol changes need to be done to ISIS for = supporting NBMA p2mp? also i would like to know if there is any vendor supporting this = feature(p2mp support)? any response in this regard would be of great helpful _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 07:04:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04154 for ; Tue, 21 Aug 2001 07:04:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73323; Tue, 21 Aug 2001 04:13:31 -0700 (PDT) Received: from hotmail.com (f54.law3.hotmail.com [209.185.241.54]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73311 for ; Tue, 21 Aug 2001 04:12:39 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 Aug 2001 04:03:39 -0700 Received: from 202.9.170.10 by lw3fd.law3.hotmail.msn.com with HTTP; Tue, 21 Aug 2001 11:03:39 GMT X-Originating-IP: [202.9.170.10] From: "Sachidananda K" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Aug 2001 11:03:39.0447 (UTC) FILETIME=[EEB12C70:01C12A30] Subject: [Isis-wg] Protocol parameter. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 11:03:39 +0000 Hello, I have some questions related to the parameter minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of ISO 10589. Does this parameter corresponds to the frequency at which Link State Database is scanned for transmitting the LSP? That is every minimumBroadcastLSPTransmissionInterval duration the Link state database MUST be scanned for searching the LSP to be sent. Or it corresponds to the minimum time interval that needs to be allowed between consecutive packets (be it of any type) on a LAN interface? that is suppose on a particular interface (say A) if a LSP is sent, then for the next minimumBroadcastLSPTransmissionInterval duration no other packets of any type is to be sent on this interface. Apart from this, if the point 1 is not true, then is there any parameter that dictates the frequency at which the link state database is to be scanned for searching the LSP to be sent? Thanking in advance for all early responses that I receive. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 07:31:05 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05348 for ; Tue, 21 Aug 2001 07:31:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73535; Tue, 21 Aug 2001 04:40:32 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73515 for ; Tue, 21 Aug 2001 04:39:35 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7LBUYs91990 for ; Tue, 21 Aug 2001 04:30:35 -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.2966); Tue, 21 Aug 2001 04:28:08 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05191; Tue, 21 Aug 2001 07:27:12 -0400 (EDT) Message-Id: <200108211127.HAA05191@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 Aug 2001 11:28:08.0921 (UTC) FILETIME=[5A911C90:01C12A34] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 07:27:11 -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 for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-04.txt Pages : 11 Date : 20-Aug-01 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-traffic-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-traffic-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010820142205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820142205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 08:44:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08890 for ; Tue, 21 Aug 2001 08:44:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA73879; Tue, 21 Aug 2001 05:53:31 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id FAA73867 for ; Tue, 21 Aug 2001 05:52:46 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2001 12:43:28 -0000 X-Apparently-From: Message-ID: <00a301c12a3f$6d2c98b0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Sachidananda K" Cc: References: Subject: Re: [Isis-wg] Protocol parameter. Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 18:16:16 +0530 Content-Transfer-Encoding: 7bit Please find my comments inline .. > Does this parameter corresponds to the frequency at which Link State > Database is scanned for transmitting the LSP? That is every > minimumBroadcastLSPTransmissionInterval duration the Link state database > MUST be scanned for searching the LSP to be sent. Yes. Setting the SRMflag does not cause the LSP to be transmitted immediately. Instead the IS scans the database after every minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted randomly. Once this is done the SRMflag for the corresponding LSP is cleared. Hope this helps, Manav Bhatia > > Or it corresponds to the minimum time interval that needs to be allowed > between consecutive packets (be it of any type) on a LAN interface? that is > suppose on a particular interface (say A) if a LSP is sent, then for the > next minimumBroadcastLSPTransmissionInterval duration no other packets of > any type is to be sent on this interface. > > Apart from this, if the point 1 is not true, then is there any parameter > that dictates the frequency at which the link state database is to be > scanned for searching the LSP to be sent? > > Thanking in advance for all early responses that I receive. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 09:58:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13690 for ; Tue, 21 Aug 2001 09:58:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA74254; Tue, 21 Aug 2001 07:07:31 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA74242 for ; Tue, 21 Aug 2001 07:06:29 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7LDvSs93574 for ; Tue, 21 Aug 2001 06:57:28 -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.2966); Tue, 21 Aug 2001 06:46:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12794; Tue, 21 Aug 2001 09:45:58 -0400 (EDT) Message-Id: <200108211345.JAA12794@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 Aug 2001 13:46:56.0343 (UTC) FILETIME=[BE18DE70:01C12A47] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-traffic-04.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 09:45:58 -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 for Traffic Engineering Author(s) : T. Li, H. Smit Filename : draft-ietf-isis-traffic-04.txt Pages : 11 Date : 20-Aug-01 This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-traffic-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-traffic-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010820142205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-traffic-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-traffic-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820142205.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 11:05:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19162 for ; Tue, 21 Aug 2001 11:05:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA74570; Tue, 21 Aug 2001 08:14:31 -0700 (PDT) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA74558 for ; Tue, 21 Aug 2001 08:13:33 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7LF4S008022; Tue, 21 Aug 2001 08:04:28 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id IAA19768; Tue, 21 Aug 2001 08:04:28 -0700 (PDT) Message-Id: <200108211504.IAA19768@cirrus.juniper.net> From: Dave Katz To: mnvbhatia@yahoo.com CC: sachidananda_k@hotmail.com, isis-wg@spider.juniper.net In-reply-to: <00a301c12a3f$6d2c98b0$da046c6b@Manav> (mnvbhatia@yahoo.com) Subject: Re: [Isis-wg] Protocol parameter. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 08:04:28 -0700 (PDT) Of course, any implementation that actually scans the database looking for things to send will probably have other intractable scaling problems as well. Unlike the OSPF spec, the ISIS spec provides very little implementation guidance (a feature, I believe, as it promotes actual thinking.) All that minimumBroadcastLSPTransmissionInterval does is ensure that the transmission rate is controlled so you don't swamp your receivers (as there is no flow control in the protocol.) X-Apparently-From: Reply-To: "Manav Bhatia" From: "Manav Bhatia" Cc: References: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 18:16:16 +0530 Please find my comments inline .. > Does this parameter corresponds to the frequency at which Link State > Database is scanned for transmitting the LSP? That is every > minimumBroadcastLSPTransmissionInterval duration the Link state database > MUST be scanned for searching the LSP to be sent. Yes. Setting the SRMflag does not cause the LSP to be transmitted immediately. Instead the IS scans the database after every minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted randomly. Once this is done the SRMflag for the corresponding LSP is cleared. Hope this helps, Manav Bhatia > > Or it corresponds to the minimum time interval that needs to be allowed > between consecutive packets (be it of any type) on a LAN interface? that is > suppose on a particular interface (say A) if a LSP is sent, then for the > next minimumBroadcastLSPTransmissionInterval duration no other packets of > any type is to be sent on this interface. > > Apart from this, if the point 1 is not true, then is there any parameter > that dictates the frequency at which the link state database is to be > scanned for searching the LSP to be sent? > > Thanking in advance for all early responses that I receive. > Sachi > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 11:13:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19527 for ; Tue, 21 Aug 2001 11:13:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA74632; Tue, 21 Aug 2001 08:22:32 -0700 (PDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA74620 for ; Tue, 21 Aug 2001 08:21:10 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2001 15:12:07 -0000 X-Apparently-From: Message-ID: <010201c12a54$3097d1c0$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Dave Katz" Cc: , References: <200108211504.IAA19768@cirrus.juniper.net> Subject: Re: [Isis-wg] Protocol parameter. Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 20:45:54 +0530 Content-Transfer-Encoding: 7bit > Of course, any implementation that actually scans the database looking > for things to send will probably have other intractable scaling problems > as well. Why so ?? Is it because .. if there is a large toplogy then scanning the entire database will take up a lot of time .. which is not required out of a routing protocol because of the convergence issues .. Regards, Manav > > Unlike the OSPF spec, the ISIS spec provides very little implementation > guidance (a feature, I believe, as it promotes actual thinking.) > > All that minimumBroadcastLSPTransmissionInterval does is ensure that > the transmission rate is controlled so you don't swamp your receivers > (as there is no flow control in the protocol.) > > X-Apparently-From: > Reply-To: "Manav Bhatia" > From: "Manav Bhatia" > Cc: > References: > Organization: Samsung India Operations > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 21 Aug 2001 18:16:16 +0530 > > Please find my comments inline .. > > > Does this parameter corresponds to the frequency at which Link State > > Database is scanned for transmitting the LSP? That is every > > minimumBroadcastLSPTransmissionInterval duration the Link state database > > MUST be scanned for searching the LSP to be sent. > > Yes. Setting the SRMflag does not cause the LSP to be transmitted > immediately. Instead the IS scans the database after every > minimumBroadcastLSPTransmissionInterval and choses the LSP to be multicasted > randomly. Once this is done the SRMflag for the corresponding LSP is > cleared. > > Hope this helps, > Manav Bhatia > > > > > Or it corresponds to the minimum time interval that needs to be allowed > > between consecutive packets (be it of any type) on a LAN interface? that > is > > suppose on a particular interface (say A) if a LSP is sent, then for the > > next minimumBroadcastLSPTransmissionInterval duration no other packets of > > any type is to be sent on this interface. > > > > Apart from this, if the point 1 is not true, then is there any parameter > > that dictates the frequency at which the link state database is to be > > scanned for searching the LSP to be sent? > > > > Thanking in advance for all early responses that I receive. > > Sachi > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 11:16:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19724 for ; Tue, 21 Aug 2001 11:16:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA74678; Tue, 21 Aug 2001 08:26:32 -0700 (PDT) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA74666 for ; Tue, 21 Aug 2001 08:25:26 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7LFGO008341; Tue, 21 Aug 2001 08:16:24 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id IAA19811; Tue, 21 Aug 2001 08:16:24 -0700 (PDT) Message-Id: <200108211516.IAA19811@cirrus.juniper.net> From: Dave Katz To: mnvbhatia@yahoo.com CC: sachidananda_k@hotmail.com, isis-wg@spider.juniper.net In-reply-to: <010201c12a54$3097d1c0$da046c6b@Manav> (mnvbhatia@yahoo.com) Subject: Re: [Isis-wg] Protocol parameter. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 08:16:24 -0700 (PDT) Why so ?? Is it because .. if there is a large toplogy then scanning the entire database will take up a lot of time .. which is not required out of a routing protocol because of the convergence issues .. Basically. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 12:19:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22630 for ; Tue, 21 Aug 2001 12:19:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA75049; Tue, 21 Aug 2001 09:27:31 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA75037 for ; Tue, 21 Aug 2001 09:26:29 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 21 Aug 2001 16:17:25 -0000 X-Apparently-From: Message-ID: <003301c12a5d$502658a0$da046c6b@Manav> From: "Mareline Sheldon" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] ISH PDUs ? Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 21:51:16 +0530 Content-Transfer-Encoding: 7bit Hi, I am supposed to write an implementation of integrated IS-IS which i know i will be running over tcp/ip networks only. Knowing this, do i need to issue ISHs .. for i know all my end systems (if any) have to be manually configured ? Regards, Mary _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 14:10:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26069 for ; Tue, 21 Aug 2001 14:10:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA75549; Tue, 21 Aug 2001 11:19:32 -0700 (PDT) Received: from hotmail.com (f61.pav2.hotmail.com [64.4.37.61]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA75537 for ; Tue, 21 Aug 2001 11:18:24 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 Aug 2001 11:09:21 -0700 Received: from 47.211.0.13 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 21 Aug 2001 18:09:21 GMT X-Originating-IP: [47.211.0.13] From: "Chris isis" To: isis-wg@spider.juniper.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Aug 2001 18:09:21.0957 (UTC) FILETIME=[6736E550:01C12A6C] Subject: [Isis-wg] Redistribution of routes from ISIS to OSPF Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 19:09:21 +0100 I have not been able to identify a vendor that offers redistribution of IP routes between Integrated IS-IS and OSPF. Have I not looked hard enough? or is it particularly difficult, or even impossible to redistribute routes from OSPF into Integrated IS-IS and the other way around. Thanks, Chris. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 14:42:01 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27256 for ; Tue, 21 Aug 2001 14:42:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA75725; Tue, 21 Aug 2001 11:51:31 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA75713 for ; Tue, 21 Aug 2001 11:50:07 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA18093; Tue, 21 Aug 2001 20:40:58 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010821203310.033cdf60@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Chris isis" From: stefano previdi Subject: Re: [Isis-wg] Redistribution of routes from ISIS to OSPF Cc: isis-wg@spider.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 20:38:07 +0200 At 20:09 21/08/2001, Chris isis wrote: >I have not been able to identify a vendor that offers redistribution of IP >routes between Integrated IS-IS and OSPF. > >Have I not looked hard enough? I believe so....I know at least one vendor doing it and doubt it's the only one... >or is it particularly difficult, or even impossible to redistribute routes >from OSPF into Integrated IS-IS and the other way around. whoever implements routing protocols should be able to allow redistribution between them. s. >Thanks, Chris. > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 15:14:53 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28804 for ; Tue, 21 Aug 2001 15:14:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA75873; Tue, 21 Aug 2001 12:21:32 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id MAA75861 for ; Tue, 21 Aug 2001 12:20:15 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id PAA07259; Tue, 21 Aug 2001 15:10:57 -0400 Message-ID: <3B82B241.409F1B25@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: stefano previdi CC: Chris isis , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Redistribution of routes from ISIS to OSPF References: <4.3.2.7.2.20010821203310.033cdf60@brussels.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 15:10:57 -0400 Content-Transfer-Encoding: 7bit stefano previdi wrote: > At 20:09 21/08/2001, Chris isis wrote: > >I have not been able to identify a vendor that offers redistribution of IP > >routes between Integrated IS-IS and OSPF. > > > >Have I not looked hard enough? > > I believe so....I know at least one vendor doing it > and doubt it's the only one... > Well, I know at least one more.. ;-) In general, redistribution of routes should be a simple matter of inter-protocol policy configuration. Tayfun Gol > > >or is it particularly difficult, or even impossible to redistribute routes > >from OSPF into Integrated IS-IS and the other way around. > > whoever implements routing protocols should be able to > allow redistribution between them. > > s. > > >Thanks, Chris. > > > >_________________________________________________________________ > >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 16:15:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00140 for ; Tue, 21 Aug 2001 16:15:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA76184; Tue, 21 Aug 2001 13:24:32 -0700 (PDT) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA76172 for ; Tue, 21 Aug 2001 13:23:07 -0700 (PDT) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Aug 2001 13:14:04 -0700 Message-ID: From: Neal Castagnoli To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] New 10589 spec, PtoP and ISHs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 13:13:55 -0700 From the original 10589, routers might be able to get around sending ISHs on ptop circuits. The original states routers should transmit an IIH immediately upon circuit startup, and so an implementation need not send an ISH to get the peer IS to start IIH transmission. New 10589, however, removes this wording, and now it appears routers require receipt of an ISH prior to sending the first IIH. Yet if there are old implementations that don't send ISHs, ptop adjacencies won't come up with strict new implementations. Does anyone know whether there are deployed ISIS implementations that don't send ISHs on ptop circuits? Thanks, --Neal _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 16:40:59 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00752 for ; Tue, 21 Aug 2001 16:40:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA76339; Tue, 21 Aug 2001 13:50:32 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA76324 for ; Tue, 21 Aug 2001 13:49:00 -0700 (PDT) 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 NAA14837; Tue, 21 Aug 2001 13:39:56 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 13:39:56 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A63C@avalon.pluris.com> From: Les Ginsberg To: "'Neal Castagnoli'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] New 10589 spec, PtoP and ISHs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 13:39:46 -0700 This issue is a confusing one, some of which is due to the fact that the original wording in ISO 10589:1992 was revised by Technical Corrigendum I (published in 1993), but because many people do not have ready access to the TCs, they rely on the uncorrected original text. In fact, the original intent was made clear in TC1 by adding: "An IS shall cause ISO 9542 to send an ISH PDU whenever a point-to-point circuit is first enabled." and then changing the original text in 8.2.3a (which Neal refers to in stating that an IIH was supposed to be sent when the circuit was first enabled) to read: "a)the IS receives an ISH PDU" So the original intent was to wait for receipt of an ISH before beginning to send IIHs. The latest ISO 10589 draft further clarifies this by specifying that ISH's should continue to be sent periodically until the adjacency reaches the UP state. This is a logical requirement discovered when implementing that was not clearly stated even in the TC1 changes. In an IP only IS-IS implementation, the use of ISH's is an anachronism. Many implementations relax the requirements, at least on reception, so that receiving an ISH is not required. In following the old axiom of being "strict in what you send and generous in what you receive", a robust implementation should send ISHs until the adjacency is up, but allow (at least for IP operation) the adjacency to come up without ever seeing an ISH. This is easily achieved by starting to send IIHs when you first receive an IIH. I can tell you from first hand experience that there are indeed implementations out there which do not send ISHs. Les > -----Original Message----- > From: Neal Castagnoli [mailto:cast@allegronetworks.com] > Sent: Tuesday, August 21, 2001 1:14 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] New 10589 spec, PtoP and ISHs > > > > From the original 10589, routers might be able to get around > sending ISHs on > ptop circuits. The original states routers should transmit an IIH > immediately upon circuit startup, and so an implementation > need not send an > ISH to get the peer IS to start IIH transmission. New 10589, however, > removes this wording, and now it appears routers require > receipt of an ISH > prior to sending the first IIH. > > Yet if there are old implementations that don't send ISHs, > ptop adjacencies > won't come up with strict new implementations. Does anyone > know whether > there are deployed ISIS implementations that don't send ISHs on ptop > circuits? > > Thanks, > > --Neal > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 21 16:50:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01030 for ; Tue, 21 Aug 2001 16:50:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA76438; Tue, 21 Aug 2001 13:59:32 -0700 (PDT) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA76426 for ; Tue, 21 Aug 2001 13:58:14 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id f7LKnB027314; Tue, 21 Aug 2001 13:49:11 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id NAA20537; Tue, 21 Aug 2001 13:49:11 -0700 (PDT) Message-Id: <200108212049.NAA20537@cirrus.juniper.net> From: Dave Katz To: chris_isis@hotmail.com CC: isis-wg@spider.juniper.net In-reply-to: (chris_isis@hotmail.com) Subject: Re: [Isis-wg] Redistribution of routes from ISIS to OSPF Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 13:49:11 -0700 (PDT) Certainly cisco and Juniper both do it; presumably anybody that does route redistribution ought to be able to (nothing special here.) X-Originating-IP: [47.211.0.13] From: "Chris isis" Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Aug 2001 18:09:21.0957 (UTC) FILETIME=[6736E550:01C12A6C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 21 Aug 2001 19:09:21 +0100 I have not been able to identify a vendor that offers redistribution of IP routes between Integrated IS-IS and OSPF. Have I not looked hard enough? or is it particularly difficult, or even impossible to redistribute routes from OSPF into Integrated IS-IS and the other way around. Thanks, Chris. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 22 02:38:43 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26479 for ; Wed, 22 Aug 2001 02:38:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA78781; Tue, 21 Aug 2001 23:47:32 -0700 (PDT) Received: from smtp.huawei.com (61.144.GD.CN [61.144.161.21] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA78768 for ; Tue, 21 Aug 2001 23:46:07 -0700 (PDT) Received: from narayananl ([10.110.8.191]) by smtp.huawei.com (Netscape Messaging Server 4.15) with ESMTP id GIGIA500.H7L; Wed, 22 Aug 2001 14:34:53 +0800 Message-ID: <001201c12ad5$1b6fd8c0$bf086e0a@huawei.com> Reply-To: "Lakshminarayanan Rajamanickam" From: "Lakshminarayanan Rajamanickam" To: Cc: Organization: FS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C12B18.293F2C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Isis-wg] Mesh Groups Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 22 Aug 2001 14:38:51 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C12B18.293F2C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is Mesh Groups concept (Rfc-2973) applied only to NBMA circuits or=20 It can be applied for normal serial P2P links also ? (a large set of p2p = links that results in a full-mesh!) thanks in advance, lakshminarayan r ------=_NextPart_000_000F_01C12B18.293F2C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Is Mesh Groups concept (Rfc-2973) = applied only=20 to NBMA circuits or
It can be applied for normal = serial P2P links=20 also ? (a large set of p2p links that results in a = full-mesh!)
 
thanks in advance,
lakshminarayan = r
------=_NextPart_000_000F_01C12B18.293F2C60-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 22 10:03:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08661 for ; Wed, 22 Aug 2001 10:03:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA80734; Wed, 22 Aug 2001 07:12:36 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA80722 for ; Wed, 22 Aug 2001 07:11:40 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Lakshminarayanan Rajamanickam'" , isis-wg@spider.juniper.net Cc: Jeff Parker MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Mesh Groups Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 22 Aug 2001 10:02:26 -0400 > Is Mesh Groups concept (Rfc-2973) applied only to > NBMA circuits or It can be applied for normal > serial P2P links also ? (a large set of p2p > links that results in a full-mesh!) If you just subscribed to this list, then you missed a discussion of the history behind why IS-IS does not support NBMA. The normal application of mesh groups is a series of circuits that approximates a full mesh. That is, where you are liable to hear about the same LSP from multiple sources. - jeff parker - axiowave networks - I can't remember if I'm the good twin or the evil one. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 22 16:19:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22978 for ; Wed, 22 Aug 2001 16:19:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA82269; Wed, 22 Aug 2001 13:28:32 -0700 (PDT) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA82257 for ; Wed, 22 Aug 2001 13:27:30 -0700 (PDT) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Aug 2001 13:18:13 -0700 Message-ID: From: Neal Castagnoli To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Route selection Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 22 Aug 2001 13:18:10 -0700 We ran a battery of route selection tests against a couple of common implementations. One of the implementations in recent versions follows the RFC 2966 route selection precedence, but in older (deployed) versions treats the metrics as 8 bits wide. The other treats external metric, level 2, and external route (TLV 130) at an absolute lower precedence than L1 internal routes, regardless of the disposition of the up/down bit. Given the inconsistent way these common implementations perform route selection and the attendent routing loops that can form, does it make sense to avoid use of external routes (TLV 130) altogether? Does anyone know of deployed instances in which the use of external routes is required? ----------------- Example: Routing loop caused by inconsistent route selection. C1 is an implementation that absolutely prefers L1 internal routes, C2 chooses based on least cost. 10 10 10 A ---- C1 --- C2 --- B If A advertises a.b.c.d as an external route of cost 10, but B advertises the same route as internal at cost 30, then C2 will use the cheaper route to a.b.c.d through C1 to A at a total cost of 30, but C1 will prefer the more costly route through C2 to B at 50 since it prefers internal routes to external routes regardless of their cost. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 22 22:51:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00593 for ; Wed, 22 Aug 2001 22:51:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA83797; Wed, 22 Aug 2001 20:00:32 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by external.juniper.net (8.9.3/8.9.3) with SMTP id TAA83779 for ; Wed, 22 Aug 2001 19:59:51 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Aug 2001 02:50:38 -0000 X-Apparently-From: Message-ID: <015001c12b7e$ede5f970$da046c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] More than 256 LSPs Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 08:24:26 +0530 Content-Transfer-Encoding: 7bit A single IS can at most issue 256 LSPs and it has to pack everything it wants to advertise into this much. Are there any hacks wherein i may be able to send more information than i what i am capable of using my 256 LSPs. I believe one such mechanism is by faking a LAN .. but i am not sure as to how it may work. Can anybody please explain ? Thanks and Regards, Manav Bhatia "C is not a big language, and is not well served by a big book." -- K&R2 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 06:34:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21551 for ; Thu, 23 Aug 2001 06:34:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA85809; Thu, 23 Aug 2001 03:43:32 -0700 (PDT) Received: from web11205.mail.yahoo.com (web11205.mail.yahoo.com [216.136.131.187]) by external.juniper.net (8.9.3/8.9.3) with SMTP id DAA85797 for ; Thu, 23 Aug 2001 03:42:09 -0700 (PDT) Message-ID: <20010823103255.8412.qmail@web11205.mail.yahoo.com> Received: from [202.9.170.10] by web11205.mail.yahoo.com; Thu, 23 Aug 2001 03:32:55 PDT From: Aravind Ravikumar Subject: Re: [Isis-wg] Protocol parameter. To: Sachidananda K , isis-wg@spider.juniper.net In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1920019959-998562775=:8404" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 03:32:55 -0700 (PDT) --0-1920019959-998562775=:8404 Content-Type: text/plain; charset=us-ascii Hi Sachidananda, It definitely corresponds to the minimum time interval that needs to be allowed between consecutive LSPs on a LAN interface. But what other significance this 32 millisecond interval has got depends on which of of the following two views hold good. I am not sure about which one is correct and Iam also eager to know Approach A There are certain conditions that make an LSP qualified to be sent. This applies to individual LSPs on per circuit basis and is mainly related to the timing constraint minimumLSPTransmissionInterval. For a large database it is highly probable that at any given time there are LSPs in the database qualified to be send. In ideal case we would never want to hold back an LSP which is qualified to be sent any further. The speed with which we discover a ready LSP is limited by the speed with which we scan the database. Ideally we would like to continuously scan the database and discover ready LSPs as soon as possible. There is a constraint that limits the speed with which you can send the LSPs in the same LAN, even if you have found that it is ready to be transmitted. The minimumLSPbroadcast interval is the minimum interval that you should have between two LSPs sent on a particular LAN. This means that there is no use in finding out ready LSPs more frequent than this, since! you cannot send it more frequently. So an efficient implementation should scan the LSDB once in 32 milliseconds, even if its highly demanding Approach B As said in section 7.3.15.5 of ISO 10589, If we consider an individual LSP it should be kept with in the router's memory without propagating for atleast minimumLSPTransmissionInterval and no more than twice this value (between 5and 10 seconds). This can be achieved if we scan the database once in each 5 seconds. For a point to point link transmit all the selected LSPs. But in case of broadcast network, take into consideration the 32 millisecond interval between LSP transmission. Even if the router finds out that there are a number of LSPs, keep them in queue and send them separated by 32 milliseconds. The main question here is whether the interpretation that a router can keep an individual LSP between 5 and 10 second is correct or not .If we take an average of 7.5 seconds, a topology change will take more than 75 seconds to travel 10 links. This also puts restriction on scalability.But the advantage is that you need need to scan the whole database once in 5 seconds only, rathe! r than 32ms Aravind Sachidananda K wrote: Hello, I have some questions related to the parameter minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of ISO 10589. Does this parameter corresponds to the frequency at which Link State Database is scanned for transmitting the LSP? That is every minimumBroadcastLSPTransmissionInterval duration the Link state database MUST be scanned for searching the LSP to be sent. Or it corresponds to the minimum time interval that needs to be allowed between consecutive packets (be it of any type) on a LAN interface? that is suppose on a particular interface (say A) if a LSP is sent, then for the next minimumBroadcastLSPTransmissionInterval duration no other packets of any type is to be sent on this interface. Apart from this, if the point 1 is not true, then is there any parameter that dictates the frequency at which the link state database is to be scanned for searching the LSP to be sent? Thanking in advance for all early responses that I receive. Sachi _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg --------------------------------- Do You Yahoo!? Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-1920019959-998562775=:8404 Content-Type: text/html; charset=us-ascii

 

Hi Sachidananda,

It definitely corresponds to the minimum time interval that needs to be allowed between consecutive LSPs on a LAN interface. But what other significance this 32 millisecond interval has got depends on which of of the following two views hold good. I am not sure about which one is correct and Iam also eager to know

Approach A

          There are certain conditions that make an LSP qualified to be sent. This applies to individual LSPs on per circuit basis and is mainly related to the timing constraint minimumLSPTransmissionInterval. For a large database it is highly probable that at any given time there are LSPs in the database qualified to be send. In ideal case we would never want to hold back an LSP which is qualified to be sent any further. The speed with which we discover a ready LSP is limited by the speed with which we scan the database. Ideally we would like to continuously scan the database and discover ready LSPs as soon as possible. There is a constraint that limits the speed with which you can send the LSPs in the same LAN, even if you have found that it is ready to be transmitted. The minimumLSPbroadcast interval is the minimum interval that you should have between two LSPs sent on a particular LAN. This means that there is no use in findi! ng out ready LSPs more frequent than this, since you cannot send it more frequently. So an efficient implementation should scan the LSDB once in 32 milliseconds, even if its highly demanding

Approach B

As said in section 7.3.15.5 of ISO 10589, If we consider an individual LSP it should be kept with in the router's memory without propagating for atleast minimumLSPTransmissionInterval and no more than twice this value (between 5and 10 seconds). This can be achieved if we scan the database once in each 5 seconds. For a point to point link transmit all the selected LSPs. But in case of broadcast network, take into consideration the 32 millisecond interval between LSP transmission. Even if the router finds out that there are a number of LSPs, keep them in queue and send them separated by 32 milliseconds. The main question here is whether the interpretation that a router can keep an individual LSP between 5 and 10 second is correct or not .If we take an average of 7.5 seconds, a topology change will take more than 75 seconds to travel 10 links. This also puts restriction on scalability.But the advantage is that you need need to scan the whole database once in 5 seconds only, ra! ther than 32ms

Aravind

 

  Sachidananda K <sachidananda_k@hotmail.com> wrote:

Hello,

I have some questions related to the parameter
minimumBroadcastLSPTransmissionInterval as described in section 7.3.15.6 of
ISO 10589.

Does this parameter corresponds to the frequency at which Link State
Database is scanned for transmitting the LSP? That is every
minimumBroadcastLSPTransmissionInterval duration the Link state database
MUST be scanned for searching the LSP to be sent.

Or it corresponds to the minimum time interval that needs to be allowed
between consecutive packets (be it of any type) on a LAN interface? that is
suppose on a particular interface (say A) if a LSP is sent, then for the
next minimumBroadcastLSPTransmissionInterval duration no other packets of
any type is to be sent on this interface.

Apart from this, if the point 1 is not true, then is there any parameter
that dictates the frequency at w! hich the link state database is to be
scanned for searching the LSP to be sent?

Thanking in advance for all early responses that I receive.
Sachi

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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


Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-1920019959-998562775=:8404-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 07:39:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22198 for ; Thu, 23 Aug 2001 07:39:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA86122; Thu, 23 Aug 2001 04:48:32 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA86110 for ; Thu, 23 Aug 2001 04:47:42 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [Isis-wg] More than 256 LSPs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: [Isis-wg] More than 256 LSPs Thread-Index: AcErfwcMZtdX7ZoWQtaeSLD5FW05fAASMoEA From: "Amir Hermelin" To: "Manav Bhatia" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id EAA86111 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 14:38:25 +0300 Content-Transfer-Encoding: 8bit Manav, check out this draft http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt It attempts to solve the problem and remove the 256 limit. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Thursday, August 23, 2001 5:54 AM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] More than 256 LSPs > > > A single IS can at most issue 256 LSPs and it has to pack > everything it > wants to advertise into this much. Are there any hacks > wherein i may be able > to send more information than i what i am capable of using my > 256 LSPs. I > believe one such mechanism is by faking a LAN .. but i am not > sure as to how > it may work. > Can anybody please explain ? > > Thanks and Regards, > Manav Bhatia > > "C is not a big language, and is not well served by a big > book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 15:40:09 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00045 for ; Thu, 23 Aug 2001 15:40:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA88055; Thu, 23 Aug 2001 12:48:33 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA88043 for ; Thu, 23 Aug 2001 12:47:02 -0700 (PDT) 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 f7NJbjs39113 for ; Thu, 23 Aug 2001 12:37:45 -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.2966); Thu, 23 Aug 2001 12:35:51 -0700 Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 5A3DBCAB70 for ; Thu, 23 Aug 2001 12:36:11 -0700 (PDT) Message-ID: <3B85569D.40E1F15D@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2001 19:35:51.0279 (UTC) FILETIME=[D11E17F0:01C12C0A] Subject: [Isis-wg] Meeting minutes ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 12:16:45 -0700 Content-Transfer-Encoding: 7bit For London from my sketchy notes since I didn't get the notes that Alex was taking yet . Administrativa . isis-transient has been updated and called again, should go to RFC now . isis-3way passed last call, will need addition of TLV codepoint consideration for RFC . isis-snp-checksum same, TLV assignment conflict has been resolved . isis-ipv6 same . large ether frames in editing, under discussion . Presentations . m-isis: Mike had some questions on flooding optimizations mentioned, the discussion that came out of it basically lead to agreement that it's mostly a dangerous idea not worth pursuiting and due to the lack of specifics in the draft lacked in quality. IPv6 has been mentioned and authors answered that the problem is being ignored at the moment due to the lack of requirements from the ISP side. . hermelin-ext-lsp-frags: Mike & Stefano thought that it would make more sense to have a method to issue LSPs > 255 under different system ID and tie those together using some proxy TLV with the original node, concern with presented proposal was that without SPF changes it only presents a restricted functionality (leaf-node). Motion to make it workgroup document. Agreement was that within 8 weeks Stefano & Mike submit an alternative draft and things will be discussed further or merged or otherwise hermelin draft becomes a WG item. . ietf-isis-transient: Danny did not show up to present . shand-isis-restart: After presentation a discussion started WHY it should be done at all and enough reasons have been found to make it a wg item (backups, software upgrades) . ietf-ospf-p2p: Dino brought up some simplifying ideas on the ISIS side that have been considered but would make layer violations worse (taking MAC directly from hellos). Request to make it working group document has been delayed and should be posted by the authors to the mailing list for a wider discussion. . auth-anti-replay: Request has been made to make it a workgroup document. No comment from the room due to the early morning hour and jetlag probably. Tony came up to the mike and brought up several reasons why it does not make sense to accept the draft as it is. Either ISPs with burning desire for that partial solutions should be vocal or we should spend serious time on a clean security solution for ISIS that would encompass proper nonce negotiation for replay protection, source authentication and other best-known-practices. Up to Alex to see whether he wants to pursuit either path. . tlv-codepoints: All drafts taking new TLV values should please refer to that draft -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 16:07:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00463 for ; Thu, 23 Aug 2001 16:07:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA88192; Thu, 23 Aug 2001 13:16:32 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA88179 for ; Thu, 23 Aug 2001 13:15:45 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7NK6Ss39542 for ; Thu, 23 Aug 2001 13:06:28 -0700 (PDT) X-JNPR-Received-From: outside Received: from dino-pc.procket.com ([209.140.237.1]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 13:05:27 -0700 Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id NAA06495; Thu, 23 Aug 2001 13:05:46 -0700 Message-Id: <200108232005.NAA06495@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: prz@redback.com CC: isis-wg@juniper.net In-reply-to: <3B85569D.40E1F15D@redback.com> (message from Tony Przygienda on Thu, 23 Aug 2001 12:16:45 -0700) Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> X-OriginalArrivalTime: 23 Aug 2001 20:05:27.0703 (UTC) FILETIME=[F3F2E270:01C12C0E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 13:05:46 -0700 >> . ietf-ospf-p2p: Dino brought up some simplifying ideas on the >> ISIS side that have >> been considered but would make layer violations worse (taking >> MAC directly from This layer violation is already in IS-IS when processing LAN IIH's. Dino _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 17:13:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01832 for ; Thu, 23 Aug 2001 17:13:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88577; Thu, 23 Aug 2001 14:22:32 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88565 for ; Thu, 23 Aug 2001 14:21:42 -0700 (PDT) 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 f7NLCPs40985 for ; Thu, 23 Aug 2001 14:12:25 -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.2966); Thu, 23 Aug 2001 14:11:49 -0700 Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 2358ECAB6B; Thu, 23 Aug 2001 14:12:12 -0700 (PDT) Message-ID: <3B856D1D.B159A2E3@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <200108232005.NAA06495@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2001 21:11:49.0472 (UTC) FILETIME=[39449E00:01C12C18] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 13:52:46 -0700 Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > >> . ietf-ospf-p2p: Dino brought up some simplifying ideas on the > >> ISIS side that have > >> been considered but would make layer violations worse (taking > >> MAC directly from > > This layer violation is already in IS-IS when processing LAN IIH's. > layer violation meaning that ISIS would probably take to ARP tables to teach them the MAC address of the neighbor if such a scheme is employed (and proxy ARP's not being run) ... That is more than the usual MAC-on-hellos layer violation ;-) -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 17:18:41 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01955 for ; Thu, 23 Aug 2001 17:18:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88639; Thu, 23 Aug 2001 14:28:33 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88622 for ; Thu, 23 Aug 2001 14:27:17 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7NLI0s41116 for ; Thu, 23 Aug 2001 14:18:00 -0700 (PDT) X-JNPR-Received-From: outside Received: from challah.msrl.com ([198.176.193.209]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 14:13:50 -0700 Received: (qmail 756 invoked from network); 23 Aug 2001 21:14:13 -0000 Received: from localhost (HELO challah.msrl.com) (127.0.0.1) by localhost with SMTP; 23 Aug 2001 21:14:13 -0000 To: Tony Przygienda , isis-wg@juniper.net Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> From: Vijay Gill Organization: vgill global logistics Original-Sender: vgill@vijaygill.com In-Reply-To: Tony Przygienda's message of "Thu, 23 Aug 2001 12:16:45 -0700" Message-ID: <7msneieaxm.fsf@challah.msrl.com> Lines: 40 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 23 Aug 2001 21:13:50.0875 (UTC) FILETIME=[81A13EB0:01C12C18] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 23 Aug 2001 21:14:13 +0000 Tony Przygienda writes: > For London from my sketchy notes since I didn't get the notes that Alex > was taking yet > . shand-isis-restart: After presentation a discussion started WHY > > it should be done at> all and enough reasons have been found to > make it a wg item (backups, software upgrades) I would strongly suggest checking the archives of the OSPF wg mailing list (http://discuss.microsoft.com/archives/ospf.html) as there has been significant discussion on a somewhat similar topic. > . auth-anti-replay: Request has been made to make it a workgroup > document. No comment from the room due to the early morning hour > and jetlag probably. Tony came up to the mike and brought up > several reasons why it does not make sense to accept the draft > as it is. Either ISPs with burning desire for that partial > solutions should be vocal or we should spend serious time on a > clean security solution for ISIS that would encompass proper > nonce negotiation for replay protection, source authentication > and other best-known-practices. Up to Alex to see whether he > wants to pursuit either path. In general, the entire aspect of control plane security in IP networks has been of secondary importance (maybe because it is hard to get the control plane working to our satisfaction. The codebase probably comprises as good an attack on our infrastructure as anything the black hats could come up with). That being said, it is probably of use to pursue _a_ solution, and a solution that gets us most of the way there and is codeable and deployable is of more use than the all singing, all dancing undeployable solution which introduces significant amounts of codebase upheaval. /vijay _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 17:19:17 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01982 for ; Thu, 23 Aug 2001 17:19:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88658; Thu, 23 Aug 2001 14:29:09 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88627 for ; Thu, 23 Aug 2001 14:27:59 -0700 (PDT) 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 f7NLIgs41182 for ; Thu, 23 Aug 2001 14:18:42 -0700 (PDT) X-JNPR-Received-From: outside Received: from dino-pc.procket.com ([209.140.237.1]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 14:16:23 -0700 Received: (from dino@localhost) by dino-pc.procket.com (8.9.3/8.9.3) id OAA07106; Thu, 23 Aug 2001 14:16:45 -0700 Message-Id: <200108232116.OAA07106@dino-pc.procket.com> X-Authentication-Warning: dino-pc.procket.com: dino set sender to dino@dino-pc.procket.com using -f From: Dino Farinacci To: prz@redback.com CC: isis-wg@juniper.net In-reply-to: <3B856D1D.B159A2E3@redback.com> (message from Tony Przygienda on Thu, 23 Aug 2001 13:52:46 -0700) Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <200108232005.NAA06495@dino-pc.procket.com> <3B856D1D.B159A2E3@redback.com> X-OriginalArrivalTime: 23 Aug 2001 21:16:23.0380 (UTC) FILETIME=[DC87A940:01C12C18] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 14:16:45 -0700 >> layer violation meaning that ISIS would probably take to ARP tables to >> teach them >> the MAC address of the neighbor if such a scheme is employed (and proxy >> ARP's not being >> run) ... That is more than the usual MAC-on-hellos layer violation ;-) IS-IS deals with layer-2 addresses. If the implementation chooses to add ARP entries, it is a local matter. Just like Russ said. A traditional "layer violation" means a layer-n protocol looks at a layer-(n-1) protocol's header. Dino _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 17:25:42 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02075 for ; Thu, 23 Aug 2001 17:25:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88749; Thu, 23 Aug 2001 14:35:33 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA88734 for ; Thu, 23 Aug 2001 14:34:31 -0700 (PDT) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7NLPDi77397 for ; Thu, 23 Aug 2001 14:25:13 -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.2966); Thu, 23 Aug 2001 14:20:18 -0700 Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id E6BA6CAB7C; Thu, 23 Aug 2001 14:20:40 -0700 (PDT) Message-ID: <3B856F1A.87B58E10@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Dino Farinacci Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <200108232005.NAA06495@dino-pc.procket.com> <3B856D1D.B159A2E3@redback.com> <200108232116.OAA07106@dino-pc.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2001 21:20:19.0006 (UTC) FILETIME=[68F955E0:01C12C19] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 14:01:15 -0700 Content-Transfer-Encoding: 7bit Dino Farinacci wrote: > >> layer violation meaning that ISIS would probably take to ARP tables to > >> teach them > >> the MAC address of the neighbor if such a scheme is employed (and proxy > >> ARP's not being > >> run) ... That is more than the usual MAC-on-hellos layer violation ;-) > > IS-IS deals with layer-2 addresses. If the implementation chooses to add > ARP entries, it is a local matter. Just like Russ said. > > A traditional "layer violation" means a layer-n protocol looks at a > layer-(n-1) protocol's header. ok, let's call it 'protocol-crosstalk' ;-) then ... -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 19:07:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03655 for ; Thu, 23 Aug 2001 19:07:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA89307; Thu, 23 Aug 2001 16:17:33 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA89294 for ; Thu, 23 Aug 2001 16:16:18 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7NN70s43116 for ; Thu, 23 Aug 2001 16:07:00 -0700 (PDT) X-JNPR-Received-From: outside Received: from gnat.inet.org ([63.108.254.91]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 16:05:09 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id F3F058266F; Thu, 23 Aug 2001 19:05:29 -0400 (EDT) Message-Id: <5.1.0.14.2.20010823185647.009f96b0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Vijay Gill From: RJ Atkinson Subject: Re: [Isis-wg] Meeting minutes ... Cc: isis-wg@juniper.net In-Reply-To: <7msneieaxm.fsf@challah.msrl.com> References: <3B85569D.40E1F15D@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 23 Aug 2001 23:05:09.0609 (UTC) FILETIME=[0E772D90:01C12C28] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 18:59:58 -0400 At 17:14 23/08/01, Vijay Gill wrote: >> . auth-anti-replay: Request has been made to make it a workgroup >> document. No comment from the room due to the early morning hour >> and jetlag probably. Tony came up to the mike and brought up >> several reasons why it does not make sense to accept the draft >> as it is. Either ISPs with burning desire for that partial >> solutions should be vocal or we should spend serious time on a >> clean security solution for ISIS that would encompass proper >> nonce negotiation for replay protection, source authentication >> and other best-known-practices. Up to Alex to see whether he >> wants to pursuit either path. > >In general, the entire aspect of control plane security in IP networks >has been of secondary importance (maybe because it is hard to get the >control plane working to our satisfaction. The codebase probably >comprises as good an attack on our infrastructure as anything the >black hats could come up with). That being said, it is probably of >use to pursue _a_ solution, and a solution that gets us most of the >way there and is codeable and deployable is of more use than the all >singing, all dancing undeployable solution which introduces >significant amounts of codebase upheaval. Vijay, My apologies for my being dim-witted. I'm having trouble interpreting your remarks above: Are you saying you'd be happy with just documenting the already widely deployed (but not yet RFC) IS-IS HMAC-MD5 approach in the current tli draft as an RFC ? XOR Are you saying that you want to forget the installed base, open the hood, tinker, and do something else ? Thanks, Ran rja@inet.org _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 19:49:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04077 for ; Thu, 23 Aug 2001 19:49:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA89526; Thu, 23 Aug 2001 16:59:32 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA89514 for ; Thu, 23 Aug 2001 16:58:24 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f7NNn5s44001 for ; Thu, 23 Aug 2001 16:49:05 -0700 (PDT) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 16:44:31 -0700 Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 4FBD4F2C54; Thu, 23 Aug 2001 16:44:53 -0700 (PDT) Message-ID: <3B8590E6.17BE6D3A@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gill Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2001 23:44:31.0546 (UTC) FILETIME=[8E4A29A0:01C12C2D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 16:25:26 -0700 Content-Transfer-Encoding: 7bit Vijay Gill wrote: > Tony Przygienda writes: > > > For London from my sketchy notes since I didn't get the notes that Alex > > was taking yet > > > . shand-isis-restart: After presentation a discussion started WHY > > > it should be done at> all and enough reasons have been found to > > make it a wg item (backups, software upgrades) > > I would strongly suggest checking the archives of the OSPF wg mailing > list (http://discuss.microsoft.com/archives/ospf.html) as there has > been significant discussion on a somewhat similar topic. aware of that, was not hurting repeating the arguments since some of the crowd does not overlap between ISIS and OSPF ;-) > > . auth-anti-replay: Request has been made to make it a workgroup > > document. No comment from the room due to the early morning hour > > and jetlag probably. Tony came up to the mike and brought up > > several reasons why it does not make sense to accept the draft > > as it is. Either ISPs with burning desire for that partial > > solutions should be vocal or we should spend serious time on a > > clean security solution for ISIS that would encompass proper > > nonce negotiation for replay protection, source authentication > > and other best-known-practices. Up to Alex to see whether he > > wants to pursuit either path. > > In general, the entire aspect of control plane security in IP networks > has been of secondary importance (maybe because it is hard to get the > control plane working to our satisfaction. The codebase probably > comprises as good an attack on our infrastructure as anything the > black hats could come up with). That being said, it is probably of > use to pursue _a_ solution, and a solution that gets us most of the > way there and is codeable and deployable is of more use than the all > singing, all dancing undeployable solution which introduces > significant amounts of codebase upheaval. Vijay, nice tirade but pls read Alex's draft and tell me whehter you desperately need his-flavor-of-partial-replay-protection today. If you do, we make the draft working group item and we'll make sure that you deployed it after the vendors rolled it. If you (as placeholder for any major ISP) don't need it desperately today, it is not worth doing and we should concentrate on a proper framework (if we want to do it at all) that won't be openly picked apart at the mike by some security wizard 6 months from now. I saw couple of chairs standing with their pants down in such a situation and it is mucho embarassing. The only excuses are 'it was desperately needed to be deployed then so little hacky was fine' (case HMAC today) or 'we did thorough work and took into account all the then-known security paranoia'. Anything else does not stand the test of time and based on that observations I was trying to steer the work ... -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 23 22:02:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06235 for ; Thu, 23 Aug 2001 22:02:06 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA90088; Thu, 23 Aug 2001 19:11:33 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA90076 for ; Thu, 23 Aug 2001 19:10:22 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7O212i81207 for ; Thu, 23 Aug 2001 19:01:03 -0700 (PDT) X-JNPR-Received-From: outside Received: from challah.msrl.com ([198.176.193.209]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 18:58:15 -0700 Received: (qmail 7433 invoked from network); 24 Aug 2001 01:58:38 -0000 Received: from localhost (HELO challah.msrl.com) (127.0.0.1) by localhost with SMTP; 24 Aug 2001 01:58:38 -0000 To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> From: Vijay Gill Organization: vgill global logistics Original-Sender: vgill@vijaygill.com Message-ID: <7md75mxlpt.fsf@challah.msrl.com> Lines: 50 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 24 Aug 2001 01:58:15.0859 (UTC) FILETIME=[3D272830:01C12C40] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 24 Aug 2001 01:58:38 +0000 Tony Przygienda writes: > Vijay Gill wrote: > aware of that, was not hurting repeating the arguments since some of > the crowd does not overlap between ISIS and OSPF ;-) Just thought I'd err on the side of caution. The OSPF discussions were not pretty at all. > > black hats could come up with). That being said, it is probably of > > use to pursue _a_ solution, and a solution that gets us most of the > > way there and is codeable and deployable is of more use than the all > > singing, all dancing undeployable solution which introduces > > significant amounts of codebase upheaval. > Vijay, nice tirade but pls read Alex's draft and tell me whehter you > desperately need his-flavor-of-partial-replay-protection today. Thanks to Ran (rja@inet.org) for clearing up some errors. The HMAC solution as proposed by tli appears to be sufficient for now. > vendors rolled it. If you (as placeholder for any major ISP) don't > need it desperately today, it is not worth doing and we should > concentrate on a proper framework (if we want to do it at all) that > won't be openly picked apart at the mike by some security wizard 6 > months from now. I saw couple of chairs standing with their pants A secure solution is needed, I am not sure if the costs of imposing a very complete, unbreakable solution are worth the return given _current_ and past performance [ insert past performance is not a guarantee of future result boilerplate here ] > excuses are 'it was desperately needed to be deployed then so little > hacky was fine' (case HMAC today) or 'we did thorough work and took > into account all the then-known security paranoia'. Anything else > does not stand the test of time and based on that observations I was > trying to steer the work ... I'm basing this on a mandate after an incident some time ago. Senior mangement said 'you will run authentication on all routing protocols or you will find another job' Others mileage may and probably should, vary. /vijay _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 02:58:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26558 for ; Fri, 24 Aug 2001 02:58:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA91330; Fri, 24 Aug 2001 00:06:33 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA91318 for ; Fri, 24 Aug 2001 00:05:52 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7O6uVi84143 for ; Thu, 23 Aug 2001 23:56:31 -0700 (PDT) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 23:54:41 -0700 Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by prattle.redback.com (Postfix) with ESMTP id 2D7B21DCC65; Thu, 23 Aug 2001 23:55:05 -0700 (PDT) Message-ID: <3B85F5B8.C4BBFE02@redback.com> From: Tony Przygienda X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gill Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] Meeting minutes ... References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2001 06:54:42.0078 (UTC) FILETIME=[A690CBE0:01C12C69] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 23 Aug 2001 23:35:37 -0700 Content-Transfer-Encoding: 7bit Vijay Gill wrote: > Tony Przygienda writes: > > > Vijay Gill wrote: > > > aware of that, was not hurting repeating the arguments since some of > > the crowd does not overlap between ISIS and OSPF ;-) > > Just thought I'd err on the side of caution. The OSPF discussions > were not pretty at all. ok ... > > > black hats could come up with). That being said, it is probably of > > > use to pursue _a_ solution, and a solution that gets us most of the > > > way there and is codeable and deployable is of more use than the all > > > singing, all dancing undeployable solution which introduces > > > significant amounts of codebase upheaval. > > > Vijay, nice tirade but pls read Alex's draft and tell me whehter you > > desperately need his-flavor-of-partial-replay-protection today. > > Thanks to Ran (rja@inet.org) for clearing up some errors. The HMAC > solution as proposed by tli appears to be sufficient for now. we're in sync then ... > > vendors rolled it. If you (as placeholder for any major ISP) don't > > need it desperately today, it is not worth doing and we should > > concentrate on a proper framework (if we want to do it at all) that > > won't be openly picked apart at the mike by some security wizard 6 > > months from now. I saw couple of chairs standing with their pants > > A secure solution is needed, I am not sure if the costs of imposing > a very complete, unbreakable solution are worth the return given > _current_ and past performance [ insert past performance > is not a guarantee of future result boilerplate here ] neither am I, I was only saying if somebody has cycles to put into that, he rather do a good job rather than come up with a hacky solution for a problem that the ISPs don't have and not solving a problem they may or will have properly either ... > > excuses are 'it was desperately needed to be deployed then so little > > hacky was fine' (case HMAC today) or 'we did thorough work and took > > into account all the then-known security paranoia'. Anything else > > does not stand the test of time and based on that observations I was > > trying to steer the work ... > > I'm basing this on a mandate after an incident some time ago. Senior > mangement said 'you will run authentication on all routing protocols > or you will find another job' of course we know that most of senior managers that cluefull and determined tend to find or being found new jobs way before us techies do ;-) Points taken -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 05:31:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27603 for ; Fri, 24 Aug 2001 05:31:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA92136; Fri, 24 Aug 2001 02:40:33 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA92121 for ; Fri, 24 Aug 2001 02:39:09 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Aug 2001 09:29:46 -0000 X-Apparently-From: Message-ID: <00e601c12c7f$d93432b0$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Amir Hermelin" , References: Subject: Re: [Isis-wg] More than 256 LSPs Organization: Samsung India Operations MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 15:03:32 +0530 Content-Transfer-Encoding: 7bit Hi Amir, I went through this draft and is quite interesting but there is another approach which you can take to increase the number of LSPs beyond 256. I dont remember the details but it goes something like this .. We act as two routers that are adjacent to one another and as long as we act like what we are advertising then no one can tell. This way we can thus issue 512 LSPs . Has anybody ever heard of such a concept ?? Thanks and Regards, Manav Bhatia ----- Original Message ----- From: "Amir Hermelin" To: "Manav Bhatia" ; Sent: Thursday, August 23, 2001 5:08 PM Subject: RE: [Isis-wg] More than 256 LSPs Manav, check out this draft http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt It attempts to solve the problem and remove the 256 limit. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Thursday, August 23, 2001 5:54 AM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] More than 256 LSPs > > > A single IS can at most issue 256 LSPs and it has to pack > everything it > wants to advertise into this much. Are there any hacks > wherein i may be able > to send more information than i what i am capable of using my > 256 LSPs. I > believe one such mechanism is by faking a LAN .. but i am not > sure as to how > it may work. > Can anybody please explain ? > > Thanks and Regards, > Manav Bhatia > > "C is not a big language, and is not well served by a big > book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 09:43:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04917 for ; Fri, 24 Aug 2001 09:43:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA93179; Fri, 24 Aug 2001 06:52:33 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA93167 for ; Fri, 24 Aug 2001 06:51:24 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Manav Bhatia'" , Amir Hermelin , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] More than 256 LSPs 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@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 09:41:49 -0400 > there is another approach which you can take ... > We act as two routers that are adjacent > > Manav Bhatia Manav - This was discussed at the last meeting, as captured in TonyP's meeting notes. I can send you a copy of the notes off-line if you missed them. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 09:48:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04991 for ; Fri, 24 Aug 2001 09:48:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA93223; Fri, 24 Aug 2001 06:57:33 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA93211 for ; Fri, 24 Aug 2001 06:56:24 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7ODl1i88183 for ; Fri, 24 Aug 2001 06:47:01 -0700 (PDT) X-JNPR-Received-From: outside Received: from gnat.inet.org ([63.108.254.91]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 06:41:26 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 891BC8266F; Fri, 24 Aug 2001 09:41:47 -0400 (EDT) Message-Id: <5.1.0.14.2.20010824093213.00a1ed30@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Tony Przygienda From: RJ Atkinson Cc: isis-wg@juniper.net In-Reply-To: <3B85F5B8.C4BBFE02@redback.com> References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 24 Aug 2001 13:41:26.0453 (UTC) FILETIME=[78B4E650:01C12CA2] Subject: [Isis-wg] On authenticating IS-IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 09:36:14 -0400 At 02:35 24/08/01, Tony Przygienda wrote: >neither am I, I was only saying if somebody has cycles to put into that, >he rather do a good job rather than come up with a hacky solution for >a problem that the ISPs don't have and not solving a problem they may >or will have properly either ... Tony, My own sense is that the next useful increase in attacker work function (beyond the tli HMAC draft) is probably to go to full Digital Signatures (along the lines of RFC-2154). I am only aware of one implementation of RFC-2154 (done by its authors) and zero deployments of RFC-2154. I interpret that state of implementation and deployment as indicating that: "most of the community doesn't think the current threats justify that level of security complexity and adverse performance impact today" Regards, Ran rja@inet.org _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 15:09:30 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12783 for ; Fri, 24 Aug 2001 15:09:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA94569; Fri, 24 Aug 2001 12:18:33 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA94557 for ; Fri, 24 Aug 2001 12:17:51 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 96A2D1DCC78; Fri, 24 Aug 2001 12:08:26 -0700 (PDT) To: "Manav Bhatia" Cc: "Amir Hermelin" , isis-wg@spider.juniper.net Subject: Re: [Isis-wg] More than 256 LSPs In-reply-to: Mail from "Manav Bhatia" dated Fri, 24 Aug 2001 15:03:32 +0530 <00e601c12c7f$d93432b0$b4036c6b@Manav> From: Naiming Shen Message-Id: <20010824190826.96A2D1DCC78@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 12:08:26 -0700 ]Hi Amir, ]I went through this draft and is quite interesting but there is another ]approach which you can take to increase the number of LSPs beyond 256. I ]dont remember the details but it goes something like this .. We act as two ]routers that are adjacent to one another and as long as we act like what we ]are advertising then no one can tell. This way we can thus issue 512 LSPs . ]Has anybody ever heard of such a concept ?? how is such a concept different from the draft you just went through? ] ]Thanks and Regards, ]Manav Bhatia ] ]----- Original Message ----- ]From: "Amir Hermelin" ]To: "Manav Bhatia" ; ]Sent: Thursday, August 23, 2001 5:08 PM ]Subject: RE: [Isis-wg] More than 256 LSPs ] ] ]Manav, ] ]check out this draft ]http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt ] ]It attempts to solve the problem and remove the 256 limit. ] ]-- ]Amir Hermelin ]Charlotte's Web Networks Inc. ] ] ]> -----Original Message----- ]> From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] ]> Sent: Thursday, August 23, 2001 5:54 AM ]> To: isis-wg@spider.juniper.net ]> Subject: [Isis-wg] More than 256 LSPs ]> ]> ]> A single IS can at most issue 256 LSPs and it has to pack ]> everything it ]> wants to advertise into this much. Are there any hacks ]> wherein i may be able ]> to send more information than i what i am capable of using my ]> 256 LSPs. I ]> believe one such mechanism is by faking a LAN .. but i am not ]> sure as to how ]> it may work. ]> Can anybody please explain ? ]> ]> Thanks and Regards, ]> Manav Bhatia ]> ]> "C is not a big language, and is not well served by a big ]> book." -- K&R2 ]> ]> ]> ]> _________________________________________________________ ]> Do You Yahoo!? ]> Get your free @yahoo.com address at http://mail.yahoo.com ]> ]> _______________________________________________ ]> Isis-wg mailing list - Isis-wg@external.juniper.net ]> http://external.juniper.net/mailman/listinfo/isis-wg ]> ] ] ]_________________________________________________________ ]Do You Yahoo!? ]Get your free @yahoo.com address at http://mail.yahoo.com ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 15:26:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13282 for ; Fri, 24 Aug 2001 15:25:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA94679; Fri, 24 Aug 2001 12:34:34 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA94664 for ; Fri, 24 Aug 2001 12:33:00 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7OJNai93717 for ; Fri, 24 Aug 2001 12:23:36 -0700 (PDT) X-JNPR-Received-From: outside Received: from presque.djinesys.com ([198.108.88.2]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 12:11:54 -0700 Received: from nexthop.com (namato.nexthop.com [64.211.218.17]) by presque.djinesys.com (8.11.1/8.11.1) with ESMTP id f7OJCGK42126; Fri, 24 Aug 2001 15:12:16 -0400 (EDT) (envelope-from naamato@nexthop.com) Received: (from naamato@localhost) by nexthop.com (8.11.0/8.11.0) id f7OJCFm21772; Fri, 24 Aug 2001 15:12:15 -0400 (EDT) From: Nick Amato To: isis-wg@juniper.net Cc: Nick Amato Message-ID: <20010824151215.C323@wooj.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OriginalArrivalTime: 24 Aug 2001 19:11:54.0765 (UTC) FILETIME=[A34D33D0:01C12CD0] Subject: [Isis-wg] unauthenticated LSP purges Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 15:12:15 -0400 I have searched the archive and found nothing that relates to this, in any case, sorry if this is an old topic. It seems that ISO 10589 contradicts itself in the area of LSP purges. 7.3.16.4 indicates that when the Remaining Lifetime of an LSP in memory becomes zero: a) set all SRMflags for that LSP, and b) retain only the LSP header Yet in 7.3.15.1, 'Action on receipt of an LSP', the authentication checks in (5) and (6) are performed _before_ the zero lifetime check in (b). A popular vendor seems to check and originate simple authentication on zero lifetime LSPs. draft-ietf-isis-hmac-03.txt indicates that an IS implementing MD5 should never accept unauthenticated purges. This seems like the correct thing to do if either simple or MD5 is in use. Nick Amato naamato@nexthop.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 16:27:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14714 for ; Fri, 24 Aug 2001 16:27:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA95061; Fri, 24 Aug 2001 13:36:34 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA95049 for ; Fri, 24 Aug 2001 13:35:40 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7OKQFi94761 for ; Fri, 24 Aug 2001 13:26:15 -0700 (PDT) X-JNPR-Received-From: outside Received: from pltn13.pbi.net ([64.164.98.8]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 13:21:14 -0700 Received: from redback.com ([63.200.49.104]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GIL00BQ89W2DY@mta7.pltn13.pbi.net> for isis-wg@juniper.net; Fri, 24 Aug 2001 13:21:38 -0700 (PDT) From: Tony Przygienda To: RJ Atkinson Cc: isis-wg@juniper.net Message-id: <3B86B27E.9E1A5672@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: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> <5.1.0.14.2.20010824093213.00a1ed30@10.30.15.2> X-OriginalArrivalTime: 24 Aug 2001 20:21:14.0593 (UTC) FILETIME=[52C09510:01C12CDA] Subject: [Isis-wg] Re: On authenticating IS-IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 13:01:02 -0700 Content-Transfer-Encoding: 7BIT RJ Atkinson wrote: > At 02:35 24/08/01, Tony Przygienda wrote: > >neither am I, I was only saying if somebody has cycles to put into that, > >he rather do a good job rather than come up with a hacky solution for > >a problem that the ISPs don't have and not solving a problem they may > >or will have properly either ... > > Tony, > > My own sense is that the next useful increase in attacker work > function (beyond the tli HMAC draft) is probably to go to full Digital > Signatures (along the lines of RFC-2154). > > I am only aware of one implementation of RFC-2154 (done by > its authors) and zero deployments of RFC-2154. I interpret that > state of implementation and deployment as indicating that: > > "most of the community doesn't think the current threats > justify that level of security complexity and adverse > performance impact today" agreed, once at it and since as you say things would not be pressing timewise, time could be spend on nonce-negotiation on hellos and possibly key, encryption negotiation so all exchanges between 2 peers could not only be secure but also private. Combined with a method to propagate with an LSP the information whether it was only flooded across encrypted and negotiated links, we could claim all best practical security known to at least me incl. privacy. I have nothing against such far forward-looking work, especially if each of those pieces is standardized as optional. Time may come when we need it. Again, I completely agree that practical deployment of security has far lagged the lip-service being paid to it and therefore the work only makes sense if someone really wants to spend cycles to do it right and is willing to wait long-time for deployment. That is to be attributed probably to the cynical truth that security is not an inherent need mostly, it's rather an acquired taste like horror movies ;-) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Aug 24 17:07:45 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15565 for ; Fri, 24 Aug 2001 17:07:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA95314; Fri, 24 Aug 2001 14:17:33 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA95301 for ; Fri, 24 Aug 2001 14:16:31 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7OL76i95294 for ; Fri, 24 Aug 2001 14:07:06 -0700 (PDT) X-JNPR-Received-From: outside Received: from gnat.inet.org ([63.108.254.91]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 14:02:05 -0700 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id AF8798266F; Fri, 24 Aug 2001 17:02:27 -0400 (EDT) Message-Id: <5.1.0.14.2.20010824165424.00a184a0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Tony Przygienda From: RJ Atkinson Cc: isis-wg@juniper.net In-Reply-To: <3B86B27E.9E1A5672@redback.com> References: <3B85569D.40E1F15D@redback.com> <7msneieaxm.fsf@challah.msrl.com> <3B8590E6.17BE6D3A@redback.com> <7md75mxlpt.fsf@challah.msrl.com> <5.1.0.14.2.20010824093213.00a1ed30@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 24 Aug 2001 21:02:05.0718 (UTC) FILETIME=[07BC9360:01C12CE0] Subject: [Isis-wg] Re: On authenticating IS-IS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 24 Aug 2001 16:56:53 -0400 At 16:01 24/08/01, Tony Przygienda wrote: >...since as you say things would not be pressing timewise, >time could be spend on nonce-negotiation on hellos and possibly >key, encryption negotiation so all exchanges between 2 peers could not >only be secure but also private. Combined with a method to propagate >with an LSP the information whether it was only flooded across >encrypted and negotiated links, we could claim all best practical >security known to at least me incl. privacy. I have nothing against >such far forward-looking work, especially if each of those pieces >is standardized as optional. Time may come when we need it. One approach worth examining if confidentiality were an objective would be implementation/deployment of the IEEE 802.10 security specification. It has not been widely implemented or deployed, as far as I know, but some good folks did work on that spec. I do not have a copy, so don't know precisely what is in the 802.10 specification. Ran _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 27 01:09:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21291 for ; Mon, 27 Aug 2001 01:09:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA10406; Sun, 26 Aug 2001 22:18:34 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA10394 for ; Sun, 26 Aug 2001 22:17:13 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7R579625781; Mon, 27 Aug 2001 01:07:10 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (jlearman-dsl3.cisco.com [10.83.2.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABL04708; Mon, 27 Aug 2001 01:07:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827003934.02043020@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Les Ginsberg From: Jeff Learman Subject: RE: [Isis-wg] New 10589 spec, PtoP and ISHs Cc: "'Neal Castagnoli'" , isis-wg@spider.juniper.net In-Reply-To: <17C81AD1F1FED411991E006008F6D1CAA5A63C@avalon.pluris.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 Aug 2001 00:41:14 -0400 If my memory serves me, on a PTP circuit, an implementation is required to handle receipt of an IIH without having received an ISH, so Les's wise general rule doesn't need to be invoked. At 04:39 PM 8/21/2001, Les Ginsberg wrote: >This issue is a confusing one, some of which is due to the fact that the >original wording in ISO 10589:1992 was revised by Technical Corrigendum I >(published in 1993), but because many people do not have ready access to the >TCs, they rely on the uncorrected original text. In fact, the original >intent was made clear in TC1 by adding: > >"An IS shall cause ISO 9542 to send an ISH PDU whenever a point-to-point >circuit is first enabled." > >and then changing the original text in 8.2.3a (which Neal refers to in >stating that an IIH was supposed to be sent when the circuit was first >enabled) to read: > >"a)the IS receives an ISH PDU" > >So the original intent was to wait for receipt of an ISH before beginning to >send IIHs. The latest ISO 10589 draft further clarifies this by specifying >that ISH's should continue to be sent periodically until the adjacency >reaches the UP state. This is a logical requirement discovered when >implementing that was not clearly stated even in the TC1 changes. > >In an IP only IS-IS implementation, the use of ISH's is an anachronism. Many >implementations relax the requirements, at least on reception, so that >receiving an ISH is not required. In following the old axiom of being >"strict in what you send and generous in what you receive", a robust >implementation should send ISHs until the adjacency is up, but allow (at >least for IP operation) the adjacency to come up without ever seeing an ISH. >This is easily achieved by starting to send IIHs when you first receive an >IIH. > >I can tell you from first hand experience that there are indeed >implementations out there which do not send ISHs. > > Les > > > > >> -----Original Message----- >> From: Neal Castagnoli [mailto:cast@allegronetworks.com] >> Sent: Tuesday, August 21, 2001 1:14 PM >> To: isis-wg@spider.juniper.net >> Subject: [Isis-wg] New 10589 spec, PtoP and ISHs >> >> >> >> From the original 10589, routers might be able to get around >> sending ISHs on >> ptop circuits. The original states routers should transmit an IIH >> immediately upon circuit startup, and so an implementation >> need not send an >> ISH to get the peer IS to start IIH transmission. New 10589, however, >> removes this wording, and now it appears routers require >> receipt of an ISH >> prior to sending the first IIH. >> >> Yet if there are old implementations that don't send ISHs, >> ptop adjacencies >> won't come up with strict new implementations. Does anyone >> know whether >> there are deployed ISIS implementations that don't send ISHs on ptop >> circuits? >> >> Thanks, >> >> --Neal >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 27 03:10:02 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07937 for ; Mon, 27 Aug 2001 03:10:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA10926; Mon, 27 Aug 2001 00:18:33 -0700 (PDT) Received: from bart.cwnt.com ([192.116.246.129]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA10914 for ; Mon, 27 Aug 2001 00:17:01 -0700 (PDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] More than 256 LSPs X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: [Isis-wg] More than 256 LSPs Thread-Index: AcEsf1LYEbdhg9MaS8CLWQVobH0jzQB7Zavg From: "Amir Hermelin" To: "Manav Bhatia" Cc: "ISIS-wg (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id AAA10915 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 Aug 2001 10:07:07 +0300 Content-Transfer-Encoding: 8bit Manav, as Naiming expressed, that is the exact concept discussed in the draft. As was detailed in an earlier version of the draft, this does have its limitations (this was discussed at the wg meeting - see notes). In the current (02) version of the draft, these limitations are removed by a new "operational mode" (the term used in the draft): telling other routers that the two (in your example) are really one. The older mode, where we "fool" older implementations into processing the LSPs correctly, still exists. -- Amir Hermelin Charlotte's Web Networks Inc. -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Friday, August 24, 2001 12:34 PM To: Amir Hermelin; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] More than 256 LSPs Hi Amir, I went through this draft and is quite interesting but there is another approach which you can take to increase the number of LSPs beyond 256. I dont remember the details but it goes something like this .. We act as two routers that are adjacent to one another and as long as we act like what we are advertising then no one can tell. This way we can thus issue 512 LSPs . Has anybody ever heard of such a concept ?? Thanks and Regards, Manav Bhatia ----- Original Message ----- From: "Amir Hermelin" To: "Manav Bhatia" ; Sent: Thursday, August 23, 2001 5:08 PM Subject: RE: [Isis-wg] More than 256 LSPs Manav, check out this draft http://www.ietf.org/internet-drafts/draft-hermelin-ext-lsp-frags-02.txt It attempts to solve the problem and remove the 256 limit. -- Amir Hermelin Charlotte's Web Networks Inc. > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Thursday, August 23, 2001 5:54 AM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] More than 256 LSPs > > > A single IS can at most issue 256 LSPs and it has to pack > everything it > wants to advertise into this much. Are there any hacks > wherein i may be able > to send more information than i what i am capable of using my > 256 LSPs. I > believe one such mechanism is by faking a LAN .. but i am not > sure as to how > it may work. > Can anybody please explain ? > > Thanks and Regards, > Manav Bhatia > > "C is not a big language, and is not well served by a big > book." -- K&R2 > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 27 13:51:03 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25775 for ; Mon, 27 Aug 2001 13:51:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13542; Mon, 27 Aug 2001 10:59:34 -0700 (PDT) Received: from tahoe.allegronetworks.com (tahoe.allegronetworks.com [63.115.58.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13530 for ; Mon, 27 Aug 2001 10:58:40 -0700 (PDT) Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 10:48:54 -0700 Message-ID: From: Neal Castagnoli To: "'Jeff Learman'" , Les Ginsberg Cc: Neal Castagnoli , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] New 10589 spec, PtoP and ISHs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 Aug 2001 10:48:53 -0700 I think Les has it right. New strict implementations shouldn't begin sending IIHs until they receive an ISH. Perhaps they will accept the IIH, but they won't begin sending the IIH. --Neal > > > If my memory serves me, on a PTP circuit, an implementation > is required > to handle receipt of an IIH without having received an ISH, so Les's > wise general rule doesn't need to be invoked. > > At 04:39 PM 8/21/2001, Les Ginsberg wrote: > >This issue is a confusing one, some of which is due to the > fact that the > >original wording in ISO 10589:1992 was revised by Technical > Corrigendum I > >(published in 1993), but because many people do not have > ready access to the > >TCs, they rely on the uncorrected original text. In fact, > the original > >intent was made clear in TC1 by adding: > > > >"An IS shall cause ISO 9542 to send an ISH PDU whenever a > point-to-point > >circuit is first enabled." > > > >and then changing the original text in 8.2.3a (which Neal > refers to in > >stating that an IIH was supposed to be sent when the circuit > was first > >enabled) to read: > > > >"a)the IS receives an ISH PDU" > > > >So the original intent was to wait for receipt of an ISH > before beginning to > >send IIHs. The latest ISO 10589 draft further clarifies this > by specifying > >that ISH's should continue to be sent periodically until the > adjacency > >reaches the UP state. This is a logical requirement discovered when > >implementing that was not clearly stated even in the TC1 changes. > > > >In an IP only IS-IS implementation, the use of ISH's is an > anachronism. Many > >implementations relax the requirements, at least on > reception, so that > >receiving an ISH is not required. In following the old axiom of being > >"strict in what you send and generous in what you receive", a robust > >implementation should send ISHs until the adjacency is up, > but allow (at > >least for IP operation) the adjacency to come up without > ever seeing an ISH. > >This is easily achieved by starting to send IIHs when you > first receive an > >IIH. > > > >I can tell you from first hand experience that there are indeed > >implementations out there which do not send ISHs. > > > > Les > > > > > > > > > >> -----Original Message----- > >> From: Neal Castagnoli [mailto:cast@allegronetworks.com] > >> Sent: Tuesday, August 21, 2001 1:14 PM > >> To: isis-wg@spider.juniper.net > >> Subject: [Isis-wg] New 10589 spec, PtoP and ISHs > >> > >> > >> > >> From the original 10589, routers might be able to get around > >> sending ISHs on > >> ptop circuits. The original states routers should transmit an IIH > >> immediately upon circuit startup, and so an implementation > >> need not send an > >> ISH to get the peer IS to start IIH transmission. New > 10589, however, > >> removes this wording, and now it appears routers require > >> receipt of an ISH > >> prior to sending the first IIH. > >> > >> Yet if there are old implementations that don't send ISHs, > >> ptop adjacencies > >> won't come up with strict new implementations. Does anyone > >> know whether > >> there are deployed ISIS implementations that don't send > ISHs on ptop > >> circuits? > >> > >> Thanks, > >> > >> --Neal > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > >> > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Aug 27 17:11:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00656 for ; Mon, 27 Aug 2001 17:11:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14377; Mon, 27 Aug 2001 14:21:33 -0700 (PDT) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA14365 for ; Mon, 27 Aug 2001 14:20:57 -0700 (PDT) Received: from neserve0.corp.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.92.148]) id QQldya25041; Mon, 27 Aug 2001 21:11:09 GMT Received: from SYSENGLT222 by neserve0.corp.us.uu.net with SMTP (peer crosschecked as: localhost [127.0.0.1]) id QQldya10896; Mon, 27 Aug 2001 17:11:06 -0400 (EDT) Message-Id: <3.0.32.20010827171247.00df2d88@neserve0.corp.us.uu.net> X-Sender: abirjand@neserve0.corp.us.uu.net X-Mailer: Windows Eudora Pro Version 3.0 (32) To: "isis-wg" , danny@ambernetworks.com From: Amir Birjandi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Isis-wg] Setting the over load bit in an MPLS network Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 27 Aug 2001 17:12:48 -0400 Hi, After reading IS-IS Transient Black hole Avoidance draft i have this basic question. Imagine, we have a multihop Label switch path, which is carrying the traffic. routerA---routerB----routerC----routerD the label switch path---> from A to D. IGP== ISIS there are also a number of disjoint paths between A and D. If we set the overload bit on C or B, how would router A know it should stop sending traffic over that Label switch path. Any comments is highly appreciated Amir _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 00:24:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10669 for ; Tue, 28 Aug 2001 00:24:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA16152; Mon, 27 Aug 2001 21:34:33 -0700 (PDT) Received: from smtp010.mail.yahoo.com (smtp010.mail.yahoo.com [216.136.173.30]) by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA16140 for ; Mon, 27 Aug 2001 21:33:16 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Aug 2001 04:23:26 -0000 X-Apparently-From: Message-ID: <00cf01c12f79$9d0b5b40$b4036c6b@Manav> From: "Swati Rastogi" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] Default Routes in ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 09:56:26 +0530 Content-Transfer-Encoding: 7bit Hi, Section 1.3 "Overview of the Integrated IS-IS" in RFC 1195 states that "Default routes are permitted only at level 2 as external routes. Default routes are not permitted at level 1" This would imply that all the L1 routers must be connected to either a L2 only or L1/L2 router. Is it so ?? I thought that a L1 router can be so set up which is only connected to another L1 router which will act as a gateway to the last resort. The other L1 router may in turn be connected to another L1/L2 router to ship packets outside the area. Can anybody please explain. Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 00:43:28 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10859 for ; Tue, 28 Aug 2001 00:43:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA16269; Mon, 27 Aug 2001 21:52:33 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by external.juniper.net (8.9.3/8.9.3) with SMTP id VAA16257 for ; Mon, 27 Aug 2001 21:51:27 -0700 (PDT) Received: from unknown (HELO Manav) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Aug 2001 04:41:37 -0000 X-Apparently-From: Message-ID: <013501c12f7c$272cc460$b4036c6b@Manav> From: "Swati Rastogi" To: "isis-wg" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Isis-wg] rfc 1195 (another one!) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 10:14:39 +0530 Content-Transfer-Encoding: 7bit Hi, The way as i understood IS-IS routing goes something like this .. i am a L1 router and i recieve a packet destined to some other area so i forward that packet to my nearest L2 router. How i know that this packet does not belong to my area is by looking at its address. Then once it reaches the L2 router since it is aware of all the areas which it can reach it will forward the packet in question to the appropriate router. It will extract the area address also once again from the destination address in the packet. I hope i am okay till now .. Since everything is mentioned in the address itself and we can do all our routing just by looking at the address then we is it said that "L2 routers should include in their L2 LSPs a complete list of [IP address, subnet mask, metric] specifying all IP addresses reachable in their area" [RFC 1195.. Section 1.3]. Even in dual IS-IS we specify the area so why isn't the entire routing done just by looking at area prefixes. Please comment. Regards, Swati _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 03:43:36 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29000 for ; Tue, 28 Aug 2001 03:43:34 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA17026; Tue, 28 Aug 2001 00:53:34 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA17014 for ; Tue, 28 Aug 2001 00:52:09 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA12975; Tue, 28 Aug 2001 09:42:17 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010828093113.03354bc8@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Amir Birjandi From: stefano previdi Subject: Re: [Isis-wg] Setting the over load bit in an MPLS network Cc: "isis-wg" , danny@ambernetworks.com In-Reply-To: <3.0.32.20010827171247.00df2d88@neserve0.corp.us.uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 09:39:32 +0200 At 23:12 27/08/2001, Amir Birjandi wrote: >Hi, > >After reading IS-IS Transient Black hole Avoidance > draft i have this basic question. > >Imagine, > >we have a multihop Label switch path, which is carrying the traffic. > >routerA---routerB----routerC----routerD > >the label switch path---> from A to D. > >IGP== ISIS > >there are also a number of disjoint paths between A and D. > >If we set the overload bit on C or B, how would router A know it should >stop sending traffic over that Label switch path. it will know it through spf. labels are bound to routes. When your neighbors advertise you label bindings, you select the label for a given route if such label has been bound by the neighbor who is also your next-hop for that given route. Setting the ovl bit will change the topology, therefore the routing table, and therefore your next-hops. So, you will use other labels from other neighbors (the new next-hops). s. >Any comments is highly appreciated > >Amir >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 03:57:06 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29097 for ; Tue, 28 Aug 2001 03:57:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA17133; Tue, 28 Aug 2001 01:06:35 -0700 (PDT) Received: from cisco.com (brussels.cisco.com [144.254.15.68]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA17121 for ; Tue, 28 Aug 2001 01:05:19 -0700 (PDT) Received: from SPREVIDI-W2K.cisco.com (sprevidi-isdn-home.cisco.com [10.49.0.58]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA16573; Tue, 28 Aug 2001 09:55:07 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010828094014.03526320@brussels.cisco.com> X-Sender: sprevidi@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Swati Rastogi" From: stefano previdi Subject: Re: [Isis-wg] Default Routes in ISIS Cc: "isis-wg" In-Reply-To: <00cf01c12f79$9d0b5b40$b4036c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 09:52:22 +0200 At 06:26 28/08/2001, Swati Rastogi wrote: >Hi, >Section 1.3 "Overview of the Integrated IS-IS" in RFC 1195 states that >"Default routes are permitted only at level 2 as external routes. Default >routes are not permitted at level 1" >This would imply that all the L1 routers must be connected to either a L2 >only or L1/L2 router. Is it so ?? I thought that a L1 router can be so set >up which is only connected to another L1 router which will act as a gateway >to the last resort. The other L1 router may in turn be connected to another >L1/L2 router to ship packets outside the area. this is not exactly what happens in most implementations. Default route can be orignated in level-1 areas or can be leaked (using rfc2966) into a level-1 area. s. >Can anybody please explain. > >Regards, >Swati > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 04:30:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29531 for ; Tue, 28 Aug 2001 04:30:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA17318; Tue, 28 Aug 2001 01:40:34 -0700 (PDT) Received: from kpnqwest.com (smtp.kpnqwest.com [193.242.92.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA17303 for ; Tue, 28 Aug 2001 01:39:12 -0700 (PDT) Received: from ntexghub01.kpnqwest.com (unverified) by kpnqwest.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 28 Aug 2001 10:29:16 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 10:29:16 +0200 Message-ID: <1E810ACBCC29D51185DF00508B66CCEE04B774@ntexghfd02> From: "Metz, Eduard" To: "'Swati Rastogi'" , isis-wg Subject: RE: [Isis-wg] Default Routes in ISIS MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 10:29:13 +0200 L1 routers can use the "attached bit" set by the L1/L2 routers to determine the nearest exit out of the L1 area. This does not require all L1 routers to be connected to an L2 or L1/L2 router, all routers do need to interpret the attached bit (and the L1/L2 need to set it). Most current implementation can/do this ... cheers, Eduard > -----Original Message----- > From: Swati Rastogi [mailto:swatirstogi@yahoo.com] > Sent: 28 August 2001 06:26 > To: isis-wg > Subject: [Isis-wg] Default Routes in ISIS > > > Hi, > Section 1.3 "Overview of the Integrated IS-IS" in RFC 1195 states that > "Default routes are permitted only at level 2 as external > routes. Default > routes are not permitted at level 1" > This would imply that all the L1 routers must be connected to > either a L2 > only or L1/L2 router. Is it so ?? I thought that a L1 router > can be so set > up which is only connected to another L1 router which will > act as a gateway > to the last resort. The other L1 router may in turn be > connected to another > L1/L2 router to ship packets outside the area. > > Can anybody please explain. > > Regards, > Swati > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 05:41:41 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00618 for ; Tue, 28 Aug 2001 05:41:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA17789; Tue, 28 Aug 2001 02:45:36 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA17774 for ; Tue, 28 Aug 2001 02:44:29 -0700 (PDT) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp1.cisco.com [144.254.108.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA00698; Tue, 28 Aug 2001 10:34:34 +0100 (BST) Message-Id: <4.3.2.7.2.20010828102001.00b7bf08@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Manav Bhatia" From: mike shand Subject: Re: [Isis-wg] SNAP & NSAP Cc: In-Reply-To: <01fa01c1208c$c5d0a4a0$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 10:34:10 +0100 At 10:05 09/08/2001 +0530, Manav Bhatia wrote: >I have a small doubt . . > >(i) NSAP is an OSI equivalent of an IP address in a TCP/IP network. Almost. An NSAP is a Network Service Access Point, which has an address, the NSAP address, which is broadly equivalent to an IP address. But note that an NSAP address is NOT tied to an interface in the same way that an IP address is. >Is SNAP address equivalent of the ethernet address in the data link layer if >its a 802.2 ntwrk ? No. SNAP, stands for Sub-network Access Protocol. 8802-2 (LLC) defines various LLC classes. Class 1, which provides a datagram service, has one byte DSAP and SSAP fields, which identify the higher layer (3) protocol. For example FE identifies ISO connectionless network layer protocols. But SAP addresses are only assigned to standardized protocols, so there is another frame format which is used for non-standardized protocols. This is SNAP. It is assigned its own SAP of AA, but then the frame format diverges from LLC1, since it has a 5 byte Protocol ID field, which is used to identifier the higher layer protocol. The first 3 bytes are taken from a 24 bit IEEE block identifier, and the remaining 2 bytes are assigned by the owner of that block. This allows proprietary protocols to be distinguished by a vendor. So although the prot ID field of SNAP LOOKS a bit like an ethernet address, it is in fact a protocol identifier (in the same sense that the SAP addresses are). But aren't we getting somewhat off topic with this spate of OSI tutorials? Mike >Rgds, >Manav > >"C is not a big language, and is not well served by a big book." -- K&R2 > > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 05:55:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00764 for ; Tue, 28 Aug 2001 05:55:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA17899; Tue, 28 Aug 2001 03:05:35 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA17884 for ; Tue, 28 Aug 2001 03:04:24 -0700 (PDT) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp1.cisco.com [144.254.108.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA01419; Tue, 28 Aug 2001 10:54:29 +0100 (BST) Message-Id: <4.3.2.7.2.20010828105323.0361a008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Mareline Sheldon" From: mike shand Subject: Re: [Isis-wg] Manual Adjacencies Cc: "isis-wg" In-Reply-To: <004101c12167$af70fc10$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 10:54:19 +0100 At 12:12 10/08/2001 +0530, Mareline Sheldon wrote: >The RFC 1142 (7.3.3.1) says "NOTE - Manual End system Adjacencies shall not >be included in a level 1 LSPs issued on behalf of a pseudonode, since that >would presuppose that all Intermediate systems on a broadcast subnetwork had >the same set of manual adjacencies as defined in the ciruit" > >This is not very clear .. if it is not done so then how do manual >adjacencies get advertised on a psedonode ? They don't! They only get advertised in the LSPs of the system with the manual adjacency. Mike >Please help! > >/Mary > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 06:28:37 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01101 for ; Tue, 28 Aug 2001 06:28:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18109; Tue, 28 Aug 2001 03:31:34 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18094 for ; Tue, 28 Aug 2001 03:30:23 -0700 (PDT) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp1.cisco.com [144.254.108.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA02305; Tue, 28 Aug 2001 11:19:52 +0100 (BST) Message-Id: <4.3.2.7.2.20010828111623.035b2258@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: mike shand Subject: RE: [Isis-wg] IIH PDU exchange Cc: "'Manav Bhatia'" , "'isis-wg@spider.juniper.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 11:19:42 +0100 At 11:46 14/08/2001 -0400, Jeff Parker wrote: > > "LAN IIH PDUs shall be padded... > > > > Consider the following scenario: The network is in a > > congested state and we are bringing up [all] the IS-IS > > system[s]. > > > > Manav Bhatia > >Manav - > There are periodic dicussions on the list about >the utility of the padding, and I won't rehash those >here. Yes, the original idea was to also detect cases where both ends of the communication thought it was a large MTU, but in fact only small packets could be sent. There are various failure/misconfiguration condidtions which can lead to this, the classic one we had in mind being FDDI's connected through a (non-fragmenting) ethernet bridge, but can also postulate pt-pt links which are data length sensitive. In practice, most implementation permit the padding to be switched off. > If you have so many IS-IS routers that periodic >hello packets are a big problem, then I suspect the >LSP exchange that will start once the adjacencies come >up will have a greater effect. > >- jeff parker >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 06:33:10 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01181 for ; Tue, 28 Aug 2001 06:33:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18204; Tue, 28 Aug 2001 03:43:35 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18192 for ; Tue, 28 Aug 2001 03:42:51 -0700 (PDT) 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 f7SAX1s95779 for ; Tue, 28 Aug 2001 03:33:01 -0700 (PDT) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.150]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 28 Aug 2001 03:27:26 -0700 Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp1.cisco.com [144.254.108.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA02512; Tue, 28 Aug 2001 11:27:51 +0100 (BST) Message-Id: <4.3.2.7.2.20010828112434.038e2948@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Przygienda From: mike shand Subject: Re: [Isis-wg] tlv codepoints ... Cc: isis-wg@juniper.net In-Reply-To: <3B79992B.9E287E89@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 28 Aug 2001 10:27:26.0724 (UTC) FILETIME=[088A3440:01C12FAC] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 11:27:29 +0100 At 14:33 14/08/2001 -0700, Tony Przygienda wrote: > DECnet Phase IV 42 ? ? ? DEC (ancient) Tony, It should only appear in the IIHs, so.... DECnet PhaseIV 42 y n n _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 06:42:12 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01436 for ; Tue, 28 Aug 2001 06:42:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18284; Tue, 28 Aug 2001 03:52:35 -0700 (PDT) Received: from web11208.mail.yahoo.com (web11208.mail.yahoo.com [216.136.131.190]) by external.juniper.net (8.9.3/8.9.3) with SMTP id DAA18267 for ; Tue, 28 Aug 2001 03:51:43 -0700 (PDT) Message-ID: <20010828104152.63263.qmail@web11208.mail.yahoo.com> Received: from [202.9.170.10] by web11208.mail.yahoo.com via HTTP; Tue, 28 Aug 2001 03:41:52 PDT From: Aravind Ravikumar Subject: Re: [Isis-wg] Protocol parameter. To: Aravind Ravikumar , Sachidananda K , isis-wg@spider.juniper.net In-Reply-To: <20010823103255.8412.qmail@web11205.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-355408955-998995312=:63144" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 03:41:52 -0700 (PDT) --0-355408955-998995312=:63144 Content-Type: text/plain; charset=us-ascii Hi Sachidananda, I feel that I was wrong when I said that individual LSPs will remain in the memory for atleast minimumLSP TransmissionInterval and no more than twice that interval LSP from a particular source shouldn't be transmitted within minimumLSP transmission interval.This means that if we take an individual LSP it will remain in memory before transmission for 0 to 5 seconds according to when the last LSP from same source was transmitted We can achive this requirement precisely by keeping timers for individual LSPs.So as soon as this timer expires we could transmit the LSP on the appropriate circuits.For all point to point circuit with SRM flags set it can be send imediately.For broadcast network ensure an interval of 32 milliseconds between successive transmissions on the same LAN. Since it will be difficult to implement per LSP timer, ISO 10589(7.3.15.5) gives a relaxation to this requirement in section and says that any implementation that ensures an interval between minimumLSP TransmissionInterval and twice that interval is OK . We can avoid the need for individual timers and even then meet the requirement fo broadcast circuit precisely and for point to point circuit almost precisely(maximum delay of 32 millisecondsafter the LSP gets ready),if we scan the database each 32 milliseconds along with last sent timestamp.But as 10589 itself says it will be very inefficient to scan at the whole database at this rate.We are free to use any techinique which is reasonably precise and utilizes the relaxation to the exact timer requirement mentioned above Aravind --------------------------------- Do You Yahoo!? Make international calls for as low as $0.04/minute with Yahoo! Messenger. --------------------------------- Do You Yahoo!? Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-355408955-998995312=:63144 Content-Type: text/html; charset=us-ascii

Hi Sachidananda, 

         I feel that I was wrong when I said that individual LSPs will remain in the memory for atleast minimumLSP TransmissionInterval and no more than twice that interval

LSP from a particular source shouldn't be transmitted within minimumLSP transmission interval.This means that if we take an individual LSP it will remain in memory before transmission for 0 to 5 seconds according to when the last LSP from same source was transmitted

We can achive this requirement precisely by keeping timers for individual LSPs.So as soon as  this timer expires we could transmit the LSP on the appropriate circuits.For all point to point circuit with SRM flags set it can be send imediately.For broadcast network ensure an interval of 32 milliseconds between successive transmissions on the same LAN.


Since it will be difficult to implement per LSP timer, ISO 10589(7.3.15.5) gives a relaxation to this requirement in section and says that any implementation that ensures an interval between minimumLSP TransmissionInterval and  twice that interval is OK .

We can avoid the need for individual timers and even then meet the requirement fo broadcast circuit precisely and for point to point circuit almost precisely(maximum delay of 32 millisecondsafter the LSP gets ready),if we scan the database each 32 milliseconds along with last sent timestamp.But as 10589 itself says it will be very inefficient to scan at the whole database at this rate.We are free to use any techinique which is reasonably precise and utilizes the relaxation to the exact timer requirement mentioned above

 

Aravind 

Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger.


Do You Yahoo!?
Make international calls for as low as $0.04/minute with Yahoo! Messenger. --0-355408955-998995312=:63144-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 06:44:31 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01586 for ; Tue, 28 Aug 2001 06:44:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18311; Tue, 28 Aug 2001 03:54:56 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA18272 for ; Tue, 28 Aug 2001 03:51:54 -0700 (PDT) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp1.cisco.com [144.254.108.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA03066; Tue, 28 Aug 2001 11:41:51 +0100 (BST) Message-Id: <4.3.2.7.2.20010828113829.038f8c20@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Dave Katz From: mike shand Subject: Re: [Isis-wg] Protocol parameter. Cc: mnvbhatia@yahoo.com, sachidananda_k@hotmail.com, isis-wg@spider.juniper.net In-Reply-To: <200108211504.IAA19768@cirrus.juniper.net> References: <00a301c12a3f$6d2c98b0$da046c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 11:41:41 +0100 At 08:04 21/08/2001 -0700, Dave Katz wrote: >Of course, any implementation that actually scans the database looking >for things to send will probably have other intractable scaling problems >as well. > >Unlike the OSPF spec, the ISIS spec provides very little implementation >guidance (a feature, I believe, as it promotes actual thinking.) > >All that minimumBroadcastLSPTransmissionInterval does is ensure that >the transmission rate is controlled so you don't swamp your receivers >(as there is no flow control in the protocol.) and randomizes the transmission order so that multiple routers on the LAN don't all try to send the same LSP at the same time. Note that seeing someone else transmit an LSP clears your SRMflag for it, so you don't need to bother transmitting it. This probably doesn't matter in the normal case of only a few routers on the LAN, but we were trying to make it scale to > 32 routers (I can't remember why :-) Mike > X-Apparently-From: > Reply-To: "Manav Bhatia" > From: "Manav Bhatia" > Cc: > References: > Organization: Samsung India Operations > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 5.50.4133.2400 > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Sender: isis-wg-admin@spider.juniper.net > Errors-To: isis-wg-admin@spider.juniper.net > X-BeenThere: isis-wg@external.juniper.net > X-Mailman-Version: 2.0rc1 > Precedence: bulk > List-Help: > List-Post: > List-Subscribe: , > > List-Id: IETF IS-IS working group > List-Unsubscribe: , > > List-Archive: > Date: Tue, 21 Aug 2001 18:16:16 +0530 > > Please find my comments inline .. > > > Does this parameter corresponds to the frequency at which Link State > > Database is scanned for transmitting the LSP? That is every > > minimumBroadcastLSPTransmissionInterval duration the Link state database > > MUST be scanned for searching the LSP to be sent. > > Yes. Setting the SRMflag does not cause the LSP to be transmitted > immediately. Instead the IS scans the database after every > minimumBroadcastLSPTransmissionInterval and choses the LSP to be > multicasted > randomly. Once this is done the SRMflag for the corresponding LSP is > cleared. > > Hope this helps, > Manav Bhatia > > > > > Or it corresponds to the minimum time interval that needs to be allowed > > between consecutive packets (be it of any type) on a LAN interface? that > is > > suppose on a particular interface (say A) if a LSP is sent, then for the > > next minimumBroadcastLSPTransmissionInterval duration no other > packets of > > any type is to be sent on this interface. > > > > Apart from this, if the point 1 is not true, then is there any parameter > > that dictates the frequency at which the link state database is to be > > scanned for searching the LSP to be sent? > > > > Thanking in advance for all early responses that I receive. > > Sachi > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 11:06:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12523 for ; Tue, 28 Aug 2001 11:06:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA19441; Tue, 28 Aug 2001 08:16:35 -0700 (PDT) Received: from mailrelay.laurelnetworks.com (host11.laurelnetworks.com [63.94.127.11] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with SMTP id IAA19429 for ; Tue, 28 Aug 2001 08:15:37 -0700 (PDT) Received: from laurelnetworks.com (IDENT:tgol@tgol-pc-linux.laurelnetworks.com [10.0.4.230]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id LAA27928; Tue, 28 Aug 2001 11:05:35 -0400 Message-ID: <3B8BB33F.E58E1A31@laurelnetworks.com> From: Tayfun Gol X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Swati Rastogi CC: isis-wg Subject: Re: [Isis-wg] rfc 1195 (another one!) References: <013501c12f7c$272cc460$b4036c6b@Manav> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 11:05:35 -0400 Content-Transfer-Encoding: 7bit Swati Rastogi wrote: > Hi, > The way as i understood IS-IS routing goes something like this .. i am a L1 > router and i recieve a packet destined to some other area so i forward that > packet to my nearest L2 router. How i know that this packet does not belong > to my area is by looking at its address. Then once it reaches the L2 router > since it is aware of all the areas which it can reach it will forward the > packet in question to the appropriate router. It will extract the area > address also once again from the destination address in the packet. > I hope i am okay till now .. As far as OSI forwarding goes, you are. > > Since everything is mentioned in the address itself and we can do all our > routing just by looking at the address then we is it said that "L2 routers This again is valid for OSI forwarding only, you can not associate an IP destination address to an area address prefix ( which is derived from NSAP address, you would have an NSAP destination address for forwarding OSI traffic, not IP ) Tayfun Gol > > should include in their L2 LSPs a complete list of [IP address, subnet mask, > metric] specifying all IP addresses reachable in their area" [RFC 1195.. > Section 1.3]. Even in dual IS-IS we specify the area so why isn't the entire > routing done just by looking at area prefixes. > > > Please comment. > > Regards, > Swati > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 14:23:21 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17815 for ; Tue, 28 Aug 2001 14:23:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA20252; Tue, 28 Aug 2001 11:33:35 -0700 (PDT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA20240 for ; Tue, 28 Aug 2001 11:32:09 -0700 (PDT) Received: (qmail 55462 invoked from network); 28 Aug 2001 18:22:16 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 28 Aug 2001 18:22:16 -0000 From: "Ken Larmer" To: "Isis-Wg@Spider. Juniper. Net" Cc: "Ken Larmer" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 14:24:29 -0400 Content-Transfer-Encoding: 7bit Hi, I am a bit confused as to what exactly should be present in the L2 LSP "IP Internal Reachability Information" TLV? RFC-1195 states the following: 5.2 Overview of IP-Specific Information for IS-IS If included in level 2 LSPs, this field includes only entries reachable by the router, which originates the LSP, either via one of its interfaces, or indirectly via level 1 routing. We are conducting Interoperability tests on various Integrated IS-IS implementations. I am seeing conflicting "IP Internal Reachability Information" in the L2 LSPs being generated throughout the common L1/L2 Domain. To make matters worse, I am seeing conflicting contents when I do a reboot versus a "clear isis" with the same exact configuration? Sometimes the L2 LSP contains ONLY directly attached subnets and other times it contains the union of L1 areas? The reason I raise these issues is because there MAY be a conflict in the protocol specifications, which affects calculation of routes through an IS with an LSPDB overload condition? Let me explain using the following configuration: IP Subnet (10.10.10.0) [A][B][C][D] IP subnet (11.11.11.0) ^ LSPDB Overload condition All 4 IS routers (A,B,C,D) share a common area address (same L1 Sub-Domain) and are also part of the same L2 Domain. IS-B has a LSPDB overload condition and advertises this in it's L1/L2 LSP by setting the LSPDB overload bit. The other routers receive these LSPs and process them properly; they calculate routes to directly attached destinations but do not use IS-B as a transient IS. The problem is that an IP host connected to subnet 11.11.11.0 can still reach subnet 10.10.10.0. This is made possible because IS-B is advertising, in it's L2 LSP, the contents specified above in RFC-1195 Section 5.2. As a consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable via L2 routing, because they think IS-B has a direct connection to this subnet. Am I missing something fundamental here? Of course, if the above is the case then it will cause LSPDB overload conditions to be ineffective, given a similar configuration. This means the draft-ietf-isis-transient could also be made ineffective? Is this an implementation problem, protocol specific problem or just me being out to lunch? Any assistance would be greatly appreciated! Cheers, Ken Larmer _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Aug 28 15:11:16 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19017 for ; Tue, 28 Aug 2001 15:11:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA20472; Tue, 28 Aug 2001 12:21:35 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA20460 for ; Tue, 28 Aug 2001 12:20:14 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 87D05F2C4F; Tue, 28 Aug 2001 12:10:21 -0700 (PDT) To: Amir Birjandi Cc: "isis-wg" , danny@ambernetworks.com Subject: Re: [Isis-wg] Setting the over load bit in an MPLS network In-reply-to: Mail from Amir Birjandi dated Mon, 27 Aug 2001 17:12:48 EDT <3.0.32.20010827171247.00df2d88@neserve0.corp.us.uu.net> From: Naiming Shen Message-Id: <20010828191021.87D05F2C4F@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 28 Aug 2001 12:10:21 -0700 ]we have a multihop Label switch path, which is carrying the traffic. ] ]routerA---routerB----routerC----routerD ] ]the label switch path---> from A to D. ] ]IGP== ISIS ] ]there are also a number of disjoint paths between A and D. ] ]If we set the overload bit on C or B, how would router A know it should ]stop sending traffic over that Label switch path. ] I would think you may not want to stop sending traffic down this Label switched path. The overload bit here is used as a hint to say C or B's bgp has not yet converged, it is possible that the label switched path calculation does not pay attention to ISIS overload bit and still sets up the label switched path through B and C to D before BGP on B or C can converge. In this case, routers B and C knows how to switch the mpls packets regardless of BGP convergence.(in some cases, the forwarding and rsvp module are always up, so the label switched path is never down) But whether routerA can send traffic down this A->B->C->D lsp depends on implementation, configuration and topology of the network. In some implementation and configuration, as long as the tunnel destination is the bgp nexthop, it can always switch; Even if the IGP routes are tightly coupled with the label switched paths, as long as the IGP has some alternative paths for routerA to reach routerD, it may still forward packets into this label switched path. If the IGP was ospf, then the "overload bit" equivalent should not prevent routerA sending traffic down this label switched path regardless of the topology of network. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 29 05:12:11 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18623 for ; Wed, 29 Aug 2001 05:12:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA24032; Wed, 29 Aug 2001 02:21:35 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA24020 for ; Wed, 29 Aug 2001 02:20:27 -0700 (PDT) Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp1.cisco.com [144.254.108.68]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA09757; Wed, 29 Aug 2001 10:10:27 +0100 (BST) Message-Id: <4.3.2.7.2.20010829100705.019b4b48@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ken Larmer" From: mike shand Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents Cc: "Isis-Wg@Spider. Juniper. Net" , "Ken Larmer" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 29 Aug 2001 10:10:18 +0100 Ken, I'm confused. What do you mean by L1/L2 LSP? Do you mean the overload bit is set in BOTH L1 and L2? In which case other routers should NOT be seeing these reachable at L1 OR L2. Or do you mean that it is set in L1 only, and because the information is present in L2 LSPs from B (which do not have ovl set), the subnets appear reachable (correctly) at L2, but not at L1? Or do you mean something else entirely? Mike At 14:24 28/08/2001 -0400, Ken Larmer wrote: > All 4 IS routers (A,B,C,D) share a common area address (same L1 > Sub-Domain) >and are also part of the same L2 Domain. IS-B has a LSPDB overload condition >and advertises this in it's L1/L2 LSP by setting the LSPDB overload bit. The >other routers receive these LSPs and process them properly; they calculate >routes to directly attached destinations but do not use IS-B as a transient >IS. The problem is that an IP host connected to subnet 11.11.11.0 can still >reach subnet 10.10.10.0. This is made possible because IS-B is advertising, >in it's L2 LSP, the contents specified above in RFC-1195 Section 5.2. As a >consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable >via L2 routing, because they think IS-B has a direct connection to this >subnet. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Aug 29 09:22:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25652 for ; Wed, 29 Aug 2001 09:22:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA25055; Wed, 29 Aug 2001 06:32:35 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA25043 for ; Wed, 29 Aug 2001 06:31:29 -0700 (PDT) Received: (qmail 64350 invoked from network); 29 Aug 2001 13:21:30 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 29 Aug 2001 13:21:30 -0000 From: "Ken Larmer" To: "mike shand" Cc: "Isis-Wg@Spider. Juniper. Net" Subject: RE: [Isis-wg] L2 LSP IP Internal Reachability Information TLV contents Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.3.2.7.2.20010829100705.019b4b48@jaws.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 29 Aug 2001 09:23:43 -0400 Content-Transfer-Encoding: 7bit Hi Mike, Sorry, I should have made this a bit clearer. The OVL bit is being set in both the L1 and L2 LSPs originated by IS-B. But because the IS-B's L2 LSP contains all of the IP subnets within the L1 area (all IS routers are in the same area), there exists a route to subnet 10.10.10.0 via L2 from IS-C and IS-D. Say each link has a metric = 10. IS-B is advertising L2 reachability to IP subnet 10.10.10.0 with a metric = 20. IS-C and IS-D install an L2 IP route in their routing table to IP subnet 10.10.10.0 via IS-B. IS-B possesses an L1 IP route to IP subnet 10.10.10.0 via IS-A. So IS-B installs a L1 IP route to 10.10.10.0 in its IP routing table. Conversely, IS-A possesses a L2 IP route to IP subnet 11.11.11.0 via IS-B. IS-B possesses an L1 IP route to IP subnet 11.11.11.0 via IS-C... Consequently, we possess an IP route from IS-D (subnet 11.11.11.0) to IS-A (subnet 10.10.10.0), which uses the following path. Source = IS-D and Destination = IS-A. IS-D forwards the IP packet to IS-C via L1, IS-C forwards the IP packet to IS-B via L1 and then IS-B forwards the IP packet to IS-A via L1. IP Subnet (10.10.10.0) [A][B][C][D] IP subnet (11.11.11.0) ^ LSPDB Overload condition Mike, does the above scenario defeat the purpose of setting the LSPDB OVL bit? Cheers, Ken Larmer > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of mike shand > Sent: Wednesday, August 29, 2001 5:10 AM > To: Ken Larmer > Cc: Isis-Wg@Spider. Juniper. Net; Ken Larmer > Subject: Re: [Isis-wg] L2 LSP IP Internal Reachability Information TLV > contents > > > Ken, > I'm confused. What do you mean by L1/L2 LSP? Do you mean the > overload bit is set in BOTH L1 and L2? In which case other routers should > NOT be seeing these reachable at L1 OR L2. > > Or do you mean that it is set in L1 only, and because the information is > present in L2 LSPs from B (which do not have ovl set), the subnets appear > reachable (correctly) at L2, but not at L1? > > Or do you mean something else entirely? > > Mike > > At 14:24 28/08/2001 -0400, Ken Larmer wrote: > > All 4 IS routers (A,B,C,D) share a common area address (same L1 > > Sub-Domain) > >and are also part of the same L2 Domain. IS-B has a LSPDB > overload condition > >and advertises this in it's L1/L2 LSP by setting the LSPDB > overload bit. The > >other routers receive these LSPs and process them properly; they > calculate > >routes to directly attached destinations but do not use IS-B as > a transient > >IS. The problem is that an IP host connected to subnet > 11.11.11.0 can still > >reach subnet 10.10.10.0. This is made possible because IS-B is > advertising, > >in it's L2 LSP, the contents specified above in RFC-1195 Section > 5.2. As a > >consequence, IS-C and IS-D calculate IP subnet 10.10.10.0 to be reachable > >via L2 routing, because they think IS-B has a direct connection to this > >subnet. > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Aug 30 09:45:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16773 for ; Thu, 30 Aug 2001 09:45:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA30968; Thu, 30 Aug 2001 06:55:35 -0700 (PDT) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA30953 for ; Thu, 30 Aug 2001 06:54:14 -0700 (PDT) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by blush.juniper.net (8.11.2/8.11.2) with ESMTP id f7UDi8i78083 for ; Thu, 30 Aug 2001 06:44:08 -0700 (PDT) X-JNPR-Received-From: outside Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 30 Aug 2001 06:40:33 -0700 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29674 for ; Thu, 30 Aug 2001 09:41:00 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09581 for ; Thu, 30 Aug 2001 09:41:00 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Aug 2001 09:40:59 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5519EBA1@VIE-MSGUSR-01> From: "Odak, John" To: isis-wg@juniper.net Subject: RE: [Isis-wg] draft-ietf-isis-diff-te-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 30 Aug 2001 13:40:33.0218 (UTC) FILETIME=[57746220:01C13159] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 30 Aug 2001 09:40:57 -0400 All, In the subject draft, several items were left as TBD (sub-TLV codes), and one was left as an editor's note (repitition octet at start). Have these been resolved? Are there candidate resolutions? Thank you for any information. -- John Odak _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg