From isis-wg-admin@spider.juniper.net Sun Mar 3 14:16:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28283 for ; Sun, 3 Mar 2002 14:16:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g23J20L48487; Sun, 3 Mar 2002 11:02:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g23IxLL48458 for ; Sun, 3 Mar 2002 10:59:22 -0800 (PST) (envelope-from prz@redback.com) 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 g23J7HY34052 for ; Sun, 3 Mar 2002 11:07:17 -0800 (PST) X-JNPR-Received-From: outside Received: from mta7.pltn13.pbi.net ([64.164.98.8]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 10:57:56 -0800 Received: from redback.com ([63.200.50.188]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSE00EVNVEJUN@mta7.pltn13.pbi.net> for isis-wg@juniper.net; Sun, 03 Mar 2002 10:59:07 -0800 (PST) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3C825373.D3791744@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: 03 Mar 2002 18:57:56.0781 (UTC) FILETIME=[54B93DD0:01C1C2E5] Subject: [Isis-wg] last call on draft draft-ietf-isis-3way-05 ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 03 Mar 2002 08:46:43 -0800 Content-Transfer-Encoding: 7BIT We are starting last call on draft-ietf-isis-3way-05 (again, version was updated). The last call will end 3/19/02 thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sun Mar 3 14:28:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28492 for ; Sun, 3 Mar 2002 14:28:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g23JFlL48559; Sun, 3 Mar 2002 11:15:47 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g23IxML48463 for ; Sun, 3 Mar 2002 10:59:22 -0800 (PST) (envelope-from prz@redback.com) 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 g23J7HY34060 for ; Sun, 3 Mar 2002 11:07:17 -0800 (PST) X-JNPR-Received-From: outside Received: from mta7.pltn13.pbi.net ([64.164.98.8]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 11:02:55 -0800 Received: from redback.com ([63.200.50.188]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSE00EJZVMTUR@mta7.pltn13.pbi.net> for isis-wg@juniper.net; Sun, 03 Mar 2002 11:04:05 -0800 (PST) From: Tony Przygienda To: isis-wg@juniper.net Message-id: <3C82549D.E348115E@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: 03 Mar 2002 19:02:55.0218 (UTC) FILETIME=[069B1D20:01C1C2E6] Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 03 Mar 2002 08:51:42 -0800 Content-Transfer-Encoding: 7BIT We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call will end 3/19/02 thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 16:50:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01514 for ; Tue, 5 Mar 2002 16:50:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25LZRL63353; Tue, 5 Mar 2002 13:35:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 17:03:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02164 for ; Tue, 5 Mar 2002 17:03:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25LoQL63448; Tue, 5 Mar 2002 13:50:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 17:17:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02851 for ; Tue, 5 Mar 2002 17:17:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25M5QL63576; Tue, 5 Mar 2002 14:05:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 17:31:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03475 for ; Tue, 5 Mar 2002 17:31:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25MJQL63665; Tue, 5 Mar 2002 14:19:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 17:45:52 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04232 for ; Tue, 5 Mar 2002 17:45:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25MXQL63778; Tue, 5 Mar 2002 14:33:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 18:00:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04981 for ; Tue, 5 Mar 2002 18:00:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25MlQL63887; Tue, 5 Mar 2002 14:47:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 18:15:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05653 for ; Tue, 5 Mar 2002 18:15:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25N2QL63978; Tue, 5 Mar 2002 15:02:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 18:29:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06074 for ; Tue, 5 Mar 2002 18:29:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25NHQL64087; Tue, 5 Mar 2002 15:17:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 18:44:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06514 for ; Tue, 5 Mar 2002 18:44:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25NVQL64217; Tue, 5 Mar 2002 15:31:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 18:58:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06960 for ; Tue, 5 Mar 2002 18:58:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g25NjQL64313; Tue, 5 Mar 2002 15:45:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 19:13:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07321 for ; Tue, 5 Mar 2002 19:13:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2600RL64424; Tue, 5 Mar 2002 16:00:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 19:28:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07584 for ; Tue, 5 Mar 2002 19:28:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g260FQL64523; Tue, 5 Mar 2002 16:15:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 19:42:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07905 for ; Tue, 5 Mar 2002 19:42:16 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g260TQL64625; Tue, 5 Mar 2002 16:29:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 19:55:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08153 for ; Tue, 5 Mar 2002 19:55:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g260hQL64731; Tue, 5 Mar 2002 16:43:27 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 5 20:10:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08379 for ; Tue, 5 Mar 2002 20:10:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g260vSL64846; Tue, 5 Mar 2002 16:57:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g1LBCAL58901 for ; Thu, 21 Feb 2002 03:12:10 -0800 (PST) (envelope-from bhama.venugopal@wipro.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g1LBJ0P99830 for ; Thu, 21 Feb 2002 03:19:00 -0800 (PST) X-JNPR-Received-From: outside Received: from wiproecmx1.wipro.com ([164.164.31.5]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 03:17:58 -0800 Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g1LBHTP03570 for ; Thu, 21 Feb 2002 16:47:32 +0530 (IST) Received: from gdyalc107077 ([192.168.165.115]) by bhairavi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GRVRF300.FC6; Thu, 21 Feb 2002 16:48:39 +0530 Reply-To: From: "Bhama" To: Cc: "Anitha" Message-ID: <00ed01c1bac9$b561c180$73a5a8c0@gdyalc107077> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00EE_01C1BAF7.CF19FD80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000EAB90CCED501D511815D006067735981444B2E00 X-OriginalArrivalTime: 21 Feb 2002 11:17:59.0328 (UTC) FILETIME=[6B3A9A00:01C1BAC9] Subject: [Isis-wg] reg. ISO10589 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Feb 2002 16:50:03 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi! As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. This means they are basically a set of information base. Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... Thanks and Regards, Bhama & Anitha ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgMLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAgAVABAAMgAAAAQANgEB A5AGAMAGAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAADgAAAHJlZy4gSVNPMTA1ODkAAAACAXEAAQAAABYAAAABwbrJtMqDlEOd0LFCgIWu4hEPH9cc AAACAR0MAQAAAB8AAABTTVRQOkJIQU1BLlZFTlVHT1BBTEBXSVBSTy5DT00AAAsAAQ4AAAAAQAAG DgCwJ7PJusEBAgEKDgEAAAAYAAAAAAAAAOq5DM7VAdURgV0AYGdzWYHCgAAACwAfDgEAAAADAAYQ NxjjDAMABxD2AQAAHgAIEAEAAABlAAAASElBU1BFUlRIRUlTTzEwNTg5RE9DLFRIRURFRklOSVRJ T05GT1JDSVJDVUlUSVNUSEVTVUJTRVRPRkxPQ0FMUk9VVElOR0lORk9STUFUSU9OUEVSVElORU5U VE9BU0lOR0xFTAAAAAACAQkQAQAAAEoCAABGAgAASAMAAExaRnUNqQvzAwAKAHJjcGcxMjUWMgD4 C2BuDhAwMzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgNkIyCA7CW8OMDUCgAqBknYIkHdrC4Bk NAxgDmMAUAsDC7UgSGkhXwqiCoEBkRFgBCBwBJAggHRoZSBJU08PQAA1ODkgZG9jLo4sF2IBAQuA aXRpAiAGIAIQBcAnY2lyY7J1GRAnIAQAAzBjAEARF1NzdWIRISBvZqogCQBjB0AgA2B1GSD7DyAa QG4ZcQDAGSMXIRxBwwnwBUB0byBhGwAcUYZsF4AbtFNOUEEacosRUABwZBlkYWRqANDpCfBjeRo8 cAkRGTIbgdMcHxlBd2gN4GgdQwtxvwQgHfEXYglwANAQ8GIDEB0ZEHkbch4nHaBpZ2h7BuAFwEUF 8AWxF6AbcHavFzEeJxnFH2MuFkRUI7B/BCAHgAYiF2ElsArAF4Bi9mEN0QdAbCqhGwAbVBya1SsB ZSlVQSBWIBDwBCD+YgnhKgECMBkxCYAeEAQhynsZxSwmllx9FxALcOxyLBsAHgB3F4ArEBsQ3weA F1Ec8BdTLahEHPABoM8tAS4zF2EzsTIgHbEIgepzKVVDA5F5CGAXEB6ASTOidGUrYCB1BCB39m8F QB4gQxnUM0gD8DaR5wWgAjALcT9BH8EUoitx/yfBBpAlsQhwMaQFMBkyCXD+ZwsRHFIyvy0gPQEW RT1ZWynAAHBrBCAfslI7U3OaLBZEQhDwAMAgJhFgLxkBEPAWRBHhAEFwAAADABAQAAAAAAMAERAA AAAACwABgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADwEwAAHgAIgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsADIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwANgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAF4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAZgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeACiACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAp gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AKoAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALADKACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsANIAL IAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwA2gAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAA AAACAfgPAQAAABAAAADquQzO1QHVEYFdAGBnc1mBAgH6DwEAAAAQAAAA6rkMztUB1RGBXQBgZ3NZ gQIB+w8BAAAAZgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB +b+4AQCqADfZbgAAAEM6XFdJTkRPV1NcQXBwXE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0 AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwRUFCOTBDQ0VENTAxRDUxMTgx NUQwMDYwNjc3MzU5ODE0NDRCMkUwMAAAAAB3Vw== ------=_NextPart_000_00EE_01C1BAF7.CF19FD80 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPart_000_00EE_01C1BAF7.CF19FD80-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 6 10:16:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12326 for ; Wed, 6 Mar 2002 10:16:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g26F2ht69290; Wed, 6 Mar 2002 07:02:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g26EvGt69258 for ; Wed, 6 Mar 2002 06:57:16 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'bhama.venugopal@wipro.com'" Cc: "IS-IS-WG (E-mail)" Subject: RE: [Isis-wg] reg. ISO10589 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 6 Mar 2002 10:05:07 -0500 > From: Bhama [mailto:bhama.venugopal@wipro.com] > Sent: Thursday, February 21, 2002 6:20 AM > To: isis-wg@juniper.net > Cc: Anitha > Subject: [Isis-wg] reg. ISO10589 > > Hi! > As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. > This means they are basically a set of information base. > Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. > Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... > > Bhama & Anitha There is a MIB that describes the information an SNMP manager might expect to find. You will find a version of that at http://ietf.org/internet-drafts/draft-ietf-isis-wg-mib-07.txt What an implementation keeps is determined by what the implementor needs to store. Some of that information might lie in the ISIS system, and some might lie in an interface specific database. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Sat Mar 9 03:06:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06558 for ; Sat, 9 Mar 2002 03:06:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g297q1t86446; Fri, 8 Mar 2002 23:52:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g297plt86434 for ; Fri, 8 Mar 2002 23:51:47 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) 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 g2980Hx85999 for ; Sat, 9 Mar 2002 00:00:17 -0800 (PST) X-JNPR-Received-From: outside Received: from web11208.mail.yahoo.com ([216.136.131.190]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Mar 2002 23:57:55 -0800 Message-ID: <20020309075911.9876.qmail@web11208.mail.yahoo.com> Received: from [203.196.145.150] by web11208.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 23:59:11 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1413420458-1015660751=:9372" X-OriginalArrivalTime: 09 Mar 2002 07:57:55.0093 (UTC) FILETIME=[1EC1B450:01C1C740] Subject: [Isis-wg] Route Addition to different logical subnet Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 8 Mar 2002 23:59:11 -0800 (PST) --0-1413420458-1015660751=:9372 Content-Type: text/plain; charset=us-ascii Hi, In ISIS, Routers can establish adjacency independent of the logical subnets in which they are,if they share the same physical network. How can we add a route to the neighboring router's subnet [which is different] and what should the gateway be for such a route? For a destination for which the next hop is an adjacent router on another logical subnet, how can we add the route ? More specifically, what should be the gateway for such destinations ? Please help me, Regards. --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-1413420458-1015660751=:9372 Content-Type: text/html; charset=us-ascii
Hi,
 
In ISIS, Routers can establish adjacency independent of the logical subnets in which they are,
if they share the same physical network.
 
How can we add a route to the neighboring router's subnet [which is different] and
what should the gateway be for such a route?
 
For a destination for which the next hop is an adjacent router on another logical subnet,
how can we add the route ?
 
More specifically, what should be the gateway for such destinations ?
 
 
Please help me,
 
Regards.


Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! --0-1413420458-1015660751=:9372-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 14:55:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20991 for ; Mon, 11 Mar 2002 14:55:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BJcVt06238; Mon, 11 Mar 2002 11:38:31 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g247MML51837 for ; Sun, 3 Mar 2002 23:22:23 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) 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 g247UKY40838 for ; Sun, 3 Mar 2002 23:30:21 -0800 (PST) X-JNPR-Received-From: outside Received: from ghostrider.gredler.at ([193.83.223.228]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 23:27:11 -0800 Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id IAA30191; Mon, 4 Mar 2002 08:28:09 +0100 From: Hannes Gredler To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Message-ID: <20020304082809.A30187@juniper.net> References: <3C82549D.E348115E@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: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 X-OriginalArrivalTime: 04 Mar 2002 07:27:11.0484 (UTC) FILETIME=[FFD08BC0:01C1C34D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 08:28:09 +0100 On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 15:12:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21567 for ; Mon, 11 Mar 2002 15:12:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BJvSt06357; Mon, 11 Mar 2002 11:57:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g247MML51837 for ; Sun, 3 Mar 2002 23:22:23 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) 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 g247UKY40838 for ; Sun, 3 Mar 2002 23:30:21 -0800 (PST) X-JNPR-Received-From: outside Received: from ghostrider.gredler.at ([193.83.223.228]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 23:27:11 -0800 Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id IAA30191; Mon, 4 Mar 2002 08:28:09 +0100 From: Hannes Gredler To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Message-ID: <20020304082809.A30187@juniper.net> References: <3C82549D.E348115E@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: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 X-OriginalArrivalTime: 04 Mar 2002 07:27:11.0484 (UTC) FILETIME=[FFD08BC0:01C1C34D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 08:28:09 +0100 On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 15:29:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22169 for ; Mon, 11 Mar 2002 15:29:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BKEYt06463; Mon, 11 Mar 2002 12:14:34 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g247MML51837 for ; Sun, 3 Mar 2002 23:22:23 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) 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 g247UKY40838 for ; Sun, 3 Mar 2002 23:30:21 -0800 (PST) X-JNPR-Received-From: outside Received: from ghostrider.gredler.at ([193.83.223.228]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 23:27:11 -0800 Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id IAA30191; Mon, 4 Mar 2002 08:28:09 +0100 From: Hannes Gredler To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Message-ID: <20020304082809.A30187@juniper.net> References: <3C82549D.E348115E@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: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 X-OriginalArrivalTime: 04 Mar 2002 07:27:11.0484 (UTC) FILETIME=[FFD08BC0:01C1C34D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 08:28:09 +0100 On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 15:44:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23257 for ; Mon, 11 Mar 2002 15:44:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BKUSt06559; Mon, 11 Mar 2002 12:30:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g247MML51837 for ; Sun, 3 Mar 2002 23:22:23 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) 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 g247UKY40838 for ; Sun, 3 Mar 2002 23:30:21 -0800 (PST) X-JNPR-Received-From: outside Received: from ghostrider.gredler.at ([193.83.223.228]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 23:27:11 -0800 Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id IAA30191; Mon, 4 Mar 2002 08:28:09 +0100 From: Hannes Gredler To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Message-ID: <20020304082809.A30187@juniper.net> References: <3C82549D.E348115E@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: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 X-OriginalArrivalTime: 04 Mar 2002 07:27:11.0484 (UTC) FILETIME=[FFD08BC0:01C1C34D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 08:28:09 +0100 On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 16:01:53 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24369 for ; Mon, 11 Mar 2002 16:01:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BKkSt06656; Mon, 11 Mar 2002 12:46:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g247MML51837 for ; Sun, 3 Mar 2002 23:22:23 -0800 (PST) (envelope-from hannes@ghostrider.gredler.at) 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 g247UKY40838 for ; Sun, 3 Mar 2002 23:30:21 -0800 (PST) X-JNPR-Received-From: outside Received: from ghostrider.gredler.at ([193.83.223.228]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 3 Mar 2002 23:27:11 -0800 Received: (from hannes@localhost) by ghostrider.gredler.at (8.9.3/8.9.3) id IAA30191; Mon, 4 Mar 2002 08:28:09 +0100 From: Hannes Gredler To: Tony Przygienda Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Message-ID: <20020304082809.A30187@juniper.net> References: <3C82549D.E348115E@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: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 X-OriginalArrivalTime: 04 Mar 2002 07:27:11.0484 (UTC) FILETIME=[FFD08BC0:01C1C34D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 4 Mar 2002 08:28:09 +0100 On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 17:14:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27357 for ; Mon, 11 Mar 2002 17:14:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BLx1t07055; Mon, 11 Mar 2002 13:59:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BLvWt07040 for ; Mon, 11 Mar 2002 13:57:32 -0800 (PST) (envelope-from naiming@redback.com) 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 g2BM6Ix18047; Mon, 11 Mar 2002 14:06:18 -0800 (PST) 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); Mon, 11 Mar 2002 14:02:27 -0800 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 685651531D3; Mon, 11 Mar 2002 14:03:46 -0800 (PST) To: Hannes Gredler Cc: Tony Przygienda , isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-reply-to: Mail from Hannes Gredler dated Mon, 04 Mar 2002 08:28:09 +0100 <20020304082809.A30187@juniper.net> From: Naiming Shen Message-Id: <20020311220346.685651531D3@prattle.redback.com> X-OriginalArrivalTime: 11 Mar 2002 22:02:27.0890 (UTC) FILETIME=[6EEC6920:01C1C948] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 14:03:46 -0800 Hannes, good catch, i'll change that. thanks. ] On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: ] | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The las t call ] | will end 3/19/02 ] ] tony, ] ] there is still a typo in 8.5 ] ] --- ] ] 8.5. Reserved MT ID Values ] ] Certain MT topologies are assigned to serve pre-determined purposes: ] ] - MT ID #0: Equivalent to the ``standard'' topology. ] - MT ID #1: Reserved for In-Band Management Purposes. ] - MT ID #2: Reserved for IPv6 Routing Topology. ] - MT ID #3: Reserved for Multicast Routing Topology. ] - MT ID #4-#8190: Reserved for IETF consensus. ] - MT ID #8191: Reserved for development, experimental and ] proprietary features. ] ] --- ] ] in the TLV there are only 12 bits reserved for the ID purpose ] so i guess it should be ] ] ] --- ] - MT ID #4-#4094: Reserved for IETF consensus. ] - MT ID #4095: Reserved for development, experimental and ] proprietary features. ] ] --- ] ] /hannes _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 17:32:32 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27959 for ; Mon, 11 Mar 2002 17:32:32 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BMI7t07163; Mon, 11 Mar 2002 14:18:07 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2BM8Mt07106 for ; Mon, 11 Mar 2002 14:08:22 -0800 (PST) (envelope-from leontsinis@hotmail.com) 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 g2BMH8Y24347 for ; Mon, 11 Mar 2002 14:17:08 -0800 (PST) X-JNPR-Received-From: outside Received: from hotmail.com ([216.33.241.227]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Mar 2002 14:08:28 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Mar 2002 14:09:47 -0800 Received: from 213.16.149.152 by lw8fd.law8.hotmail.msn.com with HTTP; Mon, 11 Mar 2002 22:09:47 GMT X-Originating-IP: [213.16.149.152] From: "Nikos Leontsinis" To: isis-wg@juniper.net Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 11 Mar 2002 22:09:47.0525 (UTC) FILETIME=[74F76350:01C1C949] Subject: [Isis-wg] IS-IS metrics: in search for a sound way Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 22:09:47 +0000
ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined:

1.Default: Each link is given a metric value based on its throughput
2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay)
3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done)

4 Error metric.It measures the residual (ęáôÜëďéđď, őđüëďéđď) error probability of the asociated circuit (also unclear but makes sense as a concept).

If you look at the IS-IS  LSP format's analysis i.e. p.638 Doyle, Routing TCP/IP Volume1 you will see that IOS supports
 only the default metric (bit 4) Bits 5-7  which are delay, expense & error are not supported and they will always be zero.
This is a major IOS caveat as bandwidth alone is by no means sufficient to account for metric assignment.
However, looking at the LSP format is not the only way to reach the above conclusion.
These 3 factors would be brought into consideration on a discussion on how to tune isis metrics by someone
who was building his/her argumentation on pure operational experience. 
The main objective behind metric tuning is network performance improvement. Performance is an umbrella
which incorporates the configuration and measurement of distinct areas. It is not clear to me how the ietf engineers
calculate delay, expense and error as part of their (non Cisco supported) isis impl! ementation. What it is indubitable is that
availability, response time, accuracy and utilisation will be key indicators for the performance of a network and these are the
ones that should also be added as key decision parameters in the metric assignment process.

        In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't think there is one formula which can be used as a panacea. My feeling is that this is a context based approach. One can come to an agreement on what issues to consider but the
decision should be taken on the individual links rather than make it matter of correct application of a specific formula.
For a more detailed analysis on these 4 areas of performance: availability, response time, accuracy and utilisation see
Performance and Fault Management  Della Magiora, et al p.74-85.

Best,

Nikos Leontsinis

 
 
 

Join the world’s largest e-mail service with MSN Hotmail. Click Here
_______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 11 22:13:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04246 for ; Mon, 11 Mar 2002 22:13:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2C2wBt08570; Mon, 11 Mar 2002 18:58:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2C2aet08463 for ; Mon, 11 Mar 2002 18:36:41 -0800 (PST) (envelope-from azinin@nexsi.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2C2jSu23872; Mon, 11 Mar 2002 18:45:28 -0800 (PST) X-JNPR-Received-From: outside Received: from chrome.nexsi.com ([66.35.207.149]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Mar 2002 18:29:09 -0800 Received: from khonsu.sw.nexsi.com (unknown [192.168.104.126]) by chrome.nexsi.com (Postfix) with ESMTP id 984B7F029; Mon, 11 Mar 2002 18:29:30 -0800 (PST) From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <13891121285.20020311183010@nexsi.com> To: Naiming Shen Cc: Hannes Gredler , Tony Przygienda , isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <20020311220346.685651531D3@prattle.redback.com> References: <20020311220346.685651531D3@prattle.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Mar 2002 02:29:09.0140 (UTC) FILETIME=[B0696540:01C1C96D] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 18:30:10 -0800 Content-Transfer-Encoding: 7bit Naiming, Some editorial comments to save your time: - remove citations from the Abstract - put a standard boilerplate for MUST/MAY/SHOULD you're using. - Fix the "references" section. You need RFC and STD (if applicable) numbers there. See if you can split normative and informative refs. BTW, do we have interoperable implementations for this? -- Alex Zinin Monday, March 11, 2002, 2:03:46 PM, Naiming Shen wrote: > Hannes, > good catch, i'll change that. thanks. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 03:53:09 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12750 for ; Thu, 14 Mar 2002 03:53:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2E8aBt23913; Thu, 14 Mar 2002 00:36:11 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2C3Jdt08704 for ; Mon, 11 Mar 2002 19:19:39 -0800 (PST) (envelope-from naiming@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2C3SRx21990; Mon, 11 Mar 2002 19:28:27 -0800 (PST) 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); Mon, 11 Mar 2002 19:22:18 -0800 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 6E115F2C50; Mon, 11 Mar 2002 19:23:37 -0800 (PST) To: Alex Zinin Cc: Hannes Gredler , Tony Przygienda , isis-wg@juniper.net Subject: Re: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-reply-to: Mail from Alex Zinin dated Mon, 11 Mar 2002 18:30:10 PST <13891121285.20020311183010@nexsi.com> From: Naiming Shen Message-Id: <20020312032337.6E115F2C50@prattle.redback.com> X-OriginalArrivalTime: 12 Mar 2002 03:22:18.0639 (UTC) FILETIME=[1D8051F0:01C1C975] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 19:23:37 -0800 Alex, ] ] Naiming, ] ] Some editorial comments to save your time: ] - remove citations from the Abstract ] - put a standard boilerplate for MUST/MAY/SHOULD ] you're using. ] - Fix the "references" section. You need RFC and ] STD (if applicable) numbers there. See if you ] can split normative and informative refs. will do. ] ] BTW, do we have interoperable implementations for this? i'm only aware of multiple implementations for a while, but not sure if anyone has tested interoperability or not. thanks. ] ] -- ] Alex Zinin ] ] Monday, March 11, 2002, 2:03:46 PM, Naiming Shen wrote: ] ] ] > Hannes, ] ] > good catch, i'll change that. thanks. ] ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 04:55:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13786 for ; Thu, 14 Mar 2002 04:55:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2E9f4t24225; Thu, 14 Mar 2002 01:41:04 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2E9Vct24170 for ; Thu, 14 Mar 2002 01:31:38 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2E9eeu63139 for ; Thu, 14 Mar 2002 01:40:40 -0800 (PST) X-JNPR-Received-From: outside Received: from web11203.mail.yahoo.com ([216.136.131.185]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Mar 2002 01:34:42 -0800 Message-ID: <20020314093603.38235.qmail@web11203.mail.yahoo.com> Received: from [203.196.145.150] by web11203.mail.yahoo.com via HTTP; Thu, 14 Mar 2002 01:36:02 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-862532364-1016098562=:37888" X-OriginalArrivalTime: 14 Mar 2002 09:34:42.0640 (UTC) FILETIME=[7863CD00:01C1CB3B] Subject: [Isis-wg] Administratively setting overload bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 01:36:02 -0800 (PST) --0-862532364-1016098562=:37888 Content-Type: text/plain; charset=us-ascii Hi All, The variable isisSysSetOverload of table isisSysTable (ISIS MIB) can be used to set overload bit administrativly at each level. I am not clear, that if network manager sets this variable to indicate overload condition at a level then do we need to enter waiting state at that level,even if we have enough resources and perform all those actions listed in section 7.3.19 of ISO 10589 for that level. Please help me. Thanks in advance. --------------------------------- Do You Yahoo!? Yahoo! Sports - live college hoops coverage --0-862532364-1016098562=:37888 Content-Type: text/html; charset=us-ascii

Hi All,

            The variable isisSysSetOverload of table isisSysTable (ISIS MIB)

can be used to set overload bit administrativly at each level. I am not clear, that

if network manager sets this variable to indicate overload condition at a level then

do we need to enter waiting state at that level,even if we have enough resources

 and perform all those actions listed in

section 7.3.19 of ISO 10589 for that level.

Please help me. Thanks in advance.

 


Do You Yahoo!?
Yahoo! Sports - live college hoops coverage --0-862532364-1016098562=:37888-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:19:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10094 for ; Thu, 14 Mar 2002 22:19:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F37ot29333; Thu, 14 Mar 2002 19:07:50 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2C7CQt09878 for ; Mon, 11 Mar 2002 23:12:26 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2C7LEx24267 for ; Mon, 11 Mar 2002 23:21:14 -0800 (PST) X-JNPR-Received-From: outside Received: from web11202.mail.yahoo.com ([216.136.131.184]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Mar 2002 23:05:02 -0800 Message-ID: <20020312070621.9250.qmail@web11202.mail.yahoo.com> Received: from [203.196.145.150] by web11202.mail.yahoo.com via HTTP; Mon, 11 Mar 2002 23:06:21 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-26142839-1015916781=:8978" X-OriginalArrivalTime: 12 Mar 2002 07:05:02.0202 (UTC) FILETIME=[3ACE35A0:01C1C994] Subject: [Isis-wg] doubt regarding administratively setting overload bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 11 Mar 2002 23:06:21 -0800 (PST) --0-26142839-1015916781=:8978 Content-Type: text/plain; charset=us-ascii Hi All, The variable isisSysSetOverload of table isisSysTable (ISIS MIB) can be used to set overload bit administratively at each level. I am not clear, that if network manager sets this variable to indicate overload condition at a level then do we need to enter waiting state at that level , even if we have proper resources and perform all those actions listed in section 7.3.19 of ISO 10589 for that level. Please help me. Thanks in advance. --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-26142839-1015916781=:8978 Content-Type: text/html; charset=us-ascii

Hi All,

            The variable isisSysSetOverload of table isisSysTable (ISIS MIB)

can be used to set overload bit administratively at each level. I am not clear, that

if network manager sets this variable to indicate overload condition at a level then

do we need to enter waiting state at that level , even if we have proper resources 

and perform all those actions listed in

section 7.3.19 of ISO 10589 for that level.

Please help me. Thanks in advance.

 


Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! --0-26142839-1015916781=:8978-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:22:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10193 for ; Thu, 14 Mar 2002 22:22:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3B1t29390; Thu, 14 Mar 2002 19:11:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2CGRCt12928 for ; Tue, 12 Mar 2002 08:27:12 -0800 (PST) (envelope-from bneal@broadwing.com) 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 g2CGa3x31317 for ; Tue, 12 Mar 2002 08:36:04 -0800 (PST) X-JNPR-Received-From: outside Received: from ausmx1.ixc-comm.com ([216.140.58.174]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Mar 2002 08:32:01 -0800 Received: by ausmx1.ixc-comm.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 10:33:20 -0600 Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A598D@metexch3.ixc-comm.com> From: bneal@broadwing.com To: leontsinis@hotmail.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 12 Mar 2002 16:32:01.0640 (UTC) FILETIME=[6FF87E80:01C1C9E3] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 10:33:16 -0600 Although ISO 10589 defines four different metric fields, I believe the decision process still uses a single scalar metric because IS-IS combines the four fields by simple addition paragraph 7.2.2, note 13. It's up to the network operator to weight these fields according to his own requirements. Point is, you can accomplish pretty much the same thing with a single field--just define which link properties are important to you, weight them according to their relative importance, add up the values and the result is your combined metric, just like IS-IS would have done. +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:23:18 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10216 for ; Thu, 14 Mar 2002 22:23:18 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3CGt29444; Thu, 14 Mar 2002 19:12:16 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2CNgRt14805 for ; Tue, 12 Mar 2002 15:42:28 -0800 (PST) (envelope-from leontsinis@hotmail.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2CNpLx38657 for ; Tue, 12 Mar 2002 15:51:21 -0800 (PST) X-JNPR-Received-From: outside Received: from hotmail.com ([216.33.241.151]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Mar 2002 15:46:36 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Mar 2002 15:47:56 -0800 Received: from 213.16.154.4 by lw8fd.law8.hotmail.msn.com with HTTP; Tue, 12 Mar 2002 23:47:55 GMT X-Originating-IP: [213.16.154.4] From: "Nikos Leontsinis" To: bneal@broadwing.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 12 Mar 2002 23:47:56.0241 (UTC) FILETIME=[5553E410:01C1CA20] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 23:47:55 +0000
Although ISO 10589 defines four different metric fields, I believe the
decision process still uses a single scalar metric because IS-IS combines
the four fields by simple addition paragraph 7.2.2, note 13. It's up to the
network operator to weight these fields according to his own requirements.

No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent  than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics.

Point is, you can accomplish pretty much the same thing with a single

field--just define which link properties are important to you, weight them
according to their relative importance, add up the values and the result is
your combined metric, just like IS-IS would have done.
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++

Join the world’s largest e-mail service with MSN Hotmail. Click Here
_______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:24:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10229 for ; Thu, 14 Mar 2002 22:24:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3DVt29485; Thu, 14 Mar 2002 19:13:31 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2D0jjt15092 for ; Tue, 12 Mar 2002 16:45:45 -0800 (PST) (envelope-from bneal@broadwing.com) 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 g2D0scY41682 for ; Tue, 12 Mar 2002 16:54:38 -0800 (PST) X-JNPR-Received-From: outside Received: from ausmx1.ixc-comm.com ([216.140.58.174]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Mar 2002 16:52:13 -0800 Received: by ausmx1.ixc-comm.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 18:53:32 -0600 Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A5997@metexch3.ixc-comm.com> From: bneal@broadwing.com To: leontsinis@hotmail.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CA29.7967F310" X-OriginalArrivalTime: 13 Mar 2002 00:52:13.0234 (UTC) FILETIME=[50465120:01C1CA29] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 12 Mar 2002 18:53:22 -0600 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CA29.7967F310 Content-Type: text/plain; charset="iso-8859-1" My point is that even if a platform lets you set all four metrics, the SPF computation, as defined by 10589, just adds them up and uses the sum as a single metric. I can only assume that the reason they are broken out separately is for conceptual convenience. (?) A human being can do this just as easily when a platform only supports a single metric, or when using the new-style TLVs that only define one metric. The only real difference is that the actual values of the individual link properties are not reflected in the router's configuration state. As far as a generalized metric-selection schema, I don't think there really is one. How I, as a network operator, assign link metrics will depend on what link properties are interesting to me in my particular situation. For instance, if I can provision bandwidth quickly and have sufficient confidence in my trending and planning efforts, bandwidth isn't interesting to me as an IGP decision input. Delay might be, though, if I have a network of large geographic scope. If I run a regional or metropolitan network, my requirements may be quite different and I would define my metrics accordingly. -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Tuesday, March 12, 2002 5:48 PM To: Neal, Brad (Broadwing); isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Although ISO 10589 defines four different metric fields, I believe the decision process still uses a single scalar metric because IS-IS combines the four fields by simple addition paragraph 7.2.2, note 13. It's up to the network operator to weight these fields according to his own requirements. No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics. Point is, you can accomplish pretty much the same thing with a single field--just define which link properties are important to you, weight them according to their relative importance, add up the values and the result is your combined metric, just like IS-IS would have done. +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ _____ Join the world's largest e-mail service with MSN Hotmail. Click Here +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ ------_=_NextPart_001_01C1CA29.7967F310 Content-Type: text/html; charset="iso-8859-1"
My point is that even if a platform lets you set all four metrics, the SPF computation, as defined by 10589, just adds them up and uses the sum as a single metric. I can only assume that the reason they are broken out separately is for conceptual convenience. (?)
 
A human being can do this just as easily when a platform only supports a single metric, or when using the new-style TLVs that only define one metric.  The only real difference is that the actual values of the individual link properties are not reflected in the router's configuration state.
 
As far as a generalized metric-selection schema, I don't think there really is one.  How I, as a network operator, assign link metrics will depend on what link properties are interesting to me in my particular situation.  For instance, if I can provision bandwidth quickly and have sufficient confidence in my trending and planning efforts, bandwidth isn't interesting to me as an IGP decision input.  Delay might be, though, if I have a network of large geographic scope.  If I run a regional or metropolitan network, my requirements may be quite different and I would define my metrics accordingly. 
 

 -----Original Message-----
From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]
Sent: Tuesday, March 12, 2002 5:48 PM
To: Neal, Brad (Broadwing); isis-wg@juniper.net
Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way

Although ISO 10589 defines four different metric fields, I believe the
decision process still uses a single scalar metric because IS-IS combines
the four fields by simple addition paragraph 7.2.2, note 13. It's up to the
network operator to weight these fields according to his own requirements.

No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent  than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics.

Point is, you can accomplish pretty much the same thing with a single

field--just define which link properties are important to you, weight them
according to their relative importance, add up the values and the result is
your combined metric, just like IS-IS would have done.
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++

Join the world's largest e-mail service with MSN Hotmail. Click Here

+++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++

------_=_NextPart_001_01C1CA29.7967F310-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:25:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10261 for ; Thu, 14 Mar 2002 22:25:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3Ejt29530; Thu, 14 Mar 2002 19:14:45 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2D6Xbt16555 for ; Tue, 12 Mar 2002 22:33:37 -0800 (PST) (envelope-from leontsinis@hotmail.com) 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 g2D6gWx43006 for ; Tue, 12 Mar 2002 22:42:32 -0800 (PST) X-JNPR-Received-From: outside Received: from hotmail.com ([216.33.241.50]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Mar 2002 22:33:32 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Mar 2002 22:34:52 -0800 Received: from 213.16.150.47 by lw8fd.law8.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 06:34:52 GMT X-Originating-IP: [213.16.150.47] From: "Nikos Leontsinis" To: bneal@broadwing.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 13 Mar 2002 06:34:52.0917 (UTC) FILETIME=[2ECCFA50:01C1CA59] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 06:34:52 +0000

There must be some documentation about the metric assignment process we just don't know it. This is a topic for a book it should be written for the 3 main routing protocols.

Best Regards,
 Nikos Leontsinis
 
From: bneal@broadwing.com
To: leontsinis@hotmail.com, isis-wg@juniper.net
Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way
Date: Tue, 12 Mar 2002 18:53:22 -0600
MIME-Version: 1.0
Received: from [216.140.57.101] by hotmail.com (3.2) with ESMTP id MHotMailBE57EE23006F4004374ED88C396555F60; Tue, 12 Mar 2002 16:53:56 -0800
Received: by ausmx1.ixc-comm.com with Internet Mail Service (5.5.2653.19)id ; Tue, 12 Mar 2002 18:53:32 -0600
From bneal@broadwing.com Tue, 12 Mar 2002 16:55:15 -0800
Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A5997@metexch3.ixc-comm.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
My point is that even if a platform lets you set all four metrics, the SPF
computation, as defined by 10589, just adds them up and uses the sum as a
single metric. I can only assume that the reason they are broken out
separately is for conceptual convenience. (?)
A human being can do this just as easily when a platform only supports a
single metric, or when using the new-style TLVs that only define one metric.
The only real difference is that the actual values of the individual link
properties are not reflected in the router's configuration state.
As far as a generalized metric-selection schema, I don't think there really
is one. How I, as a network operator, assign link metrics will depend on
what link properties are interesting to me in my particular situation. For
instance, if I can provision bandwidth quickly and have sufficient
confidence in my trending and planning efforts, bandwidth isn't interesting
to me as an IGP decision input. Delay might be, though, if I have a network
of large geographic scope. If I run a regional or metropolitan network, my
requirements may be quite different and I would define my metrics
accordingly.
-----Original Message-----
From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]
Sent: Tuesday, March 12, 2002 5:48 PM
To: Neal, Brad (Broadwing); isis-wg@juniper.net
Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way
Although ISO 10589 defines four different metric fields, I believe the
decision process still uses a single scalar metric because IS-IS combines
the four fields by simple addition paragraph 7.2.2, note 13. It's up to the
network operator to weight these fields according to his own requirements.
No the network operator can only ammend the default cisco metric which is
bandwith. The remaining metrics are not supported hence cannot be used what
they rather do is to give a hint to the network administrator what to bear
in mind when designing his/her network. I was looking for something more
coherent than that as I think metric assinment is by far the most
challenging task for the network designer since Cisco together with the
remaining implemeters are fairly inefficient in this direction. I am looking
for a sound way to measure metrics.
Point is, you can accomplish pretty much the same thing with a single
field--just define which link properties are important to you, weight them
according to their relative importance, add up the values and the result is
your combined metric, just like IS-IS would have done.
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++
_____
Join the world's largest e-mail service with MSN Hotmail. Click
Here
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++

Send and receive Hotmail on your mobile device: Click Here
_______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:26:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10345 for ; Thu, 14 Mar 2002 22:26:49 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3Fxt29569; Thu, 14 Mar 2002 19:15:59 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2D9DJt17235 for ; Wed, 13 Mar 2002 01:13:19 -0800 (PST) (envelope-from Eduard.Metz@kpnqwest.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2D9LYu44728 for ; Wed, 13 Mar 2002 01:22:14 -0800 (PST) X-JNPR-Received-From: outside Received: from W2KEXGSWP02.kpnqwest.com ([193.242.92.8]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Mar 2002 01:11:08 -0800 Received: from ntexghub01.kpnqwest.com (unverified) by W2KEXGSWP02.kpnqwest.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 10:12:23 +0100 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 10:12:23 +0100 Message-ID: <1E810ACBCC29D51185DF00508B66CCEED02442@ntexghfd02> From: "Metz, Eduard" To: "'Nikos Leontsinis'" , isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CA6E.FF507200" X-OriginalArrivalTime: 13 Mar 2002 09:11:08.0858 (UTC) FILETIME=[034C09A0:01C1CA6F] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 10:11:02 +0100 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CA6E.FF507200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AFAIK, the default metric is more or less 'dimensionless' in current implementations, and therefor not derived from interface bandwidth = directly. So you can put any value in there (based on any formula you wish). =20 In general something like: long, narrow pipes =3D> large metric, and = short, fat pipes =3D> small metric tends to work. Use the math of your choice = to get from one end to the other. =20 cheers, Eduard -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Monday, 11 March, 2002 23:10 To: isis-wg@juniper.net Subject: [Isis-wg] IS-IS metrics: in search for a sound way ISO 10589 states in 7.2.2. that the following 4 isis metrics are = defined: 1.Default: Each link is given a metric value based on its throughput=20 2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay) 3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done)=20 4 Error metric.It measures the residual (=EA=E1=F4=DC=EB=EF=E9=F0=EF, = =F5=F0=FC=EB=EF=E9=F0=EF) error probability of the asociated circuit (also unclear but makes sense as a concept).=20 If you look at the IS-IS LSP format's analysis i.e. p.638 Doyle, = Routing TCP/IP Volume1 you will see that IOS supports only the default metric (bit 4) Bits 5-7 which are delay, expense & = error are not supported and they will always be zero. This is a major IOS caveat as bandwidth alone is by no means sufficient = to account for metric assignment. However, looking at the LSP format is not the only way to reach the = above conclusion. These 3 factors would be brought into consideration on a discussion on = how to tune isis metrics by someone who was building his/her argumentation on pure operational experience.=20 The main objective behind metric tuning is network performance = improvement. Performance is an umbrella which incorporates the configuration and measurement of distinct areas. = It is not clear to me how the ietf engineers calculate delay, expense and error as part of their (non Cisco = supported) isis impl! ementation. What it is indubitable is that availability, response time, accuracy and utilisation will be key = indicators for the performance of a network and these are the ones that should also be added as key decision parameters in the metric assignment process. In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't = think there is one formula which can be used as a panacea. My feeling is that = this is a context based approach. One can come to an agreement on what = issues to consider but the decision should be taken on the individual links rather than make it = matter of correct application of a specific formula. For a more detailed analysis on these 4 areas of performance: = availability, response time, accuracy and utilisation see Performance and Fault Management Della Magiora, et al p.74-85.=20 Best, Nikos Leontsinis =20 =20 =20 _____ =20 Join the world's largest e-mail service with MSN Hotmail. Click Here _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1CA6E.FF507200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
AFAIK,=20 the default metric is more or less 'dimensionless' in current = implementations,=20 and therefor not derived from interface bandwidth directly. So you can = put any=20 value in there (based on any formula you wish).
 
In=20 general something like: long, narrow pipes =3D> large metric, and = short, fat=20 pipes =3D> small metric tends to work. Use the math of your choice = to get from=20 one end to the other.
 
cheers,
    Eduard
-----Original Message-----
From: Nikos Leontsinis=20 [mailto:leontsinis@hotmail.com]
Sent: Monday, 11 March, = 2002=20 23:10
To: isis-wg@juniper.net
Subject: [Isis-wg] = IS-IS=20 metrics: in search for a sound way

ISO 10589 states in 7.2.2. that the following 4 isis = metrics=20 are defined:

1.Default: Each link is given a metric value = based on=20 its throughput
2.Delay metric . It measures the transit = delay of the=20 circuit. (pretty common-sensical higher value longer delay)
3. = Expense=20 metric. It measures the monetary cost of the network's = utilsation-higher value=20 larger expense-.(very unclear to me how this is done)=20

4 Error metric.It measures the residual = (=EA=E1=F4=DC=EB=EF=E9=F0=EF, =F5=F0=FC=EB=EF=E9=F0=EF) error=20 probability of the asociated circuit (also unclear but makes sense as = a=20 concept).

If you look at the IS-IS  LSP format's analysis i.e. p.638 = Doyle,=20 Routing TCP/IP Volume1 you will see that IOS = supports
 only the=20 default metric (bit 4) Bits 5-7  which are delay, expense & = error are=20 not supported and they will always be zero.
This is a = major IOS caveat=20 as bandwidth alone is by no means sufficient to account for metric=20 assignment.
However, looking at the LSP format is not the only way = to reach=20 the above conclusion.
These 3 factors would be brought into = consideration=20 on a discussion on how to tune isis metrics by someone
who=20 was building his/her argumentation on pure operational=20 experience. 
The main objective behind metric tuning is = network=20 performance improvement. Performance is an umbrella
which = incorporates the=20 configuration and measurement of distinct areas. It is not clear to = me how the=20 ietf engineers
calculate delay, expense and error as part of their = (non=20 Cisco supported) isis impl! ementation. What it is indubitable = is=20 that
availability, response time, accuracy and utilisation will be = key=20 indicators for the performance of a network and these are = the
ones=20 that should also be added as key decision parameters in the metric = assignment=20 process.

        In conclusion, = I am looking=20 for a good way to measeure metrics either based on = bandwidth=20 or geographical distance eventhough I don't think there is = one=20 formula which can be used as a panacea. My feeling is that this = is a=20 context based approach. One can come to an agreement on what = issues to=20 consider but the
decision should be taken on the individual links = rather=20 than make it matter of correct application of a specific = formula.
For a=20 more detailed analysis on these 4 areas of performance: availability, = response=20 time, accuracy and utilisation see
Performance=20 and Fault Management  Della Magiora, et al p.74-85. =

Best,

Nikos = Leontsinis

 
 
 

Join the world's largest e-mail service with MSN Hotmail. Click=20 Here
_______________________________________________ Isis-wg = mailing=20 list - Isis-wg@spider.juniper.net=20 = http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1CA6E.FF507200-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:28:17 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10399 for ; Thu, 14 Mar 2002 22:28:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3HDt29600; Thu, 14 Mar 2002 19:17:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2DIu0t20159 for ; Wed, 13 Mar 2002 10:56:00 -0800 (PST) (envelope-from svemulap@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2DJ4wu51899 for ; Wed, 13 Mar 2002 11:04:58 -0800 (PST) X-JNPR-Received-From: outside Received: from ce-nfs-1.cisco.com ([171.68.227.69]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Mar 2002 11:01:45 -0800 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.102.160]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA25756; Wed, 13 Mar 2002 11:03:05 -0800 (PST) From: Shankar Vemulapalli To: isis-wg@juniper.net, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 13 Mar 2002 19:01:45.0171 (UTC) FILETIME=[84FC4A30:01C1CAC1] Subject: [Isis-wg] draft-ietf-isis-transient-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 13 Mar 2002 11:02:16 -0800 (PST) Hi Danny - Everything looks really good in the document. Just a couple of suggestions -[from readability perspective] In the section 4 under "Discussion" " Though, because RtrB has yet to establish and synchronization it's BGP neighbor relationship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. " is little verbose... may be it is good to break it up into two sentences. Also, there are too many 'and's In the same section 4 under "Discussion" - " If RtrB were to temporarily set it's LSP Overload bit while synchroniz ing BGP tables with it's neighbors, RtrA would continue to use the work ing RtrA->RtrC->RtrD path, and the LSP should only be used to obtain reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). " when talking about the "locally connected networks" - include a line saying that it is the Router-B's connected interfaces - so that it brings clarity. Thank you, /Shankar _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:29:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10411 for ; Thu, 14 Mar 2002 22:29:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3IVt29680; Thu, 14 Mar 2002 19:18:31 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2EAMbt24424 for ; Thu, 14 Mar 2002 02:22:37 -0800 (PST) (envelope-from mshand@cisco.com) 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 g2EAVdx67930 for ; Thu, 14 Mar 2002 02:31:39 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Mar 2002 02:30:06 -0800 Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp16.cisco.com [144.254.108.83]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA15173; Thu, 14 Mar 2002 10:31:24 GMT Message-Id: <4.3.2.7.2.20020314103058.03387638@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Aravind Ravikumar From: mike shand Subject: Re: [Isis-wg] Administratively setting overload bit Cc: isis-wg@juniper.net In-Reply-To: <20020314093603.38235.qmail@web11203.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-OriginalArrivalTime: 14 Mar 2002 10:30:06.0328 (UTC) FILETIME=[35765780:01C1CB43] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:31:21 +0000 At 01:36 14/03/2002 -0800, Aravind Ravikumar wrote:

Hi All,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

            The variable isisSysSetOverload of table isisSysTable (ISIS MIB)

can be used to set overload bit administrativly at each level. I am not clear, that

if network manager sets this variable to indicate overload condition at a level then

do we need to enter waiting state at that level,even if we have enough resources

 and perform all those actions listed in

section 7.3.19 of ISO 10589 for that level.

No.
        Mike


Please help me. Thanks in advance.

 



Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
_______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:30:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10615 for ; Thu, 14 Mar 2002 22:30:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3Jit29706; Thu, 14 Mar 2002 19:19:44 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2EEx3t26060 for ; Thu, 14 Mar 2002 06:59:03 -0800 (PST) (envelope-from jparker@axiowave.com) 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 g2EF86x71602 for ; Thu, 14 Mar 2002 07:08:06 -0800 (PST) X-JNPR-Received-From: outside Received: from bridge.axiowave.com ([64.115.125.242]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Mar 2002 07:05:09 -0800 Message-ID: From: Jeff Parker To: "'Aravind Ravikumar'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Administratively setting overload bit MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 14 Mar 2002 15:05:09.0453 (UTC) FILETIME=[A2175FD0:01C1CB69] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 10:06:25 -0500 You may want to take a look at http://ietf.org/internet-drafts/draft-ietf-isis-transient-02.txt to see the kind of devious mindset^H^H^H^H^H^H^H^H^H^H ways people might use this functionality. Briefly, there is a bit in the LSPs we generate that tells the world to route around us, when possible. This bit has been overloaded to use the meaning in other contexts than "I'm low on memory". It is really an admission that there are many resources that we may need. I have distinguished "wait" from "on" because there is a system event (timer firing, finished importing selected external routes from BGP) that will move the variable from "wait" to "off". - jeff parker - axiowave networks -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Thursday, March 14, 2002 4:36 AM To: isis-wg@juniper.net Subject: [Isis-wg] Administratively setting overload bit Hi All, The variable isisSysSetOverload of table isisSysTable (ISIS MIB) can be used to set overload bit administrativly at each level. I am not clear, that if network manager sets this variable to indicate overload condition at a level then do we need to enter waiting state at that level,even if we have enough resources and perform all those actions listed in section 7.3.19 of ISO 10589 for that level. Please help me. Thanks in advance. Do You Yahoo!? Yahoo! Sports - live college hoops coverage _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:31:43 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11177 for ; Thu, 14 Mar 2002 22:31:42 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3Kxt29739; Thu, 14 Mar 2002 19:20:59 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from coltrane.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2EHB0t26627 for ; Thu, 14 Mar 2002 09:11:00 -0800 (PST) (envelope-from JRB@dataconnection.com) Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2655.55) id ; Thu, 14 Mar 2002 17:19:51 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70348F0D4@duke.datcon.co.uk> From: Jon Berger To: "Isis-Wg (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] draft-ietf-isis-wg-multi-topolgy-02 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 17:19:51 -0000 Could someone explain to me what the assignment of MT ID#2 to IPv6 Routing Topology means? Is #2 the IPv6 equivalent of #0? If so, why can't we just use #0? If not, what does it represent? Jon _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:32:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11487 for ; Thu, 14 Mar 2002 22:32:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3MDt29771; Thu, 14 Mar 2002 19:22:13 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from coltrane.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2EI1ot26850 for ; Thu, 14 Mar 2002 10:01:50 -0800 (PST) (envelope-from JRB@dataconnection.com) Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2655.55) id ; Thu, 14 Mar 2002 18:10:43 -0000 Message-ID: <37701240971DD31193970000F6CCB9F70348F0DE@duke.datcon.co.uk> From: Jon Berger To: isis-wg@spider.juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] draft-ietf-isis-3way-05 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 18:10:45 -0000 Section 3.1 says "Any system that supports this mechanism MUST include Adjacency Three-Way State field in this option. The other fields in this option should be included as explained below in section 3.2." Which implies that it is possible to leave out the Extended Local Circuit ID. However my reading of the rest of the draft is that this is not an option. Jon _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:34:14 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11510 for ; Thu, 14 Mar 2002 22:34:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3NVt29847; Thu, 14 Mar 2002 19:23:31 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by external.juniper.net (8.11.6/8.11.6) with SMTP id g2F0VZt28549 for ; Thu, 14 Mar 2002 16:31:35 -0800 (PST) (envelope-from qinzhijian@yahoo.com) Received: from qinzhijian (AUTH login) at unknown (HELO training4) (qinzhijian@12.44.184.121) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Mar 2002 00:40:41 -0000 Message-ID: <000501c1cbba$8c6995d0$e404a8c0@hq.uniant.com> From: "zhijian qin" To: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Subject: [Isis-wg] Partition Designated L2 IS Election Problem Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 16:44:21 -0800 Content-Transfer-Encoding: 7bit Hi, I am a new guy on ISIS. When I was testing the Partition Repair Option, I create 2 areas, the first area has 6 routers while the second area has 2 routers. Area Addresses: Area1 aa01 Area2 aa02 NSAPs: R1 aa01000000000001 R2 aa01000000000002 R3 aa01000000000003 R4 aa01000000000004 R5 aa01000000000005 R6 aa01000000000006 R7 aa02000000000007 R8 aa02000000000008 Network Topology: _____ _____ | | | | | R7 | -----------------------------------------------------------| R8 | |_____| |_____| | | | | __|___ __|___ | | | | | R3 | | R4 | |_____| |_____| / \ / \ / \ / \ / \ / \ __|___ __|___ __|___ __|___ | | | | | | | | | R1 |-----| R2 |-----------------------------------------------| R6 |------| R5 | |_____| |_____| |_____| |_____| (All links are point-to-point links). I brought up all routers as L1L2 IS with partion repair capability (I am not sure if I can do that). Then I cut the connection between R2 and R6, R1/R2/R3 became a partition of area1 and R4/R5/R6 became another partion. Because every router in area1 can reach area2 directly or indirectly, every router in area1 claims itself as attached. So based the "Election of partition designated level 2 IS" (ISO10589 7.2.10.2), the Partition designated IS for the partition is R1 which has the lowest ID, while the the partion designated IS for the second partion is R4. R1 and R4 treat each other as a virtual adjacency. Each Non-Partition-Designated Routers (R2/R3/R5/R6) use the partition designated router as the next hop when they want to reach the routers in another partiton. The problem is R1, which is the partition designated router of the first partion, use the R3 as the next hop for destination R4, then I got a route loop, when R2 wants to talk to R4, R2 selects R1 as the next hop, then R3, then R1 again, then R3 again,........... i am dead. I did go though the ISO 10589 couple of times for help without any luck, but I still don't believe the protocol itself has something wrong, so could any experts out there can tell me what is wrong with my test envirionment or the software stack I am using might be the bad guy? Thanks a lot in advance, Jackie Qin _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 22:34:30 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11525 for ; Thu, 14 Mar 2002 22:34:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F3NSt29819; Thu, 14 Mar 2002 19:23:28 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2EJ39t27129 for ; Thu, 14 Mar 2002 11:03:10 -0800 (PST) (envelope-from Ravindra.Sunkad@vivacenetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2EJCEx78309 for ; Thu, 14 Mar 2002 11:12:14 -0800 (PST) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Mar 2002 11:09:12 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CB8B.F0EC2DD9" Message-ID: Thread-Topic: Extended IP Reachability question Thread-Index: AcHLjI05pA0iyNNRT3+F0cXgvG13rQ== From: "Ravindra Sunkad" To: X-OriginalArrivalTime: 14 Mar 2002 19:09:12.0327 (UTC) FILETIME=[B9ECA170:01C1CB8B] Subject: [Isis-wg] Extended IP Reachability question Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 11:10:44 -0800 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CB8B.F0EC2DD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In the following threads there is some talk about defining a sub-tlv for the Extended IP Reachability TLV that could be used to differentiate external route advertisements from internal route advertisements. Has any work been done on this front? =20 http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 =20 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt=20 =20 Thanks, Ravi ------_=_NextPart_001_01C1CB8B.F0EC2DD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the following = threads there is some talk about defining a sub-tlv for the Extended IP = Reachability TLV that could be used to differentiate external route advertisements from = internal route advertisements. Has any work been done on this = front?

 

= http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31

 

[Isis-wg] IS-IS = Extensions for Traffic Engineering

[Isis-wg] draft-ietf-isis-traffic-01.txt

 

Thanks,

Ravi

=00 ------_=_NextPart_001_01C1CB8B.F0EC2DD9-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 23:26:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12295 for ; Thu, 14 Mar 2002 23:26:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F4F1t30357; Thu, 14 Mar 2002 20:15:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F4Eft30342 for ; Thu, 14 Mar 2002 20:14:41 -0800 (PST) (envelope-from cmartin@gnilink.net) 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 g2F4Nmx91008 for ; Thu, 14 Mar 2002 20:23:48 -0800 (PST) X-JNPR-Received-From: outside Received: from entmail.gnilink.net ([199.45.47.10]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Mar 2002 20:21:04 -0800 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 23:22:26 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2C67@entmail.gnilink.com> From: "Martin, Christian" To: "'Nikos Leontsinis'" , bneal@broadwing.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Mar 2002 04:21:04.0671 (UTC) FILETIME=[D26B5AF0:01C1CBD8] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 23:22:26 -0500 Nikos, There is no "documentation", per se. However, the Operations Research folks have been studying these types of problems for 50 years. They vary in complexity, from a 3-node single metric IP network to a worldwide dispatching system such as that employed by FedEx. Network optimization problems are HARD at a large scale. In fact, some linear programming models are so difficult to compute, that they cannot be solved using today's computers. An example would be finding the fastest way from one street corner to another in Manhattan given known variables like signal frequency, speed limits, number of lanes, and average traffic patterns. The optimal solution is not solvable. But, approximations to the optimal solution are. I believe Brad is trying to convey that there is no simple rule of thumb. Your needs may be different from mine. The tools and methods are the same, however. If you need a quick fix that takes lots into consideration, you can use EIGRPs method as a starting point. As you can infer, the goal of EIGRP is to optimize a path given constraints. Usually, IP networks AIM to minimize delay and maximize bandwidth. If you need some help working this out, a colleague and I have derived a formula that works well for IS-IS/OSPF costing that aims to minimze the delay to transmit one 1500 byte packet. If you need to minimize financial cost, then it gets tougher. If you are interested, try www.citeseer.org and search for things like qos routing, link costs, etc. You will likely find more information than you'll ever need! For more information, try "Network Optimization" by Bertsekas and any reasonable text on Operations Research. Regards, chris -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Wednesday, March 13, 2002 1:35 AM To: bneal@broadwing.com; isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way There must be some documentation about the metric assignment process we just don't know it. This is a topic for a book it should be written for the 3 main routing protocols. Best Regards, Nikos Leontsinis From: bneal@broadwing.com To: leontsinis@hotmail.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Date: Tue, 12 Mar 2002 18:53:22 -0600 MIME-Version: 1.0 Received: from [216.140.57.101] by hotmail.com (3.2) with ESMTP id MHotMailBE57EE23006F4004374ED88C396555F60; Tue, 12 Mar 2002 16:53:56 -0800 Received: by ausmx1.ixc-comm.com with Internet Mail Service (5.5.2653.19)id ; Tue, 12 Mar 2002 18:53:32 -0600 From bneal@broadwing.com Tue, 12 Mar 2002 16:55:15 -0800 Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A5997@metexch3.ixc-comm.com> X-Mailer: Internet Mail Service (5.5.2653.19) My point is that even if a platform lets you set all four metrics, the SPF computation, as defined by 10589, just adds them up and uses the sum as a single metric. I can only assume that the reason they are broken out separately is for conceptual convenience. (?) A human being can do this just as easily when a platform only supports a single metric, or when using the new-style TLVs that only define one metric. The only real difference is that the actual values of the individual link properties are not reflected in the router's configuration state. As far as a generalized metric-selection schema, I don't think there really is one. How I, as a network operator, assign link metrics will depend on what link properties are interesting to me in my particular situation. For instance, if I can provision bandwidth quickly and have sufficient confidence in my trending and planning efforts, bandwidth isn't interesting to me as an IGP decision input. Delay might be, though, if I have a network of large geographic scope. If I run a regional or metropolitan network, my requirements may be quite different and I would define my metrics accordingly. -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Tuesday, March 12, 2002 5:48 PM To: Neal, Brad (Broadwing); isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Although ISO 10589 defines four different metric fields, I believe the decision process still uses a single scalar metric because IS-IS combines the four fields by simple addition paragraph 7.2.2, note 13. It's up to the network operator to weight these fields according to his own requirements. No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics. Point is, you can accomplish pretty much the same thing with a single field--just define which link properties are important to you, weight them according to their relative importance, add up the values and the result is your combined metric, just like IS-IS would have done. +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ _____ Join the world's largest e-mail service with MSN Hotmail. Click Here +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ Send and receive Hotmail on your mobile device: Click Here _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 14 23:55:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13105 for ; Thu, 14 Mar 2002 23:55:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F4j1t30545; Thu, 14 Mar 2002 20:45:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F4iOt30530 for ; Thu, 14 Mar 2002 20:44:24 -0800 (PST) (envelope-from ginsberg@pluris.com) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA27872; Thu, 14 Mar 2002 20:53:30 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 20:53:30 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F87B@avalon.pluris.com> From: Les Ginsberg To: "'zhijian qin'" , isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Partition Designated L2 IS Election Problem MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 20:53:24 -0800 Defects in the route preference algorithm in the presence of virtual links as defined by ISO 10589:1992 were identified a few years ago. The changes were incorporated into ISO 10589:2001. I recommend you consult that to resolve your dilemma. Pay particular attention to the changes in Section 7.2.10 and 7.4.3. ftp.cisco.com/pub/rfc/ISO/ISO10589v2-2001-07-04.pdf Les > -----Original Message----- > From: zhijian qin [mailto:qinzhijian@yahoo.com] > Sent: Thursday, March 14, 2002 4:44 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] Partition Designated L2 IS Election Problem > > > Hi, > > I am a new guy on ISIS. When I was testing the Partition > Repair Option, I > create 2 areas, the first area has 6 routers while the second > area has 2 > routers. > > Area Addresses: > Area1 aa01 > Area2 aa02 > > NSAPs: > R1 aa01000000000001 > R2 aa01000000000002 > R3 aa01000000000003 > R4 aa01000000000004 > R5 aa01000000000005 > R6 aa01000000000006 > > R7 aa02000000000007 > R8 aa02000000000008 > > Network Topology: > > _____ > _____ > | | > | | > | R7 > | > -----------------------------------------------------------| R8 | > |_____| > |_____| > | > | > | > | > __|___ > __|___ > | | > | | > | R3 | > | R4 | > |_____| > |_____| > / \ > / \ > / \ > / \ > / \ > / \ > __|___ __|___ > __|___ __|___ > | | | | > | | | | > | R1 |-----| R2 > |-----------------------------------------------| R6 > |------| R5 | > |_____| |_____| > |_____| |_____| > > (All links are point-to-point links). > > I brought up all routers as L1L2 IS with partion repair > capability (I am not > sure if I can do that). Then I cut the connection between R2 and R6, > R1/R2/R3 became a partition of area1 and R4/R5/R6 became > another partion. > > Because every router in area1 can reach area2 directly or > indirectly, every > router in area1 claims itself as attached. So based the "Election of > partition designated level 2 IS" (ISO10589 7.2.10.2), the Partition > designated IS for the partition is R1 which has the lowest > ID, while the the > partion designated IS for the second partion is R4. R1 and R4 > treat each > other as a virtual adjacency. Each Non-Partition-Designated Routers > (R2/R3/R5/R6) use the partition designated router as the next > hop when they > want to reach the routers in another partiton. > > The problem is R1, which is the partition designated router > of the first > partion, use the R3 as the next hop for destination R4, then > I got a route > loop, when R2 wants to talk to R4, R2 selects R1 as the next > hop, then R3, > then R1 again, then R3 again,........... i am dead. > > I did go though the ISO 10589 couple of times for help > without any luck, but > I still don't believe the protocol itself has something > wrong, so could any > experts out there can tell me what is wrong with my test > envirionment or the > software stack I am using might be the bad guy? > > Thanks a lot in advance, > > Jackie Qin > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 15 00:07:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13238 for ; Fri, 15 Mar 2002 00:07:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F4u1t30634; Thu, 14 Mar 2002 20:56:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F4t2t30622 for ; Thu, 14 Mar 2002 20:55:02 -0800 (PST) (envelope-from ginsberg@pluris.com) 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 g2F54Ax91498 for ; Thu, 14 Mar 2002 21:04:10 -0800 (PST) X-JNPR-Received-From: outside Received: from yarilo.pluris.com ([208.227.9.200]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Mar 2002 21:00:11 -0800 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 VAA28398; Thu, 14 Mar 2002 21:01:20 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 21:01:20 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F87C@avalon.pluris.com> From: Les Ginsberg To: "'bneal@broadwing.com'" , leontsinis@hotmail.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 15 Mar 2002 05:00:11.0437 (UTC) FILETIME=[49336DD0:01C1CBDE] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 21:01:14 -0800 > > Although ISO 10589 defines four different metric fields, I believe the > decision process still uses a single scalar metric because > IS-IS combines > the four fields by simple addition paragraph 7.2.2, note 13. No - this is not the correct interpretation. Separate forwarding databases must be generated for each supported metric (see 10589:1992 C.2.4). The note Neal is referring to (Note 9 in the 1992 edition/Note 13 in the 2001 edition) is talking about how cost for a path is calculated for a particular type of metric - it is not meant to suggest that metrics of different types should be added together. Les _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 15 00:14:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13306 for ; Fri, 15 Mar 2002 00:14:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F531t30692; Thu, 14 Mar 2002 21:03:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F52Gt30680 for ; Thu, 14 Mar 2002 21:02:16 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id ECE2DF2C5B; Thu, 14 Mar 2002 21:11:22 -0800 (PST) To: Jon Berger Cc: "Isis-Wg (E-mail)" Subject: Re: [Isis-wg] draft-ietf-isis-wg-multi-topolgy-02 In-reply-to: Mail from Jon Berger dated Thu, 14 Mar 2002 17:19:51 GMT <37701240971DD31193970000F6CCB9F70348F0D4@duke.datcon.co.uk> From: Naiming Shen Message-Id: <20020315051122.ECE2DF2C5B@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 14 Mar 2002 21:11:22 -0800 Jon, ] Could someone explain to me what the assignment of MT ID#2 to IPv6 Routing ] Topology means? in M-ISIS extension, you can run multiple topologies within an IS-IS instance, the IPv6 topology is assigned to have MT ID of 2. so if you have different topology records in a packet, you can identify which topologies they belong. ] ] Is #2 the IPv6 equivalent of #0? If so, why can't we just use #0? If not, ] what does it represent? the MT ID #0 is for IPv4 unicast. yes in some sense, this #2 is the "normal" IPv6 topology. and if you have more than one IPv6 topologies within a single IS-IS domain, then you have to pick some other numbers.(this is like #0 is for "normal" IPv4 unicast topology, you need to pick other numbers for your other IPv4 unicast topologies). ] ] Jon ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 15 02:35:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22781 for ; Fri, 15 Mar 2002 02:35:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F7O0t31276; Thu, 14 Mar 2002 23:24:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F7N5t31264 for ; Thu, 14 Mar 2002 23:23:05 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 02:32:08 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Jeff Parker'" Cc: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] IS Adjacency table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 02:32:09 -0500 Hi Jeff, Some suggestion on IS Adjacency Table In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object conveying the message what "type" of adjacency is that (either Level1 or Level2), when isisISAdjUsage is "Level1and2" ? . It has to convey whether it is "Level 1" or "Level 2" i.e there can be another object before isisISAdjUsage like: isisISAdjType OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), } MAX-ACCESS read-only STATUS current DESCRIPTION "An adjacency of type level1 is used for level 1 traffic only. An adjacency of type level2 is used for level 2 traffic only. If this neighbor have another adjacency (at another level L1 or L2), then isisISAdjUsage should be 'levelland2'else it should be same as at this level" REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::= { isisISAdjEntry 6 } Thanks, Swami _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 15 04:15:24 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24175 for ; Fri, 15 Mar 2002 04:15:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F921t31791; Fri, 15 Mar 2002 01:02:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2F915t31779 for ; Fri, 15 Mar 2002 01:01:05 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 04:10:09 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Jeff Parker'" Cc: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: IS Adjacency table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 04:10:08 -0500 Also description for isisISAdjNeighPriority reads like: isisISAdjNeighPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the LAN Level 1 Designated Intermediate System if the value of isisISAdjNeighSysType is L1IntermediateSystem or LAN Level 2 Designated Intermediate System if the value of isisISAdjNeighSysType is L2IntermediateSystem." REFERENCE "{ISIS.aoi lANPriority (86)}" ::= { isisISAdjEntry 8 } what it mean when isisISAdjNeighSysType is "l1l2IntermediateSystem"?. I guess, it should be changed as DESCRIPTION "Priority of the neighboring Intermediate System for becoming the LAN Level 1 Designated Intermediate System if the value of *isisISAdjType* is 'Level1' or LAN Level 2 Designated Intermediate System if the value of *isisISAdjType* is 'level2'." isisISAdjType is new suggested object in my previous mail.. Thanks, Swami -----Original Message----- From: Ramalingam, Swaminathan Sent: Friday, March 15, 2002 1:02 PM To: 'Jeff Parker' Cc: 'isis-wg@spider.juniper.net' Subject: IS Adjacency table Hi Jeff, Some suggestion on IS Adjacency Table In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object conveying the message what "type" of adjacency is that (either Level1 or Level2), when isisISAdjUsage is "Level1and2" ? . It has to convey whether it is "Level 1" or "Level 2" i.e there can be another object before isisISAdjUsage like: isisISAdjType OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), } MAX-ACCESS read-only STATUS current DESCRIPTION "An adjacency of type level1 is used for level 1 traffic only. An adjacency of type level2 is used for level 2 traffic only. If this neighbor have another adjacency (at another level L1 or L2), then isisISAdjUsage should be 'levelland2'else it should be same as at this level" REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::= { isisISAdjEntry 6 } Thanks, Swami _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 15 09:22:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29461 for ; Fri, 15 Mar 2002 09:22:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2FEB1t33721; Fri, 15 Mar 2002 06:11:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2FEAYt33709 for ; Fri, 15 Mar 2002 06:10:34 -0800 (PST) (envelope-from rsaluja@nortelnetworks.com) Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2FEJbA12488; Fri, 15 Mar 2002 09:19:37 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2FEGmJ23968; Fri, 15 Mar 2002 09:16:48 -0500 (EST) 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 JAA14693; Fri, 15 Mar 2002 09:19:20 -0500 for Received: from nortelnetworks.com (localhost [127.0.0.1]) by lead.engeast (8.9.3+Sun/8.9.1) with ESMTP id JAA05742; Fri, 15 Mar 2002 09:19:19 -0500 (EST) Message-ID: <3C9202E7.5D621FE5@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: Jon Berger CC: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-3way-05 References: <37701240971DD31193970000F6CCB9F70348F0DE@duke.datcon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 09:19:19 -0500 Content-Transfer-Encoding: 7bit Jon Berger wrote: > Section 3.1 says > > "Any system that supports this mechanism MUST include Adjacency Three-Way > State field in this option. The other fields in this option should be > included as explained below in section 3.2." > > Which implies that it is possible to leave out the Extended Local Circuit > ID. However my reading of the rest of the draft is that this is not an > option. > > Jon > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg There are some old implementations which send only "Adjacency Three-Way State" field in this TLV. Thanks Rajesh _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 15 11:34:35 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03501 for ; Fri, 15 Mar 2002 11:34:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2FGN1t34260; Fri, 15 Mar 2002 08:23:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2FGMSt34248 for ; Fri, 15 Mar 2002 08:22:28 -0800 (PST) (envelope-from jlearman@cisco.com) 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 g2FGVcx02007 for ; Fri, 15 Mar 2002 08:31:38 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 08:26:47 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2FGSSr09419; Fri, 15 Mar 2002 11:28:28 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-16.cisco.com [10.82.240.16]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAZ25186; Fri, 15 Mar 2002 11:28:05 -0500 (EST) Message-Id: <4.3.2.7.2.20020315105005.03ddd9f0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Metz, Eduard" From: Jeff Learman Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Cc: "'Nikos Leontsinis'" , isis-wg@juniper.net In-Reply-To: <1E810ACBCC29D51185DF00508B66CCEED02442@ntexghfd02> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4533839==_.ALT" X-OriginalArrivalTime: 15 Mar 2002 16:26:48.0015 (UTC) FILETIME=[34465DF0:01C1CC3E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 15 Mar 2002 11:20:52 -0500 --=====================_4533839==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nikos, Eduard is correct, all metrics are dimensionless values and can be set to represent whatever you think works best for your network. bandwidth is simply the simplest choice that works very well under most circumstances, and assuming that hop-by-hop router-induced delays (other than for queuing) are insignificant. In addition, multiple metrics allows defining of different classes (up to 4) of traffic to be routed using different criteria. The category of traffic must be selected at the source by setting TOS bits (or for CLNS, QoS bits). Unless the source systems set these bits, all traffic is routed using the Default metric. For this reason, many networks use other means of classifying packets and handling QoS and differential services, and this is one of the driving factors behind MPLS and TE, if I my very limited understanding of those topics serves me correctly. Hopefully those who know these subjects well will correct me if I'm wrong! Furthermore, there is a pitfall to using multiple metrics. Unless all routers in the domain support and are properly configured to use the other metrics, you can get very nonintuitive results, as pointed out in Radia Perlman's "Interconnections". For example, let's assume that you (as the originating system) choose to take a path that optimizes "expense" and set the TOS bits accordingly. Also, assume that some routers support the expense metric and others don't. If there any paths between source and destination (within a subdomain, i.e. area or L2 bbone) the shortest of these paths are taken. Even if there is a single 1-cost hop between source and destination, where the router doesn't support the expense metric. All this means is that 1) multiple metrics doesn't give you better routing for default traffic 2) multiple metrics can give better routing for different TOS classes, if end systems set the bits 3) but ONLY if the non-default metrics are very carefully managed in the network. In my experience, the best use of multiple metrics has been in networks where all the traffic is generated by a limited number of applications that understand the domain's rules for metrics, i.e., a network that exists for a specific purpose. The example I have in mind was an electrical power management network. In this case, three metrics were used: default (capacity), delay, and "expense" was set to 1 for every link, so that certain traffic would always use the fewest hops regardless of other circuit properties. Default was used for bulk data transfer, Delay was used for interactive applications, and expense was used for various technical purposes including measurement of link behavior. While I'm on my soapbox, I'll include a warning about use of real-time data to set the delay metric. While this can be done successfully in certain cases, it's very difficult and requires a deep understanding of the network and application data traffic. The problem is that if you measure delays and set the delay metric in real time, you typically get into an unstable situation where, as soon as you lower the delay on a link, it starts attracting more traffic and the delays go up, so you must then raise it's metric, etc. IS-IS was designed with relatively static metric values in mind, to avoid this kind of problem. This doesn't answer your original question, which is "what's the best way to calculate the metric?" This is a very interesting topic that I believe has been studied extensively in various contexts. However, it's beyond the scope of this forum, which pertains to standards issues. The means of setting a metric value is not a matter for a standards committee because it's done entirely within an autonomous system (domain), and can be done any way the administrator thinks will provide the best results in his or her network. No standards are required. If you do find any good texts on the subject, we'd certainly be interested to hear of them, but a detailed discussion of the subject is probably not appropriate here. Regards, Jeff At 04:11 AM 3/13/2002, Metz, Eduard wrote: >AFAIK, the default metric is more or less 'dimensionless' in current= implementations, and therefor not derived from interface bandwidth= directly. So you can put any value in there (based on any formula you= wish). >=20 >In general something like: long, narrow pipes =3D> large metric, and short,= fat pipes =3D> small metric tends to work. Use the math of your choice to= get from one end to the other. >=20 >cheers, > Eduard =20 >-----Original Message-----=20 >From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]=20 >Sent: Monday, 11 March, 2002 23:10=20 >To: isis-wg@juniper.net=20 >Subject: [Isis-wg] IS-IS metrics: in search for a sound way > >ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined: > >1.Default: Each link is given a metric value based on its throughput=20 >2.Delay metric . It measures the transit delay of the circuit. (pretty= common-sensical higher value longer delay)=20 >3. Expense metric. It measures the monetary cost of the network's= utilsation-higher value larger expense-.(very unclear to me how this is= done)=20 > >4 Error metric.It measures the residual (=EA=E1=F4=DC=EB=EF=E9=F0=EF,= =F5=F0=FC=EB=EF=E9=F0=EF) error probability of the asociated circuit (also= unclear but makes sense as a concept).=20 > >If you look at the IS-IS LSP format's analysis i.e. p.638 Doyle, Routing= TCP/IP Volume1 you will see that IOS supports=20 > only the default metric (bit 4) Bits 5-7 which are delay, expense & error= are not supported and they will always be zero.=20 >This is a major IOS caveat as bandwidth alone is by no means sufficient to= account for metric assignment.=20 >However, looking at the LSP format is not the only way to reach the above= conclusion.=20 >These 3 factors would be brought into consideration on a discussion on how= to tune isis metrics by someone=20 >who was building his/her argumentation on pure operational experience.=20 >The main objective behind metric tuning is network performance improvement.= Performance is an umbrella=20 >which incorporates the configuration and measurement of distinct areas. It= is not clear to me how the ietf engineers=20 >calculate delay, expense and error as part of their (non Cisco supported)= isis impl! ementation. What it is indubitable is that=20 >availability, response time, accuracy and utilisation will be key= indicators for the performance of a network and these are the=20 >ones that should also be added as key decision parameters in the metric= assignment process. > > In conclusion, I am looking for a good way to measeure metrics= either based on bandwidth or geographical distance eventhough I don't think= there is one formula which can be used as a panacea. My feeling is that= this is a context based approach. One can come to an agreement on what= issues to consider but the=20 >decision should be taken on the individual links rather than make it matter= of correct application of a specific formula.=20 >For a more detailed analysis on these 4 areas of performance: availability,= response time, accuracy and utilisation see=20 >Pe= rformance and Fault Management Della Magiora, et al p.74-85.=20 > >Best,=20 >Nikos Leontsinis >=20 > > >=20 > > >=20 >---------- >Join the world's largest e-mail service with MSN Hotmail.= Click Here=20 >_______________________________________________ Isis-wg mailing list -= Isis-wg@spider.juniper.net= http://spider.juniper.net/mailman/listinfo/isis-wg=20 --=====================_4533839==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nikos,

Eduard is correct, all metrics are dimensionless values and can be
set to represent whatever you think works best for your network.
bandwidth is simply the simplest choice that works very well under
most circumstances, and assuming that hop-by-hop router-induced delays
(other than for queuing) are insignificant.

In addition, multiple metrics allows defining of different classes
(up to 4) of traffic to be routed using different criteria.  The category
of traffic must be selected at the source by setting TOS bits (or for
CLNS, QoS bits).  Unless the source systems set these bits, all traffic
is routed using the Default metric.  For this reason, many networks use
other means of classifying packets and handling QoS and=20 differential
services, and this is one of the driving factors behind MPLS and=20 TE,
if I my very limited understanding of those topics serves me correctly.
Hopefully those who know these subjects well will correct me if I'm
wrong!

Furthermore, there is a pitfall to using multiple metrics.  Unless
all routers in the domain support and are properly configured to=20 use
the other metrics, you can get very nonintuitive results, as=20 pointed
out in Radia Perlman's "Interconnections".  For example, let's assume
that you (as the originating system) choose to take a path that
optimizes "expense" and set the TOS bits accordingly.  Also, assume
that some routers support the expense metric and others don't.
If there any paths between source and destination (within a subdomain,
i.e. area or L2 bbone) the shortest of these paths are taken.  Even
if there is a single 1-cost hop between source and destination, where
the router doesn't support the expense metric.

All this means is that

  1) multiple metrics doesn't give you better routing for default traffic
  2) multiple metrics can give better routing for different TOS classes,
       if end systems set the bits
  3) but ONLY if the non-default metrics are very carefully managed
       in the network.

In my experience, the best use of multiple metrics has been in networks
where all the traffic is generated by a limited number of applications
that understand the domain's rules for metrics, i.e., a network
that exists for a specific purpose.  The example I have in mind was an
electrical power management network.  In this case, three metrics were
used: default (capacity), delay, and "expense" was set to 1 for every
link, so that certain traffic would always use the fewest hops regardless
of other circuit properties.  Default was used for bulk data transfer,
Delay was used for interactive applications, and expense was used for
various technical purposes including measurement of link behavior.

While I'm on my soapbox, I'll include a warning about use of real-time
data to set the delay metric.  While this can be done successfully in
certain cases, it's very difficult and requires a deep=20 understanding
of the network and application data traffic.  The problem is that if
you measure delays and set the delay metric in real time, you typically
get into an unstable situation where, as soon as you lower the=20 delay
on a link, it starts attracting more traffic and the delays go up,
so you must then raise it's metric, etc.  IS-IS was designed with
relatively static metric values in mind, to avoid this kind of problem.

This doesn't answer your original question, which is "what's the best
way to calculate the metric?"  This is a very interesting topic that
I believe has been studied extensively in various contexts.  However,
it's beyond the scope of this forum, which pertains to standards issues.
The means of setting a metric value is not a matter for a standards
committee because it's done entirely within an autonomous system
(domain), and can be done any way the administrator thinks will
provide the best results in his or her network.  No standards are
required.  If you do find any good texts on the subject, we'd certainly
be interested to hear of them, but a detailed discussion of the
subject is probably not appropriate here.

Regards,
Jeff

At 04:11 AM 3/13/2002, Metz, Eduard wrote:
AFAIK, the default metric is more or less 'dimensionless' in current implementations, and therefor not derived from interface bandwidth directly. So you can put any value in there (based on any formula you wish).
 
In general something like: long, narrow pipes =3D> large metric, and short, fat pipes =3D> small metric tends to work. Use the math of your choice to get from one end to the other.
 
cheers,
    Eduard
-----Original Message-----
From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]
Sent: Monday, 11 March, 2002 23:10
To: isis-wg@juniper.net
Subject: [Isis-wg] IS-IS metrics: in search for a sound way
ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined:

1.Default: Each link is given a metric value based on its throughput=20
2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay)
3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done)

4 Error metric.It measures the residual (=EA=E1=F4=DC=EB=EF=E9=F0=EF,= =F5=F0=FC=EB=EF=E9=F0=EF) error probability of the asociated circuit (also unclear but makes sense as a concept).

If you look at the IS-IS  LSP format's analysis i.e. p.638 Doyle, Routing TCP/IP Volume1 you will see that IOS supports
 only the default metric (bit 4) Bits 5-7  which are delay, expense & error are not supported and they will always be zero.
This is a major IOS caveat as bandwidth alone is by no means sufficient to account for metric assignment.
However, looking at the LSP format is not the only way to reach the above conclusion.
These 3 factors would be brought into consideration on a discussion on how to tune isis metrics by someone
who was building his/her argumentation on pure operational experience.=20
The main objective behind metric tuning is network performance improvement. Performance is an umbrella
which incorporates the configuration and measurement of distinct areas. It is not clear to me how the ietf engineers
calculate delay, expense and error as part of their (non Cisco supported) isis impl! ementation. What it is indubitable is that
availability, response time, accuracy and utilisation will be key indicators for the performance of a network and these are the
ones that should also be added as key decision parameters in the metric assignment process.

        In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't think there is one formula which can be used as a panacea. My feeling is that this is a context based approach. One can come to an agreement on what issues to consider but the
decision should be taken on the individual links rather than make it matter of correct application of a specific formula.
For a more detailed analysis on these 4 areas of performance: availability, response time, accuracy and utilisation see
Performance and Fault Management  Della Magiora, et al p.74-85.

Best,
Nikos Leontsinis
 


 


 
Join the world's largest e-mail service with MSN Hotmail. Click Here
_______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_4533839==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 06:07:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02914 for ; Mon, 18 Mar 2002 06:07:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IAs1t53422; Mon, 18 Mar 2002 02:54:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IArqt53410 for ; Mon, 18 Mar 2002 02:53:53 -0800 (PST) (envelope-from koen.vermeulen@alcatel.be) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2IB2pi15828 for ; Mon, 18 Mar 2002 12:02:52 +0100 (MET) Message-ID: <3C95C94C.4E94CE@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Isis-wg Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 12:02:36 +0100 Content-Transfer-Encoding: 7bit Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 08:43:50 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05024 for ; Mon, 18 Mar 2002 08:43:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IDW1t54539; Mon, 18 Mar 2002 05:32:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IDVtt54527 for ; Mon, 18 Mar 2002 05:31:55 -0800 (PST) (envelope-from christi@nortelnetworks.com) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2IDewN11988; Mon, 18 Mar 2002 14:41:06 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 13:41:11 -0000 Message-ID: <4103264BC8D3D51180B7002048400C454FB5DF@zhard0jd.europe.nortel.com> From: "Philip Christian" To: "'Koen Vermeulen'" , Isis-wg Subject: RE: [Isis-wg] Ipv4/Ipv6 routers in 1 area MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CE82.90402DC0" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 13:41:10 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CE82.90402DC0 Content-Type: text/plain; charset="iso-8859-1" According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4. By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6. Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area. This topological restriction applies due to the following clause in section 3.10 of RFC 1195 "The Dijkstra computation does not take into consideration whether a router is IP-only, OSI-only, or dual. The topological restrictions specified in section 1.4 ensure that IP packets will only be sent via IP-capable routers, and OSI packets will only be sent via OSI-capable routers." In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause. Not everyone may agree with this, but I believe that that is what it says. What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you. This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router). This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise. Philip -----Original Message----- From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] Sent: 18 March 2002 11:03 To: Isis-wg Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area Hello, I have a question related to the support of IPv4/IPv6 mixed routing domains. Every router will indicate inside its LSP what IP version it is capable off using the 'protocols supported' TLV: an IPv4-only router will indicate it supports IPv4, and IPv6-only router will indicate it supports IPv6 and an IPv4/IPv6 router indicates it supports both. This 'protocols supported' TLV can be used inside the SPF for a certain IP version (I assume that an IPv4/IPv6 router will need to run 2 SPFs, one for IPv4 and one for IPv6) to determine whether ot not to take the related LSP into account. This mechanism will work fine as long as an IPv4/IPv6 capable router can forward both IPv4 and IPv6 traffic on all its interfaces. Because of the 'node level' nature of the 'protocols supported' TLV, it is not possible to perform a correct calculation with IPv4/IPv6 routers which have a mixture of IPv4-only and IPv6-only interfaces. This can be shown easily with an example: +----+ | R1 | IPv4/IPv6 +----+ | | IPv6 capable link (1) | | +----+ | R2 | IPv4/IPv6 +----+ | | IPv4-only capable link (2) | | +----+ | R3 | IPv4/IPv6 +----+ | | IPv6 capable link (3) | | +----+ | R4 | IPv4/IPv6 +----+ | x R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and (3) can forward IPv6 packets, link (2) can only forward IPv4 traffic. x is an IPv6 network address. Suppose R1 is calculating a route to IPv6 network x. Because of the fact that R2 and R3 are both generating an LSP which indicates they are IPv6 capable, the resulting route to x will be via R2 and R3. Although, the link (2) between R2 and R3 is not capable of forwarding IPv6 traffic. I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', because here similar problems occur. From what I understand from this text, is that a dual router here can both forward CLNS and IP on all its interfaces, although it is not specifically stated. In case we take this rule also for IPv4/IPv6 capable routers (all interfaces are IPv4/IPv6 capable), there is of course no problem. On the other hand, during the transition of IPv4 to IPv6 I can image a lot of routers which will have a mixture of IPv4-only and IPv6-only interfaces. As a solution for this problem we were considering of announcing in every IS-reachablity TLV via a sub-TLV the capability of that specific interface (again via 'protocols supported')? This can be picked up in the SPF to decide whether or not take that link into account for a certain IP version. All suggestions/remarks/corrections are welcome. Thanks, Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1CE82.90402DC0 Content-Type: text/html; charset="iso-8859-1"

According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4.
By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6.
 
Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area.
 
This topological restriction applies due to the following clause in section 3.10 of RFC 1195
 
"The Dijkstra computation does not take into consideration whether a router
is IP-only, OSI-only, or dual. The topological restrictions specified in
section 1.4 ensure that IP packets will only be sent via IP-capable
routers, and OSI packets will only be sent via OSI-capable routers."
 
In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause.
 
Not everyone may agree with this, but I believe that that is what it says.
 
What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you.
This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router).
This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise.
 
Philip
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: 18 March 2002 11:03
To: Isis-wg
Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area

Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

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

------_=_NextPart_001_01C1CE82.90402DC0-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 10:12:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06776 for ; Mon, 18 Mar 2002 10:12:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IF11t54980; Mon, 18 Mar 2002 07:01:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IF0Lt54968 for ; Mon, 18 Mar 2002 07:00:21 -0800 (PST) (envelope-from koen.vermeulen@alcatel.be) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2IF9ep13633 for ; Mon, 18 Mar 2002 16:09:40 +0100 (MET) Message-ID: <3C960332.C5AD648@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Isis-wg Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1 area References: Content-Type: multipart/alternative; boundary="------------C11ECE905FC5FD8750E75473" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 16:09:38 +0100 --------------C11ECE905FC5FD8750E75473 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, OK, I agree with the fact that in case we take the RFC 1195 topological restrictions into account (which means that in case we want to forward IPv6 traffic inside an area all routers need to be able to forward IPv6 traffic) only 1 SPF is required and we don't need to look at the 'protocols supported' TLV. However, this makes it hard according to me for the transition of an area from IPv4 to IPv6. This means that from the moment we want to forward IPv6 traffic through an area, all routers and all its interfaces needs to be IPv6 capable. I don't see immediately how this can work during transition. Any suggestions? Regards, Koen Koen Vermeulen wrote: > Hello, > > I have a question related to the support of IPv4/IPv6 > mixed routing domains. > > Every router will indicate inside its LSP what IP > version it is capable off using the 'protocols supported' > TLV: an IPv4-only router will indicate it supports > IPv4, and IPv6-only router will indicate it supports > IPv6 and an IPv4/IPv6 router indicates it supports both. > > This 'protocols supported' TLV can be used inside the > SPF for a certain IP version (I assume that an IPv4/IPv6 > router will need to run 2 SPFs, one for IPv4 and one for > IPv6) to determine whether ot not to take the related LSP > into account. > > This mechanism will work fine as long as an IPv4/IPv6 > capable router can forward both IPv4 and IPv6 traffic > on all its interfaces. Because of the 'node level' nature > of the 'protocols supported' TLV, it is not possible > to perform a correct calculation with IPv4/IPv6 routers > which have a mixture of IPv4-only and IPv6-only interfaces. > This can be shown easily with an example: > > +----+ > | R1 | IPv4/IPv6 > +----+ > | > | IPv6 capable link (1) > | > | > +----+ > | R2 | IPv4/IPv6 > +----+ > | > | IPv4-only capable link (2) > | > | > +----+ > | R3 | IPv4/IPv6 > +----+ > | > | IPv6 capable link (3) > | > | > +----+ > | R4 | IPv4/IPv6 > +----+ > | > x > > R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and > (3) can forward IPv6 packets, link (2) can only forward IPv4 > traffic. x is an IPv6 network address. > > Suppose R1 is calculating a route to IPv6 network x. Because > of the fact that R2 and R3 are both generating an LSP which > indicates they are IPv6 capable, the resulting route to x will > be via R2 and R3. Although, the link (2) between R2 and R3 is > not capable of forwarding IPv6 traffic. > > I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', > because here similar problems occur. From what I understand > from this text, is that a dual router here can both forward > CLNS and IP on all its interfaces, although it is not specifically > stated. > > In case we take this rule also for IPv4/IPv6 capable routers > (all interfaces are IPv4/IPv6 capable), there is of course no > problem. On the other hand, during the transition of IPv4 > to IPv6 I can image a lot of routers which will have a > mixture of IPv4-only and IPv6-only interfaces. > > As a solution for this problem we were considering of announcing > in every IS-reachablity TLV via a sub-TLV the capability of > that specific interface (again via 'protocols supported')? > This can be picked up in the SPF to decide whether or not > take that link into account for a certain IP version. > > > All suggestions/remarks/corrections are welcome. > > Thanks, > Koen _______________________________________________ Isis-wg mailing > list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg --------------C11ECE905FC5FD8750E75473 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

OK, I agree with the fact that in case we take the RFC 1195 topological
restrictions into account (which means that in case we want to forward
IPv6 traffic inside an area all routers need to be able to forward IPv6
traffic) only 1 SPF is required and we don't need to look at the
'protocols supported' TLV.
However, this makes it hard according to me for the transition of an
area from IPv4 to IPv6. This means that from the moment we want
to forward IPv6 traffic through an area, all routers and all its interfaces
needs to be IPv6 capable.

I don't see immediately how this can work during transition.

Any suggestions?

Regards,
Koen

Koen Vermeulen wrote:

Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

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

--------------C11ECE905FC5FD8750E75473-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 10:15:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06859 for ; Mon, 18 Mar 2002 10:15:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IEc1t54828; Mon, 18 Mar 2002 06:38:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IEb8t54816 for ; Mon, 18 Mar 2002 06:37:08 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2IEkm906976; Mon, 18 Mar 2002 09:46:48 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (sjc-vpn1-415.cisco.com [10.21.97.159]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAZ55990; Mon, 18 Mar 2002 09:46:21 -0500 (EST) Message-Id: <4.3.2.7.2.20020318092744.01e1c528@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" From: Jeff Learman Subject: RE: [Isis-wg] Ipv4/Ipv6 routers in 1 area Cc: "'Koen Vermeulen'" , Isis-wg In-Reply-To: <4103264BC8D3D51180B7002048400C454FB5DF@zhard0jd.europe.nor tel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_212817855==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 09:42:12 -0500 --=====================_212817855==_.ALT Content-Type: text/plain; charset="us-ascii" Philip is correct; however, note that routers that run separate SPF calculations for each protocol type will behave identically to those that do not in any network that meets the topology restrictions. Their behavior differs only in networks that violate the restrictions. Failing to form adjacencies based on protocol is not mentioned anywhere in 1195, and again is outside the scope based on the topology restrictions. However, on a LAN where some routers form adjacencies per 10589 and others reject adjacencies based on protocols supported, the DR election process is not guaranteed to succeed, so DR priority should be carefully managed on such LANs. Regards, Jeff At 08:41 AM 3/18/2002, Philip Christian wrote: >According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4. >By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6. > >Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area. > >This topological restriction applies due to the following clause in section 3.10 of RFC 1195 > >"The Dijkstra computation does not take into consideration whether a router >is IP-only, OSI-only, or dual. The topological restrictions specified in >section 1.4 ensure that IP packets will only be sent via IP-capable >routers, and OSI packets will only be sent via OSI-capable routers." > >In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause. > >Not everyone may agree with this, but I believe that that is what it says. > >What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you. >This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router). >This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise. > >Philip >>-----Original Message----- >>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] >>Sent: 18 March 2002 11:03 >>To: Isis-wg >>Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area >> >>Hello, >> >>I have a question related to the support of IPv4/IPv6 >>mixed routing domains. >> >>Every router will indicate inside its LSP what IP >>version it is capable off using the 'protocols supported' >>TLV: an IPv4-only router will indicate it supports >>IPv4, and IPv6-only router will indicate it supports >>IPv6 and an IPv4/IPv6 router indicates it supports both. >> >>This 'protocols supported' TLV can be used inside the >>SPF for a certain IP version (I assume that an IPv4/IPv6 >>router will need to run 2 SPFs, one for IPv4 and one for >>IPv6) to determine whether ot not to take the related LSP >>into account. >> >>This mechanism will work fine as long as an IPv4/IPv6 >>capable router can forward both IPv4 and IPv6 traffic >>on all its interfaces. Because of the 'node level' nature >>of the 'protocols supported' TLV, it is not possible >>to perform a correct calculation with IPv4/IPv6 routers >>which have a mixture of IPv4-only and IPv6-only interfaces. >>This can be shown easily with an example: >> >> +----+ >> | R1 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (1) >> | >> | >> +----+ >> | R2 | IPv4/IPv6 >> +----+ >> | >> | IPv4-only capable link (2) >> | >> | >> +----+ >> | R3 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (3) >> | >> | >> +----+ >> | R4 | IPv4/IPv6 >> +----+ >> | >> x >> >>R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and >>(3) can forward IPv6 packets, link (2) can only forward IPv4 >>traffic. x is an IPv6 network address. >> >>Suppose R1 is calculating a route to IPv6 network x. Because >>of the fact that R2 and R3 are both generating an LSP which >>indicates they are IPv6 capable, the resulting route to x will >>be via R2 and R3. Although, the link (2) between R2 and R3 is >>not capable of forwarding IPv6 traffic. >> >>I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', >>because here similar problems occur. From what I understand >>from this text, is that a dual router here can both forward >>CLNS and IP on all its interfaces, although it is not specifically >>stated. >> >>In case we take this rule also for IPv4/IPv6 capable routers >>(all interfaces are IPv4/IPv6 capable), there is of course no >>problem. On the other hand, during the transition of IPv4 >>to IPv6 I can image a lot of routers which will have a >>mixture of IPv4-only and IPv6-only interfaces. >> >>As a solution for this problem we were considering of announcing >>in every IS-reachablity TLV via a sub-TLV the capability of >>that specific interface (again via 'protocols supported')? >>This can be picked up in the SPF to decide whether or not >>take that link into account for a certain IP version. >> >> >>All suggestions/remarks/corrections are welcome. >> >>Thanks, >>Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg --=====================_212817855==_.ALT Content-Type: text/html; charset="us-ascii"
Philip is correct; however, note that routers that run separate SPF
calculations for each protocol type will behave identically to those
that do not in any network that meets the topology restrictions.
Their behavior differs only in networks that violate the restrictions.

Failing to form adjacencies based on protocol is not mentioned anywhere in
1195, and again is outside the scope based on the topology restrictions.
However, on a LAN where some routers form adjacencies per 10589
and others reject adjacencies based on protocols supported, the DR
election process is not guaranteed to succeed, so DR priority should
be carefully managed on such LANs.

Regards,
Jeff
 

At 08:41 AM 3/18/2002, Philip Christian wrote:
According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4.
By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6.
 
Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area.
 
This topological restriction applies due to the following clause in section 3.10 of RFC 1195
 
"The Dijkstra computation does not take into consideration whether a router
is IP-only, OSI-only, or dual. The topological restrictions specified in
section 1.4 ensure that IP packets will only be sent via IP-capable
routers, and OSI packets will only be sent via OSI-capable routers."
 
In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause.
 
Not everyone may agree with this, but I believe that that is what it says.
 
What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you.
This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router).
This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise.
 
Philip
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: 18 March 2002 11:03
To: Isis-wg
Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area

Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_212817855==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 10:35:19 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07535 for ; Mon, 18 Mar 2002 10:35:17 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IFO1t55116; Mon, 18 Mar 2002 07:24:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IFNut55104 for ; Mon, 18 Mar 2002 07:23:57 -0800 (PST) (envelope-from Larmer@CommSense.Net) Received: (qmail 22578 invoked from network); 18 Mar 2002 15:33:24 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Mar 2002 15:33:24 -0000 From: "Ken Larmer" To: "Koen Vermeulen" , "Isis-wg" Subject: RE: [Isis-wg] Ipv4/Ipv6 routers in 1 area Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C1CE69.31DADF00" 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 V6.00.2600.0000 In-Reply-To: <3C960332.C5AD648@alcatel.be> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 10:39:34 -0500 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C1CE69.31DADF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Koen, RFC-1195 states the following: 4.4 Maintaining Router Adjacencies ... ... ... Dual routers must operate in a dual fashion on every link in the routing domain over which they are running IS-IS. Thus, the value of the "protocols supported" field must be identical on every link(i.e., for any one router running IS-IS, all of the Hellos and LSPs transmitted by it must contain the same "protocols supported" values). Cheers, Ken Larmer CommSense Networks -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Koen Vermeulen Sent: Monday, March 18, 2002 10:10 AM To: Isis-wg Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1 area Hello, OK, I agree with the fact that in case we take the RFC 1195 topological restrictions into account (which means that in case we want to forward IPv6 traffic inside an area all routers need to be able to forward IPv6 traffic) only 1 SPF is required and we don't need to look at the 'protocols supported' TLV. However, this makes it hard according to me for the transition of an area from IPv4 to IPv6. This means that from the moment we want to forward IPv6 traffic through an area, all routers and all its interfaces needs to be IPv6 capable. I don't see immediately how this can work during transition. Any suggestions? Regards, Koen Koen Vermeulen wrote: Hello, I have a question related to the support of IPv4/IPv6 mixed routing domains. Every router will indicate inside its LSP what IP version it is capable off using the 'protocols supported' TLV: an IPv4-only router will indicate it supports IPv4, and IPv6-only router will indicate it supports IPv6 and an IPv4/IPv6 router indicates it supports both. This 'protocols supported' TLV can be used inside the SPF for a certain IP version (I assume that an IPv4/IPv6 router will need to run 2 SPFs, one for IPv4 and one for IPv6) to determine whether ot not to take the related LSP into account. This mechanism will work fine as long as an IPv4/IPv6 capable router can forward both IPv4 and IPv6 traffic on all its interfaces. Because of the 'node level' nature of the 'protocols supported' TLV, it is not possible to perform a correct calculation with IPv4/IPv6 routers which have a mixture of IPv4-only and IPv6-only interfaces. This can be shown easily with an example: +----+ | R1 | IPv4/IPv6 +----+ | | IPv6 capable link (1) | | +----+ | R2 | IPv4/IPv6 +----+ | | IPv4-only capable link (2) | | +----+ | R3 | IPv4/IPv6 +----+ | | IPv6 capable link (3) | | +----+ | R4 | IPv4/IPv6 +----+ | x R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and (3) can forward IPv6 packets, link (2) can only forward IPv4 traffic. x is an IPv6 network address. Suppose R1 is calculating a route to IPv6 network x. Because of the fact that R2 and R3 are both generating an LSP which indicates they are IPv6 capable, the resulting route to x will be via R2 and R3. Although, the link (2) between R2 and R3 is not capable of forwarding IPv6 traffic. I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', because here similar problems occur. From what I understand from this text, is that a dual router here can both forward CLNS and IP on all its interfaces, although it is not specifically stated. In case we take this rule also for IPv4/IPv6 capable routers (all interfaces are IPv4/IPv6 capable), there is of course no problem. On the other hand, during the transition of IPv4 to IPv6 I can image a lot of routers which will have a mixture of IPv4-only and IPv6-only interfaces. As a solution for this problem we were considering of announcing in every IS-reachablity TLV via a sub-TLV the capability of that specific interface (again via 'protocols supported')? This can be picked up in the SPF to decide whether or not take that link into account for a certain IP version. All suggestions/remarks/corrections are welcome. Thanks, Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------=_NextPart_000_0018_01C1CE69.31DADF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Koen,
 
RFC-1195 states the = following:=20
=20
 4.4 Maintaining Router Adjacencies=20
...=20
...=20
...=20
Dual routers must operate in a dual fashion on every link in = the routing = domain over=20 which they are running IS-IS. Thus, the value of=20 the "protocols supported" = field must be=20 identical on every link(i.e., for any one router running IS-IS, all of = the=20 Hellos and LSPs   = transmitted by it=20 must contain the same "protocols supported"  =20 values).


 
Cheers, =
Ken Larmer=20
CommSense Networks
-----Original Message-----
From:=20 isis-wg-admin@external.juniper.net=20 [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Koen=20 Vermeulen
Sent: Monday, March 18, 2002 10:10 = AM
To:=20 Isis-wg
Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1=20 area

Hello,=20

OK, I agree with the fact that in case we take the RFC 1195 = topological=20
restrictions into account (which means that in case we want to = forward=20
IPv6 traffic inside an area all routers need to be able to forward = IPv6=20
traffic) only 1 SPF is required and we don't need to look at the=20
'protocols supported' TLV.
However, this makes it hard = according to me=20 for the transition of an
area from IPv4 to IPv6. This means that = from the=20 moment we want
to forward IPv6 traffic through an area, all = routers=20 and all its interfaces
needs to be IPv6 capable.=20

I don't see immediately how this can work during transition.=20

Any suggestions?=20

Regards,
Koen=20

Koen Vermeulen wrote:=20

Hello,=20

I have a question related to the support of IPv4/IPv6=20
mixed routing domains.=20

Every router will indicate inside its LSP what IP=20
version it is capable off using the 'protocols = supported'=20
TLV: an IPv4-only router will indicate it supports=20
IPv4, and IPv6-only router will indicate it supports=20
IPv6 and an IPv4/IPv6 router indicates it supports = both.=20

This 'protocols supported' TLV can be used inside the=20
SPF for a certain IP version (I assume that an = IPv4/IPv6=20
router will need to run 2 SPFs, one for IPv4 and one = for=20
IPv6) to determine whether ot not to take the related = LSP=20
into account.=20

This mechanism will work fine as long as an IPv4/IPv6=20
capable router can forward both IPv4 and IPv6 traffic=20
on all its interfaces. Because of the 'node level' = nature=20
of the 'protocols supported' TLV, it is not possible =
to=20 perform a correct calculation with IPv4/IPv6 routers =
which have=20 a mixture of IPv4-only and IPv6-only interfaces.
This = can be=20 shown easily with an example:=20 =

           =     =20 +----+=20 =
           = ;    =20 | R1 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;       =20 |=20 =
           = ;       =20 | IPv6 capable link (1)=20 =
           = ;       =20 |=20 =
           = ;       =20 |=20 =
           = ;    =20 +----+=20 =
           = ;    =20 | R2 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;       =20 |=20 =
           = ;       =20 | IPv4-only capable link (2)=20 =
           = ;       =20 |=20 =
           = ;       =20 |=20 =
           = ;    =20 +----+=20 =
           = ;    =20 | R3 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;       =20 |=20 =
           = ;       =20 | IPv6 capable link (3)=20 =
           = ;       =20 |=20 =
           = ;       =20 |=20 =
           = ;    =20 +----+=20 =
           = ;    =20 | R4 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;      =20 |=20 =
           = ;      =20 x=20

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) = and=20
(3) can forward IPv6 packets, link (2) can only forward = IPv4=20
traffic. x is an IPv6 network address.=20

Suppose R1 is calculating a route to IPv6 network x. = Because=20
of the fact that R2 and R3 are both generating an LSP = which=20
indicates they are IPv6 capable, the resulting route to x = will=20
be via R2 and R3. Although, the link (2) between R2 and R3 = is=20
not capable of forwarding IPv6 traffic.=20

I went back to RFC 1195 1.4 'Support of Mixed Routing = Domains',=20
because here similar problems occur. From what I = understand=20
from this text, is that a dual router here can both = forward=20
CLNS and IP on all its interfaces, although it is not=20 specifically
stated.=20

In case we take this rule also for IPv4/IPv6 capable = routers=20
(all interfaces are IPv4/IPv6 capable), there is of course = no=20
problem. On the other hand, during the transition of = IPv4=20
to IPv6 I can image a lot of routers which will have a=20
mixture of IPv4-only and IPv6-only interfaces.=20

As a solution for this problem we were considering of = announcing=20
in every IS-reachablity TLV via a sub-TLV the capability = of=20
that specific interface (again via 'protocols = supported')?=20
This can be picked up in the SPF to decide whether or = not=20
take that link into account for a certain IP version.=20
 =20

All suggestions/remarks/corrections are welcome.=20

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

------=_NextPart_000_0018_01C1CE69.31DADF00-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 11:38:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10147 for ; Mon, 18 Mar 2002 11:38:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IGQ1t55391; Mon, 18 Mar 2002 08:26:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IGPXt55379 for ; Mon, 18 Mar 2002 08:25:33 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2IGZLq23240; Mon, 18 Mar 2002 11:35:21 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (sjc-vpn1-415.cisco.com [10.21.97.159]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAZ59145; Mon, 18 Mar 2002 11:34:58 -0500 (EST) Message-Id: <4.3.2.7.2.20020318111308.03d43ee8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Koen Vermeulen From: Jeff Learman Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1 area Cc: Isis-wg In-Reply-To: <3C960332.C5AD648@alcatel.be> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_219337240==_.ALT" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 11:25:08 -0500 --=====================_219337240==_.ALT Content-Type: text/plain; charset="us-ascii" I agree, I suspect that 1195's restrictions are unnecessarily severe, and that they won't serve us well for migrating to IPV6. I think this is a very important discussion for us to be having. There are two restrictions that we need to consider: 1. Interface rules (a router must support all "supported protocols" on all interfaces) 2. Area / Domain rules (need I list them here?) A third consideration that is important is whether adjacency establishment should be a function of protocols supported. While it seems sensible to do this, it would break the DR election process. I hesitate to recommend changing restriction 1, but if it would be completely impractical to stand on this rule, we need to know about it. I'd really like input from service providers here. The second rule is easy to violate; some implementations already do. Those that do behave identically as those that don't, when deployed in a network that meets the restrictions. You can't deploy a router that doesn't violate the second restriction (i.e., a router that runs a single SPF) in a network that violates the rules, of course, so compatibility issues shouldn't be a problem here. Regards, Jeff At 10:09 AM 3/18/2002, Koen Vermeulen wrote: >Hello, > >OK, I agree with the fact that in case we take the RFC 1195 topological >restrictions into account (which means that in case we want to forward >IPv6 traffic inside an area all routers need to be able to forward IPv6 >traffic) only 1 SPF is required and we don't need to look at the >'protocols supported' TLV. >However, this makes it hard according to me for the transition of an >area from IPv4 to IPv6. This means that from the moment we want >to forward IPv6 traffic through an area, all routers and all its interfaces >needs to be IPv6 capable. > >I don't see immediately how this can work during transition. > >Any suggestions? > >Regards, >Koen > >Koen Vermeulen wrote: >>Hello, >> >>I have a question related to the support of IPv4/IPv6 >>mixed routing domains. >> >>Every router will indicate inside its LSP what IP >>version it is capable off using the 'protocols supported' >>TLV: an IPv4-only router will indicate it supports >>IPv4, and IPv6-only router will indicate it supports >>IPv6 and an IPv4/IPv6 router indicates it supports both. >> >>This 'protocols supported' TLV can be used inside the >>SPF for a certain IP version (I assume that an IPv4/IPv6 >>router will need to run 2 SPFs, one for IPv4 and one for >>IPv6) to determine whether ot not to take the related LSP >>into account. >> >>This mechanism will work fine as long as an IPv4/IPv6 >>capable router can forward both IPv4 and IPv6 traffic >>on all its interfaces. Because of the 'node level' nature >>of the 'protocols supported' TLV, it is not possible >>to perform a correct calculation with IPv4/IPv6 routers >>which have a mixture of IPv4-only and IPv6-only interfaces. >>This can be shown easily with an example: >> >> +----+ >> | R1 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (1) >> | >> | >> +----+ >> | R2 | IPv4/IPv6 >> +----+ >> | >> | IPv4-only capable link (2) >> | >> | >> +----+ >> | R3 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (3) >> | >> | >> +----+ >> | R4 | IPv4/IPv6 >> +----+ >> | >> x >> >>R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and >>(3) can forward IPv6 packets, link (2) can only forward IPv4 >>traffic. x is an IPv6 network address. >> >>Suppose R1 is calculating a route to IPv6 network x. Because >>of the fact that R2 and R3 are both generating an LSP which >>indicates they are IPv6 capable, the resulting route to x will >>be via R2 and R3. Although, the link (2) between R2 and R3 is >>not capable of forwarding IPv6 traffic. >> >>I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', >>because here similar problems occur. From what I understand >>from this text, is that a dual router here can both forward >>CLNS and IP on all its interfaces, although it is not specifically >>stated. >> >>In case we take this rule also for IPv4/IPv6 capable routers >>(all interfaces are IPv4/IPv6 capable), there is of course no >>problem. On the other hand, during the transition of IPv4 >>to IPv6 I can image a lot of routers which will have a >>mixture of IPv4-only and IPv6-only interfaces. >> >>As a solution for this problem we were considering of announcing >>in every IS-reachablity TLV via a sub-TLV the capability of >>that specific interface (again via 'protocols supported')? >>This can be picked up in the SPF to decide whether or not >>take that link into account for a certain IP version. >> >> >>All suggestions/remarks/corrections are welcome. >> >>Thanks, >>Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg --=====================_219337240==_.ALT Content-Type: text/html; charset="us-ascii"
I agree, I suspect that 1195's restrictions are unnecessarily severe,
and that they won't serve us well for migrating to IPV6.  I think this
is a very important discussion for us to be having.

There are two restrictions that we need to consider:

  1.  Interface rules (a router must support all "supported protocols"
      on all interfaces)

  2.  Area / Domain rules (need I list them here?)

A third consideration that is important is whether adjacency establishment
should be a function of protocols supported.  While it seems sensible to
do this, it would break the DR election process.

I hesitate to recommend changing restriction 1, but if it would be
completely impractical to stand on this rule, we need to know about it.
I'd really like input from service providers here.

The second rule is easy to violate; some implementations already do.
Those that do behave identically as those that don't, when deployed in
a network that meets the restrictions.  You can't deploy a router that
doesn't violate the second restriction (i.e., a router that runs a single
SPF) in a network that violates the rules, of course, so compatibility
issues shouldn't be a problem here.

Regards,
Jeff

At 10:09 AM 3/18/2002, Koen Vermeulen wrote:
Hello,

OK, I agree with the fact that in case we take the RFC 1195 topological
restrictions into account (which means that in case we want to forward
IPv6 traffic inside an area all routers need to be able to forward IPv6
traffic) only 1 SPF is required and we don't need to look at the
'protocols supported' TLV.
However, this makes it hard according to me for the transition of an
area from IPv4 to IPv6. This means that from the moment we want
to forward IPv6 traffic through an area, all routers and all its interfaces
needs to be IPv6 capable.

I don't see immediately how this can work during transition.

Any suggestions?

Regards,
Koen

Koen Vermeulen wrote:
Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_219337240==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 12:38:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12842 for ; Mon, 18 Mar 2002 12:38:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IHR0t55681; Mon, 18 Mar 2002 09:27:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IHQut55669 for ; Mon, 18 Mar 2002 09:26:56 -0800 (PST) (envelope-from naiming@redback.com) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id E341F1DCC71; Mon, 18 Mar 2002 09:36:25 -0800 (PST) To: Koen Vermeulen Cc: Isis-wg Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1 area In-reply-to: Mail from Koen Vermeulen dated Mon, 18 Mar 2002 16:09:38 +0100 <3C960332.C5AD648@alcatel.be> From: Naiming Shen Message-Id: <20020318173625.E341F1DCC71@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 09:36:25 -0800 ] ] Hello, ] ] OK, I agree with the fact that in case we take the RFC 1195 topological ] restrictions into account (which means that in case we want to forward ] IPv6 traffic inside an area all routers need to be able to forward IPv6 ] traffic) only 1 SPF is required and we don't need to look at the ] 'protocols supported' TLV. ] However, this makes it hard according to me for the transition of an ] area from IPv4 to IPv6. This means that from the moment we want ] to forward IPv6 traffic through an area, all routers and all its ] interfaces ] needs to be IPv6 capable. ] ] I don't see immediately how this can work during transition. ] ] Any suggestions? please take a look at: draft-ietf-isis-wg-multi-topology-02.txt to see if your problem is solved by using M-ISIS. ] ] Regards, ] Koen ] ] Koen Vermeulen wrote: ] ] > Hello, ] > ] > I have a question related to the support of IPv4/IPv6 ] > mixed routing domains. ] > ] > Every router will indicate inside its LSP what IP ] > version it is capable off using the 'protocols supported' ] > TLV: an IPv4-only router will indicate it supports ] > IPv4, and IPv6-only router will indicate it supports ] > IPv6 and an IPv4/IPv6 router indicates it supports both. ] > ] > This 'protocols supported' TLV can be used inside the ] > SPF for a certain IP version (I assume that an IPv4/IPv6 ] > router will need to run 2 SPFs, one for IPv4 and one for ] > IPv6) to determine whether ot not to take the related LSP ] > into account. ] > ] > This mechanism will work fine as long as an IPv4/IPv6 ] > capable router can forward both IPv4 and IPv6 traffic ] > on all its interfaces. Because of the 'node level' nature ] > of the 'protocols supported' TLV, it is not possible ] > to perform a correct calculation with IPv4/IPv6 routers ] > which have a mixture of IPv4-only and IPv6-only interfaces. ] > This can be shown easily with an example: ] > ] > +----+ ] > | R1 | IPv4/IPv6 ] > +----+ ] > | ] > | IPv6 capable link (1) ] > | ] > | ] > +----+ ] > | R2 | IPv4/IPv6 ] > +----+ ] > | ] > | IPv4-only capable link (2) ] > | ] > | ] > +----+ ] > | R3 | IPv4/IPv6 ] > +----+ ] > | ] > | IPv6 capable link (3) ] > | ] > | ] > +----+ ] > | R4 | IPv4/IPv6 ] > +----+ ] > | ] > x ] > ] > R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and ] > (3) can forward IPv6 packets, link (2) can only forward IPv4 ] > traffic. x is an IPv6 network address. ] > ] > Suppose R1 is calculating a route to IPv6 network x. Because ] > of the fact that R2 and R3 are both generating an LSP which ] > indicates they are IPv6 capable, the resulting route to x will ] > be via R2 and R3. Although, the link (2) between R2 and R3 is ] > not capable of forwarding IPv6 traffic. ] > ] > I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', ] > because here similar problems occur. From what I understand ] > from this text, is that a dual router here can both forward ] > CLNS and IP on all its interfaces, although it is not specifically ] > stated. ] > ] > In case we take this rule also for IPv4/IPv6 capable routers ] > (all interfaces are IPv4/IPv6 capable), there is of course no ] > problem. On the other hand, during the transition of IPv4 ] > to IPv6 I can image a lot of routers which will have a ] > mixture of IPv4-only and IPv6-only interfaces. ] > ] > As a solution for this problem we were considering of announcing ] > in every IS-reachablity TLV via a sub-TLV the capability of ] > that specific interface (again via 'protocols supported')? ] > This can be picked up in the SPF to decide whether or not ] > take that link into account for a certain IP version. ] > ] > ] > All suggestions/remarks/corrections are welcome. ] > ] > Thanks, ] > Koen _______________________________________________ Isis-wg mailing ] > list - Isis-wg@spider.juniper.net ] > http://spider.juniper.net/mailman/listinfo/isis-wg ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 13:17:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14056 for ; Mon, 18 Mar 2002 13:17:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2II61t55882; Mon, 18 Mar 2002 10:06:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2II54t55870 for ; Mon, 18 Mar 2002 10:05:04 -0800 (PST) (envelope-from Ravindra.Sunkad@vivacenetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2IIEXx48464 for ; Mon, 18 Mar 2002 10:14:33 -0800 (PST) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 10:08:02 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CEA8.1311AE3D" Subject: RE: [Isis-wg] Extended IP Reachability question Message-ID: Thread-Topic: [Isis-wg] Extended IP Reachability question Thread-Index: AcHLjI05pA0iyNNRT3+F0cXgvG13rQDGfgKg From: "Ravindra Sunkad" To: X-OriginalArrivalTime: 18 Mar 2002 18:08:02.0530 (UTC) FILETIME=[D8350C20:01C1CEA7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 10:09:41 -0800 This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CEA8.1311AE3D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I haven't seen any responses in regards to the following thread. So, I'm assuming that no such sub-tlv has been defined so far. I propose a color/tag sub-tlv for the Extended IP Reachability TLV. This will be similar to the "Administrative group" sub-tlv defined=20 for the Extended IS Reachability TLV. It contains a 4-octet bit mask. The least significant bit is defined to indicate whether the IP prefix is outside the IS-IS routing domain. =20 Please provide me your inputs. =20 Thanks, Ravi =20 -----Original Message----- From: Ravindra Sunkad=20 Sent: Thursday, March 14, 2002 11:11 AM To: isis-wg@juniper.net Subject: [Isis-wg] Extended IP Reachability question Hi, =20 In the following threads there is some talk about defining a sub-tlv for the Extended IP Reachability TLV that could be used to differentiate external route advertisements from internal route advertisements. Has any work been done on this front? =20 http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 =20 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt=20 =20 Thanks, Ravi ------_=_NextPart_001_01C1CEA8.1311AE3D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 haven't seen any responses in regards to the following thread. So, I'm = assuming=20 that no such sub-tlv has been defined so far.
I=20 propose a color/tag sub-tlv for the Extended IP Reachability = TLV. This will=20 be similar to the "Administrative group" sub-tlv defined =
for=20 the Extended IS Reachability TLV. It contains a 4-octet bit mask. The = least=20 significant bit is defined to indicate whether the IP=20 prefix
is=20 outside the IS-IS routing domain.
 
Please=20 provide me your inputs.
 
Thanks,
Ravi
 
-----Original = Message-----
From:=20 Ravindra Sunkad
Sent: Thursday, March 14, 2002 11:11 = AM
To:=20 isis-wg@juniper.net
Subject: [Isis-wg] Extended IP = Reachability=20 question

Hi,

 

In the following = threads=20 there is some talk about defining a sub-tlv for the Extended IP = Reachability=20 TLV that could be used to differentiate external route advertisements = from=20 internal route advertisements. Has any work been done on this=20 front?

 

= http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31

 

[Isis-wg] IS-IS = Extensions=20 for Traffic Engineering

[Isis-wg]=20 draft-ietf-isis-traffic-01.txt

 

Thanks,

Ravi

=00 ------_=_NextPart_001_01C1CEA8.1311AE3D-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 16:06:56 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20185 for ; Mon, 18 Mar 2002 16:06:55 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IKt1t56637; Mon, 18 Mar 2002 12:55:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IKsxt56622 for ; Mon, 18 Mar 2002 12:55:00 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2IL4QR33037 for ; Mon, 18 Mar 2002 13:04:30 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 13:01:45 -0800 Received: from miata.procket.com (unknown [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id B89D83443A; Mon, 18 Mar 2002 13:06:46 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2IL36vM018526; Mon, 18 Mar 2002 13:03:06 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2IL36gQ009247; Mon, 18 Mar 2002 13:03:06 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <15510.22025.927785.672153@alpha-tli.procket.com> To: "Ravindra Sunkad" Cc: Subject: RE: [Isis-wg] Extended IP Reachability question In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 18 Mar 2002 21:01:45.0250 (UTC) FILETIME=[1CA1E820:01C1CEC0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id g2IKt0t56623 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 13:03:05 -0800 Content-Transfer-Encoding: 8bit Why? Tony Ravindra Sunkad writes: | I haven't seen any responses in regards to the following thread. So, I'm | assuming that no such sub-tlv has been defined so far. | I propose a color/tag sub-tlv for the Extended IP Reachability TLV. This | will be similar to the "Administrative group" sub-tlv defined | for the Extended IS Reachability TLV. It contains a 4-octet bit mask. | The least significant bit is defined to indicate whether the IP prefix | is outside the IS-IS routing domain. | | Please provide me your inputs. | | Thanks, | Ravi | | -----Original Message----- | From: Ravindra Sunkad | Sent: Thursday, March 14, 2002 11:11 AM | To: isis-wg@juniper.net | Subject: [Isis-wg] Extended IP Reachability question | | | | Hi, | | | | In the following threads there is some talk about defining a | sub-tlv for the Extended IP Reachability TLV that could be used to | differentiate external route advertisements from internal route | advertisements. Has any work been done on this front? | | | | http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 | | | | [Isis-wg] IS-IS Extensions for Traffic Engineering | | [Isis-wg] draft-ietf-isis-traffic-01.txt | | | | Thanks, | | Ravi | | | Message | | | | | |
I | haven't seen any responses in regards to the following thread. So, I'm assuming | that no such sub-tlv has been defined so far.
|
I | propose a color/tag sub-tlv for the Extended IP Reachability TLV. This will | be similar to the "Administrative group" sub-tlv defined
|
for | the Extended IS Reachability TLV. It contains a 4-octet bit mask. The least | significant bit is defined to indicate whether the IP | prefix
|
is | outside the IS-IS routing domain.
|
 
|
Please | provide me your inputs.
|
 
|
Thanks,
|
Ravi
|
 
|
-----Original Message-----
From: | Ravindra Sunkad
Sent: Thursday, March 14, 2002 11:11 AM
To: | isis-wg@juniper.net
Subject: [Isis-wg] Extended IP Reachability | question

|
|
|

Hi,

|

 

|

In the following threads | there is some talk about defining a sub-tlv for the Extended IP Reachability | TLV that could be used to differentiate external route advertisements from | internal route advertisements. Has any work been done on this | front?

|

 

|

http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31

|

 

|

[Isis-wg] IS-IS Extensions | for Traffic Engineering

|

[Isis-wg] | draft-ietf-isis-traffic-01.txt

|

 

|

Thanks,

|

Ravi

| _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 16:32:12 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21117 for ; Mon, 18 Mar 2002 16:32:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2ILL1t56780; Mon, 18 Mar 2002 13:21:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2ILKIt56768 for ; Mon, 18 Mar 2002 13:20:18 -0800 (PST) (envelope-from cmartin@gnilink.net) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2ILTnR33282 for ; Mon, 18 Mar 2002 13:29:49 -0800 (PST) X-JNPR-Received-From: outside Received: from entmail.gnilink.net ([199.45.47.10]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 13:25:53 -0800 Received: by entmail.gnilink.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 16:27:19 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB35015F2C82@entmail.gnilink.com> From: "Martin, Christian" To: "'Ravindra Sunkad'" , isis-wg@juniper.net Subject: RE: [Isis-wg] Extended IP Reachability question MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 Mar 2002 21:25:53.0359 (UTC) FILETIME=[7BC5CDF0:01C1CEC3] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 16:27:16 -0500 See http://search.ietf.org/internet-drafts/draft-martin-neal-policy-isis-admin-t ags-04.txt for this type of information. How the vendor implements the policy is up to the vendor, but matching internal vs external and tagging shouldn't be an issue during LSP creation. chris -----Original Message----- From: Ravindra Sunkad [mailto:Ravindra.Sunkad@vivacenetworks.com] Sent: Monday, March 18, 2002 1:10 PM To: isis-wg@juniper.net Subject: RE: [Isis-wg] Extended IP Reachability question I haven't seen any responses in regards to the following thread. So, I'm assuming that no such sub-tlv has been defined so far. I propose a color/tag sub-tlv for the Extended IP Reachability TLV. This will be similar to the "Administrative group" sub-tlv defined for the Extended IS Reachability TLV. It contains a 4-octet bit mask. The least significant bit is defined to indicate whether the IP prefix is outside the IS-IS routing domain. Please provide me your inputs. Thanks, Ravi -----Original Message----- From: Ravindra Sunkad Sent: Thursday, March 14, 2002 11:11 AM To: isis-wg@juniper.net Subject: [Isis-wg] Extended IP Reachability question Hi, In the following threads there is some talk about defining a sub-tlv for the Extended IP Reachability TLV that could be used to differentiate external route advertisements from internal route advertisements. Has any work been done on this front? http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt Thanks, Ravi _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 17:08:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22229 for ; Mon, 18 Mar 2002 17:08:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2ILv1t56970; Mon, 18 Mar 2002 13:57:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2ILu4t56958 for ; Mon, 18 Mar 2002 13:56:04 -0800 (PST) (envelope-from Ravindra.Sunkad@vivacenetworks.com) 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 g2IM5Yt76948 for ; Mon, 18 Mar 2002 14:05:35 -0800 (PST) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 13:58:23 -0800 Subject: RE: [Isis-wg] Extended IP Reachability question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Isis-wg] Extended IP Reachability question Thread-Index: AcHOwF1saD9uYJtlRnK9Lbtncqr0qQACHa3Q From: "Ravindra Sunkad" To: "Tony Li" Cc: X-OriginalArrivalTime: 18 Mar 2002 21:58:23.0203 (UTC) FILETIME=[05F86330:01C1CEC8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2ILu4t56959 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 14:00:02 -0800 Content-Transfer-Encoding: 8bit When IS-IS routes are redistributed to other protocols this piece of information can be useful and could serve as an additional filter. Also, we might want to create LDP LSPs only for internal prefixes. Ravi > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Monday, March 18, 2002 1:03 PM > To: Ravindra Sunkad > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > > > Why? > > Tony > > > > Ravindra Sunkad writes: > | I haven't seen any responses in regards to the following > thread. So, I'm | assuming that no such sub-tlv has been > defined so far. | I propose a color/tag sub-tlv for the > Extended IP Reachability TLV. This | will be similar to the > "Administrative group" sub-tlv defined > | for the Extended IS Reachability TLV. It contains a > 4-octet bit mask. | The least significant bit is defined to > indicate whether the IP prefix | is outside the IS-IS > routing domain. | > | Please provide me your inputs. > | > | Thanks, > | Ravi > | > | -----Original Message----- > | From: Ravindra Sunkad > | Sent: Thursday, March 14, 2002 11:11 AM > | To: isis-wg@juniper.net > | Subject: [Isis-wg] Extended IP Reachability question > | > | > | > | Hi, > | > | > | > | In the following threads there is some talk about defining a > | sub-tlv for the Extended IP Reachability TLV that could be > used to | differentiate external route advertisements from > internal route | advertisements. Has any work been done on > this front? | > | > | > | http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 > | > | > | > | [Isis-wg] IS-IS Extensions for Traffic Engineering > | > | [Isis-wg] draft-ietf-isis-traffic-01.txt > | > | > | > | Thanks, > | > | Ravi > | > | Transitional//EN"> | Message > | | name=GENERATOR> | > | > | > |
class=890335817-18032002>I > | haven't seen any responses in regards to the following > thread. So, I'm assuming > | that no such sub-tlv has been defined so > far.
|
color=#0000ff size=2>I > | propose a color/tag sub-tlv for the Extended IP > Reachability TLV. This will > | be similar to the "Administrative group" sub-tlv defined >
|
size=2>for > | the Extended IS Reachability TLV. It contains a 4-octet > bit mask. The least > | significant bit is defined to indicate whether the IP > | prefix
> |
class=890335817-18032002>is > | outside the IS-IS routing domain.
> |
| class=890335817-18032002> 
> |
class=890335817-18032002>Please > | provide me your inputs.
> |
| class=890335817-18032002> 
> |
| class=890335817-18032002>Thanks,
> |
| class=890335817-18032002>Ravi
> |
| class=890335817-18032002> 
> |
-----Original > Message-----
From: > | Ravindra Sunkad
Sent: Thursday, March 14, 2002 > 11:11 AM
To: > | isis-wg@juniper.net
Subject: [Isis-wg] Extended > IP Reachability > | question

> |
| style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: > #0000ff 2px solid; MARGIN-RIGHT: 0px"> > |
> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'">Hi,

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">In > the following threads > | there is some talk about defining a sub-tlv for the > Extended IP Reachability > | TLV that could be used to differentiate external route > advertisements from > | internal route advertisements. Has any work been done on this > | front?

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> | > href="http://spider.juniper.net/pipermail/isis-wg/1999/thread. > html#31">http://spider.juniper.net/pipermail/isis-wg/1999/thre > ad.html#31

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'">[Isis-wg] IS-IS Extensions > | for Traffic Engineering

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">[Isis-wg] > | draft-ietf-isis-traffic-01.txt

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: > Arial"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: > Arial">Thanks,

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: > Arial">Ravi

> | > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 17:22:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22783 for ; Mon, 18 Mar 2002 17:22:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IMB1t57081; Mon, 18 Mar 2002 14:11:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2IMAat57069 for ; Mon, 18 Mar 2002 14:10:36 -0800 (PST) (envelope-from Ravindra.Sunkad@vivacenetworks.com) 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 g2IMK7t77253 for ; Mon, 18 Mar 2002 14:20:07 -0800 (PST) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 14:14:14 -0800 Subject: RE: [Isis-wg] Extended IP Reachability question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Isis-wg] Extended IP Reachability question Thread-Index: AcHOxIJVkt69QdSHTImrUenJLpkM7AABaEOQ From: "Ravindra Sunkad" To: "Martin, Christian" , X-OriginalArrivalTime: 18 Mar 2002 22:14:14.0359 (UTC) FILETIME=[3CE74670:01C1CECA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2IMAat57070 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 14:15:53 -0800 Content-Transfer-Encoding: 8bit Chris, Thanks. This could work. But it would be good if everybody automatically originates a predefined sub-tlv tagging prefixes as external. i.e. I prefer this sub-tlv not be administrative. Ravi > -----Original Message----- > From: Martin, Christian [mailto:cmartin@gnilink.net] > Sent: Monday, March 18, 2002 1:27 PM > To: Ravindra Sunkad; isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > See > http://search.ietf.org/internet-drafts/draft-martin-neal-polic > y-isis-admin-t > ags-04.txt for this type of information. How the vendor > implements the policy is up to the vendor, but matching > internal vs external and tagging shouldn't be an issue during > LSP creation. > > chris > > > > -----Original Message----- > From: Ravindra Sunkad [mailto:Ravindra.Sunkad@vivacenetworks.com] > Sent: Monday, March 18, 2002 1:10 PM > To: isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > I haven't seen any responses in regards to the following > thread. So, I'm assuming that no such sub-tlv has been > defined so far. I propose a color/tag sub-tlv for the > Extended IP Reachability TLV. This will be similar to the > "Administrative group" sub-tlv defined > for the Extended IS Reachability TLV. It contains a 4-octet > bit mask. The least significant bit is defined to indicate > whether the IP prefix is outside the IS-IS routing domain. > > Please provide me your inputs. > > Thanks, > Ravi > > -----Original Message----- > From: Ravindra Sunkad > Sent: Thursday, March 14, 2002 11:11 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Extended IP Reachability question > > > Hi, > > In the following threads there is some talk about defining a > sub-tlv for the Extended IP Reachability TLV that could be > used to differentiate external route advertisements from > internal route advertisements. Has any work been done on this front? > http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt Thanks, Ravi _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 19:46:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27572 for ; Mon, 18 Mar 2002 19:46:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2J0W1t57663; Mon, 18 Mar 2002 16:32:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2J0V1t57651 for ; Mon, 18 Mar 2002 16:31:01 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2J0eWR35844 for ; Mon, 18 Mar 2002 16:40:32 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz1.procket.com ([65.174.124.36]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 16:36:38 -0800 Received: from miata.procket.com (unknown [65.174.124.5]) by dmz1.procket.com (Postfix) with ESMTP id A76E723C34; Mon, 18 Mar 2002 16:28:03 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2J0c4vM002580; Mon, 18 Mar 2002 16:38:04 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2J0c3M8009292; Mon, 18 Mar 2002 16:38:03 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15510.34923.740783.933930@alpha-tli.procket.com> To: "Ravindra Sunkad" Cc: "Tony Li" , Subject: RE: [Isis-wg] Extended IP Reachability question In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 19 Mar 2002 00:36:38.0375 (UTC) FILETIME=[2188A770:01C1CEDE] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 16:38:03 -0800 Content-Transfer-Encoding: 7bit | When IS-IS routes are redistributed to other protocols this piece of | information can be useful and could serve as an additional filter. Also, | we might want to create LDP LSPs only for internal prefixes. I believe that over the history of the Internet, it has been shown to be generally a catastrophic event to ever put any external prefixes into your IGP. It seems an error to encourage that. Similarly, unconstrained redistribution of prefixes from your IGP into BGP can also result in unwanted exposure of your internal topology to the outside world. Thus, it would seem to me that the primary mechanism to filtering routes redistributed into and out of IS-IS should be a manually configured prefix filter. Given that this exists (if redistribution is even necessary -- which I begin to doubt), I fail to see the overwhelming need for this additional bit of data. So again, why do we need this? Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 18 22:18:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01483 for ; Mon, 18 Mar 2002 22:18:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2J33ht58416; Mon, 18 Mar 2002 19:03:43 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2J2wRt58384 for ; Mon, 18 Mar 2002 18:58:27 -0800 (PST) (envelope-from Ravindra.Sunkad@vivacenetworks.com) 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 g2J37xx58148 for ; Mon, 18 Mar 2002 19:07:59 -0800 (PST) X-JNPR-Received-From: outside Received: from vivacenetworks.com ([64.221.212.130]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 19:03:47 -0800 Subject: RE: [Isis-wg] Extended IP Reachability question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Isis-wg] Extended IP Reachability question Thread-Index: AcHO3mHA2zgPOseITgypNta6lcQ4BQAD350A From: "Ravindra Sunkad" To: "Tony Li" Cc: X-OriginalArrivalTime: 19 Mar 2002 03:03:47.0109 (UTC) FILETIME=[AFDE8D50:01C1CEF2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2J2wSt58385 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 18 Mar 2002 19:05:26 -0800 Content-Transfer-Encoding: 8bit Perhaps there is no application in the real world that needs to differentiate IS-IS internal routes from externals. I was not sure if this was dropped purposefully from the isis-traffic draft or dropped because it was not in the scope of the document as one of the archived postings suggested. Since this is a shift from RFC-1195 is it worth mentioning the rationale in the traffic-eng draft? Thanks for your responses. Ravi > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Monday, March 18, 2002 4:38 PM > To: Ravindra Sunkad > Cc: Tony Li; isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > > | When IS-IS routes are redistributed to other protocols > this piece of | information can be useful and could serve as > an additional filter. Also, | we might want to create LDP > LSPs only for internal prefixes. > > > I believe that over the history of the Internet, it has been > shown to be generally a catastrophic event to ever put any > external prefixes into your IGP. It seems an error to encourage that. > > Similarly, unconstrained redistribution of prefixes from your > IGP into BGP can also result in unwanted exposure of your > internal topology to the outside world. > > Thus, it would seem to me that the primary mechanism to > filtering routes redistributed into and out of IS-IS should > be a manually configured prefix filter. Given that this > exists (if redistribution is even necessary -- which I begin > to doubt), I fail to see the overwhelming need for this > additional bit of data. > > So again, why do we need this? > > Tony > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 19 14:01:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00595 for ; Tue, 19 Mar 2002 14:01:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2JIjQt63275; Tue, 19 Mar 2002 10:45:26 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2JIbft63225 for ; Tue, 19 Mar 2002 10:37:41 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2JIlGx71144 for ; Tue, 19 Mar 2002 10:47:17 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 10:41:53 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JIhdO18190; Tue, 19 Mar 2002 13:43:40 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAZ88453; Tue, 19 Mar 2002 13:43:16 -0500 (EST) Message-Id: <4.3.2.7.2.20020319133041.03aedf08@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Ravindra Sunkad" From: Jeff Learman Subject: RE: [Isis-wg] Extended IP Reachability question Cc: "Tony Li" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 19 Mar 2002 18:41:53.0984 (UTC) FILETIME=[BD761400:01C1CF75] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 13:32:19 -0500 At 10:05 PM 3/18/2002, Ravindra Sunkad wrote: >Perhaps there is no application in the real world that needs to >differentiate IS-IS internal routes from externals. >I was not sure if this was dropped purposefully from the isis-traffic >draft or dropped because it was not in the scope of the document as one >of the archived postings suggested. Since this is a shift from RFC-1195 >is it worth mentioning the rationale in the traffic-eng draft? This sounds like be a good idea, because this question seems to pop up with annoying regularity. >Thanks for your responses. > >Ravi > >> -----Original Message----- >> From: Tony Li [mailto:tli@procket.com] >> Sent: Monday, March 18, 2002 4:38 PM >> To: Ravindra Sunkad >> Cc: Tony Li; isis-wg@juniper.net >> Subject: RE: [Isis-wg] Extended IP Reachability question >> >> >> >> | When IS-IS routes are redistributed to other protocols >> this piece of | information can be useful and could serve as >> an additional filter. Also, | we might want to create LDP >> LSPs only for internal prefixes. >> >> >> I believe that over the history of the Internet, it has been >> shown to be generally a catastrophic event to ever put any >> external prefixes into your IGP. It seems an error to encourage that. >> >> Similarly, unconstrained redistribution of prefixes from your >> IGP into BGP can also result in unwanted exposure of your >> internal topology to the outside world. >> >> Thus, it would seem to me that the primary mechanism to >> filtering routes redistributed into and out of IS-IS should >> be a manually configured prefix filter. Given that this >> exists (if redistribution is even necessary -- which I begin >> to doubt), I fail to see the overwhelming need for this >> additional bit of data. >> >> So again, why do we need this? >> >> Tony >> >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 19 18:55:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08197 for ; Tue, 19 Mar 2002 18:55:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2JNi1t64664; Tue, 19 Mar 2002 15:44:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2JNhct64652 for ; Tue, 19 Mar 2002 15:43:38 -0800 (PST) (envelope-from Prashant.Shukla@flukenetworks.com) 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 g2JNrFx77202 for ; Tue, 19 Mar 2002 15:53:15 -0800 (PST) X-JNPR-Received-From: outside Received: from evtvir03.tc.fluke.com ([129.196.128.53]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 15:45:28 -0800 Received: from evtvir03.tc.fluke.com ([129.196.128.53]) by evtvir03.tc.fluke.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DBAYBLWR; Tue, 19 Mar 2002 15:46:56 -0800 Received: FROM evtexc01.tc.fluke.com BY evtvir03.tc.fluke.com ; Tue Mar 19 15:46:55 2002 -0800 Received: by evtexc01.tc.fluke.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 15:45:36 -0800 Message-ID: <838EF00CFC5DD511BA750008C78CBA9BD5189F@evtexc03.tc.fluke.com> From: "Shukla, Prashant" To: isis-wg@juniper.net MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 19 Mar 2002 23:45:28.0968 (UTC) FILETIME=[26701080:01C1CFA0] Subject: [Isis-wg] unsubsribe Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 19 Mar 2002 15:46:47 -0800 unsubsribe _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 20 13:58:03 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09981 for ; Wed, 20 Mar 2002 13:58:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2KIj1t69678; Wed, 20 Mar 2002 10:45:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2KIiYt69663 for ; Wed, 20 Mar 2002 10:44:34 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) 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 g2KIsGt07840 for ; Wed, 20 Mar 2002 10:54:16 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Mar 2002 10:52:47 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g2KIsEe20475 for ; Wed, 20 Mar 2002 10:54:14 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id KAA19297 for ; Wed, 20 Mar 2002 10:54:08 -0800 (PST) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g2KImvY24301 for ; Wed, 20 Mar 2002 10:48:57 -0800 (PST) Received: from ems11 (ems11 [131.241.5.62]) by bunny.tdd.sj.nec.com (8.11.3/8.11.6) with SMTP id g2KImuW03611 for ; Wed, 20 Mar 2002 10:48:56 -0800 (PST) Received: by localhost with Microsoft MAPI; Wed, 20 Mar 2002 10:55:10 -0800 Message-ID: <01C1CFFD.B4A9B1A0.ramsrm@tdd.sj.nec.com> From: ramanathan rams Reply-To: "ramsrm@tdd.sj.nec.com" To: "isis-wg@juniper.net" Organization: NEC X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 20 TEXT X-OriginalArrivalTime: 20 Mar 2002 18:52:47.0609 (UTC) FILETIME=[6D771690:01C1D040] Subject: [Isis-wg] area address in Source NSAP. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 20 Mar 2002 10:55:08 -0800 hi all, I have the following doubt, could u please explain me? * we r maintaining 2 area address list in an IS, * manual area address list and * another list, which is having all the area addresses present in that area( formed from L1 LSPs). my doubt is, if an IS originates a packet, in the source NSAP field, can we use an area address such that it is present in the second list but not in the manual area address list of that IS? second doubt is, similar to the frst doubt. When an IS originates the ISH, 10589 says, we have to use the lowest available area address in the NET field. For finding the lowest available area address, do we have to search only the manual area address list or can we search the second list also? thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 20 14:57:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12371 for ; Wed, 20 Mar 2002 14:57:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2KJk1t69968; Wed, 20 Mar 2002 11:46:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2KJjct69956 for ; Wed, 20 Mar 2002 11:45:38 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2KJtKR68914 for ; Wed, 20 Mar 2002 11:55:21 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Mar 2002 11:51:20 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2KJr8j05436; Wed, 20 Mar 2002 14:53:08 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABA18153; Wed, 20 Mar 2002 14:52:45 -0500 (EST) Message-Id: <4.3.2.7.2.20020320143806.01d02d48@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "ramsrm@tdd.sj.nec.com" From: Jeff Learman Subject: Re: [Isis-wg] area address in Source NSAP. Cc: "isis-wg@juniper.net" In-Reply-To: <01C1CFFD.B4A9B1A0.ramsrm@tdd.sj.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 20 Mar 2002 19:51:20.0625 (UTC) FILETIME=[9B62CA10:01C1D048] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 20 Mar 2002 14:52:38 -0500 Answer to second question first: You must use the lowest-valued manual area address in your NET. As for the first question, I assume you mean a CLNS user datagram. The rules for network addresses (I forget the ISO doc numbers for "naming and addressing", and "netwok layer addressing") mean that you're not supposed to play mix and match with pieces of NSAP addresses. A system is assigned an NSAP address and should use it. This includes an IS. The implication is that the NSAP for an IS network service user should have an area address matching one of its manual area addresses, but it needn't be the lowest one. Now for the tricky part -- you could probably get away with using any of the dynamic area addresses and it would work. However (a) you'd be breaking the addressing rules, and (b) you'd get into trouble in various dynamic conditions, such as when the area gets partitioned, or when a dynamic area address is dropped. I can't think of any good reason for using a dynamic area address as part of a source NSAP address. While I'm on the soap-box, I should point out another source of confusion concerning IS-IS and NSAP addresses of network service users on the IS. If you have area address A and B, and system ID I, and an NSEL of 1, that means you could have two different NSAP addresses: A-I-1 or B-I-1. According to how IS-IS works, it will deliver packets to either just the same way. HOWEVER, you have no right to assume the CLNS engine and/or Transport implementation on another IS will be able to accept packets with mix-and-match addresses. Some implementations will, some won't. Both are within the letter and spirit of the law. You aren't allowed to play mix-and-match with NSAP addresses, so if you do, be prepared to expect either outcome. This complicates autodiscovery mechanisms based on the IS-IS FDB, for example. Regards, Jeff At 01:55 PM 3/20/2002, ramanathan rams wrote: >hi all, > > I have the following doubt, could u please explain me? > >* we r maintaining 2 area address list in an IS, > * manual area address list and > * another list, which is having all the area addresses present in that >area( formed from L1 LSPs). > > my doubt is, if an IS originates a packet, in the source NSAP field, can >we use an area address such that it is present in the second list but not >in the manual area address list of that IS? > > second doubt is, similar to the frst doubt. When an IS originates the >ISH, 10589 says, we have to use the lowest available area address in the >NET field. For finding the lowest available area address, do we have to >search only the manual area address list or can we search the second list >also? > >thanks >rams. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 21 17:48:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28353 for ; Thu, 21 Mar 2002 17:48:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2LMZ1t77061; Thu, 21 Mar 2002 14:35:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2LMYwt77046 for ; Thu, 21 Mar 2002 14:34:58 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2LMim699029 for ; Thu, 21 Mar 2002 14:44:48 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 14:43:06 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g2LMiXe26141 for ; Thu, 21 Mar 2002 14:44:33 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id OAA05031 for ; Thu, 21 Mar 2002 14:44:27 -0800 (PST) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g2LMdGY04758 for ; Thu, 21 Mar 2002 14:39:16 -0800 (PST) Received: from ems11 (ems11 [131.241.5.62]) by bunny.tdd.sj.nec.com (8.11.3/8.11.6) with SMTP id g2LMdEW27999 for ; Thu, 21 Mar 2002 14:39:14 -0800 (PST) Received: by localhost with Microsoft MAPI; Thu, 21 Mar 2002 14:45:31 -0800 Message-ID: <01C1D0E7.0CEA50B0.ramsrm@tdd.sj.nec.com> From: ramanathan rams Reply-To: "ramsrm@tdd.sj.nec.com" To: "isis-wg@juniper.net" Organization: NEC X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 6 TEXT X-OriginalArrivalTime: 21 Mar 2002 22:43:06.0640 (UTC) FILETIME=[C4A9A100:01C1D129] Subject: [Isis-wg] unnumbered PP i/fs. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Mar 2002 14:45:30 -0800 Hi all, Is there any standard or document explaining how to handle unnumbered Point to Point I/Fs in ISIS for IP? Thanks rams. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 21 18:54:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00539 for ; Thu, 21 Mar 2002 18:54:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2LNg1t77362; Thu, 21 Mar 2002 15:42:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2LNfst77350 for ; Thu, 21 Mar 2002 15:41:54 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2LNph600743 for ; Thu, 21 Mar 2002 15:51:43 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 15:49:30 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2LNpHQ23215; Thu, 21 Mar 2002 18:51:17 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-140.cisco.com [64.102.83.140]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABA51242; Thu, 21 Mar 2002 18:50:55 -0500 (EST) Message-Id: <4.3.2.7.2.20020321183706.039d9a70@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "ramsrm@tdd.sj.nec.com" From: Jeff Learman Subject: Re: [Isis-wg] unnumbered PP i/fs. Cc: "isis-wg@juniper.net" In-Reply-To: <01C1D0E7.0CEA50B0.ramsrm@tdd.sj.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 21 Mar 2002 23:49:30.0187 (UTC) FILETIME=[0B0AA9B0:01C1D133] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Mar 2002 18:37:21 -0500 Does there need to be? At 05:45 PM 3/21/2002, ramanathan rams wrote: >Hi all, > > Is there any standard or document explaining how to handle unnumbered Point to Point I/Fs in ISIS for IP? > >Thanks >rams. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 21 19:58:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01574 for ; Thu, 21 Mar 2002 19:57:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2M0k0t77643; Thu, 21 Mar 2002 16:46:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2M0jkt77631 for ; Thu, 21 Mar 2002 16:45:46 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2M0ta827856 for ; Thu, 21 Mar 2002 16:55:36 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 16:49:59 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g2M0pQe03346; Thu, 21 Mar 2002 16:51:26 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA20211; Thu, 21 Mar 2002 16:51:20 -0800 (PST) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g2M0kAY05776; Thu, 21 Mar 2002 16:46:10 -0800 (PST) Received: from ems11 (ems11 [131.241.5.62]) by bunny.tdd.sj.nec.com (8.11.3/8.11.6) with SMTP id g2M0k8W02967; Thu, 21 Mar 2002 16:46:08 -0800 (PST) Received: by localhost with Microsoft MAPI; Thu, 21 Mar 2002 16:52:25 -0800 Message-ID: <01C1D0F8.C73942D0.ramsrm@tdd.sj.nec.com> From: ramanathan rams Reply-To: "ramsrm@tdd.sj.nec.com" To: "'Jeff Learman'" Cc: "isis-wg@juniper.net" Subject: RE: [Isis-wg] unnumbered PP i/fs. Organization: NEC X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 37 TEXT X-OriginalArrivalTime: 22 Mar 2002 00:50:04.0327 (UTC) FILETIME=[81286B70:01C1D13B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Mar 2002 16:52:25 -0800 hi, If the PP connection between two routers does not have any IP address assigned for their interfaces then we need to have some mechanism by which that unnumbered interface is used in rib calculation. If we don't have any IP address assigned then we cannot advertise the IP address for that interface in hello packet and lsps cannot have any info regarding that interface, so effectively the shortest path via that interface(if one exists)will be missing from everyone's rib right?. or is it already handled in ISIS for IP by some means? OSPF supports this unnumbered PP I/Fs by filling the IfIndex in Router LSA. Thanks rams. -----Original Message----- From: Jeff Learman [SMTP:jlearman@cisco.com] Sent: Thursday, March 21, 2002 3:37 PM To: ramsrm@tdd.sj.nec.com Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] unnumbered PP i/fs. Does there need to be? At 05:45 PM 3/21/2002, ramanathan rams wrote: >Hi all, > > Is there any standard or document explaining how to handle unnumbered Point to Point I/Fs in ISIS for IP? > >Thanks >rams. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 21 21:19:07 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03089 for ; Thu, 21 Mar 2002 21:19:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2M271t78022; Thu, 21 Mar 2002 18:07:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2M26Ut78010 for ; Thu, 21 Mar 2002 18:06:30 -0800 (PST) (envelope-from ramsrm@tdd.sj.nec.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2M2GL603097 for ; Thu, 21 Mar 2002 18:16:21 -0800 (PST) X-JNPR-Received-From: outside Received: from mail4.nec.com ([131.241.15.4]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 18:09:45 -0800 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id g2M2Ace06739; Thu, 21 Mar 2002 18:10:38 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id SAA28710; Thu, 21 Mar 2002 18:10:33 -0800 (PST) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com (8.11.6/8.11.6) with ESMTP id g2M25MY06431; Thu, 21 Mar 2002 18:05:23 -0800 (PST) Received: from ems11 (ems11 [131.241.5.62]) by bunny.tdd.sj.nec.com (8.11.3/8.11.6) with SMTP id g2M25LW05064; Thu, 21 Mar 2002 18:05:21 -0800 (PST) Received: by localhost with Microsoft MAPI; Thu, 21 Mar 2002 18:11:38 -0800 Message-ID: <01C1D103.D7E9B7D0.ramsrm@tdd.sj.nec.com> From: ramanathan rams Reply-To: "ramsrm@tdd.sj.nec.com" To: "'Jeff Parker'" Cc: "isis-wg@juniper.net" Subject: RE: [Isis-wg] unnumbered PP i/fs. Organization: NEC X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Encoding: 44 TEXT X-OriginalArrivalTime: 22 Mar 2002 02:09:45.0343 (UTC) FILETIME=[A2DD90F0:01C1D146] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 21 Mar 2002 18:11:37 -0800 hi, Thanks for the info, I have used this info, to do the SPF calculation and unnumbered link is also included in the SPF calculation. I didn't realize the IS neighbour used in LSP with which we can find the SPF eventhough the IP Internal Reachability info for that unnumbered link won't be there in neighbour's LSP. thanks rams. -----Original Message----- From: Jeff Parker [SMTP:jparker@axiowave.com] Sent: Thursday, March 21, 2002 5:02 PM To: 'ramsrm@tdd.sj.nec.com' Subject: RE: [Isis-wg] unnumbered PP i/fs. > hi, > > If the PP connection between two routers does not have > any IP address > assigned for their interfaces then we need to have some > mechanism by which > that unnumbered interface is used in rib calculation. > If we don't have any IP address assigned then we cannot > advertise the IP > address for that interface in hello packet and lsps cannot > have any info > regarding that interface, so effectively the shortest path via that > interface(if one exists)will be missing from everyone's rib > right?. or is > it already handled in ISIS for IP by some means? > OSPF supports this unnumbered PP I/Fs by filling the IfIndex > in Router LSA. > > Thanks > rams. What is your concern - the basic connectivity, which is provided by sending the SysIDs around, or how the routers forward? - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 21 23:25:16 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08075 for ; Thu, 21 Mar 2002 23:25:14 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2M4D1t78608; Thu, 21 Mar 2002 20:13:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2M4Cat78596 for ; Thu, 21 Mar 2002 20:12:36 -0800 (PST) (envelope-from kaushik_ari@rediffmail.com) 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 g2M4MR832014 for ; Thu, 21 Mar 2002 20:22:27 -0800 (PST) X-JNPR-Received-From: outside Received: from mailweb20.rediffmail.com ([203.199.83.144]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 20:18:46 -0800 Received: (qmail 18658 invoked by uid 510); 22 Mar 2002 04:17:35 -0000 Message-ID: <20020322041735.18657.qmail@mailweb20.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 22 Mar 2002 04:17:35 -0000 MIME-Version: 1.0 From: "aridaman kaushik" Reply-To: "aridaman kaushik" To: "isis-wg@juniper.net" Content-type: text/plain; format=flowed Content-Disposition: inline X-OriginalArrivalTime: 22 Mar 2002 04:19:02.0703 (UTC) FILETIME=[B29CC3F0:01C1D158] Subject: [Isis-wg] Ipv6 Draft Problem. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: 22 Mar 2002 04:17:35 -0000 hi all, The draft For Ipv6 version 2 is totally failure. It is not accordance with ISO 10589. It supports 32 bit default metric. In ISO 10589, neighbour TLVs are having 8 metric inormation. in present case for ipv4/iso, we are sending same 8 bit metric infomation, but We have to maintain separate metrics for ipv4/iso and ip6 separately due to their range difference? So how this will be tackled for ipv6?. In neighbiour TLV we are sending 8 bit metrics information, but in ipv6 reachiability, we will be sending 32 bit metric, SPF calculation fails here.? I think, either neighbour IS6 TLV should be provided or some sub TLV in ipv6 reachiability TLV should be added to make it compatible with existing ipv4/iso implementation or ipv6 reachiability should also contain 8 bit metric infomation. thanks in advance ari. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 22 09:23:00 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22134 for ; Fri, 22 Mar 2002 09:23:00 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2MEB0t81467; Fri, 22 Mar 2002 06:11:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2MEAvt81455 for ; Fri, 22 Mar 2002 06:10:57 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2MEKp611848 for ; Fri, 22 Mar 2002 06:20:51 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Mar 2002 06:16:52 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2MEIfu02629; Fri, 22 Mar 2002 09:18:41 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn1-563.cisco.com [10.82.226.51]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABA61885; Fri, 22 Mar 2002 09:18:18 -0500 (EST) Message-Id: <4.3.2.7.2.20020322085740.01d13f58@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "ramsrm@tdd.sj.nec.com" From: Jeff Learman Subject: RE: [Isis-wg] unnumbered PP i/fs. Cc: "isis-wg@juniper.net" In-Reply-To: <01C1D0F8.C73942D0.ramsrm@tdd.sj.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 22 Mar 2002 14:16:52.0311 (UTC) FILETIME=[36909670:01C1D1AC] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 22 Mar 2002 09:00:37 -0500 Rams, What does the PPP link connect to? Presumably it's an IS, so you advertise that IS as an IS neighbor. Then, when SPF is run, you will find you're connected to everything that the other router is connected to, using that PPP link. Jeff At 07:52 PM 3/21/2002, ramanathan rams wrote: >hi, > > If the PP connection between two routers does not have any IP address >assigned for their interfaces then we need to have some mechanism by which >that unnumbered interface is used in rib calculation. >If we don't have any IP address assigned then we cannot advertise the IP >address for that interface in hello packet and lsps cannot have any info >regarding that interface, so effectively the shortest path via that >interface(if one exists)will be missing from everyone's rib right?. or is >it already handled in ISIS for IP by some means? >OSPF supports this unnumbered PP I/Fs by filling the IfIndex in Router LSA. > >Thanks >rams. > >-----Original Message----- >From: Jeff Learman [SMTP:jlearman@cisco.com] >Sent: Thursday, March 21, 2002 3:37 PM >To: ramsrm@tdd.sj.nec.com >Cc: isis-wg@juniper.net >Subject: Re: [Isis-wg] unnumbered PP i/fs. > > >Does there need to be? > >At 05:45 PM 3/21/2002, ramanathan rams wrote: >>Hi all, >> >> Is there any standard or document explaining how to handle >unnumbered Point to Point I/Fs in ISIS for IP? >> >>Thanks >>rams. >> >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@spider.juniper.net >>http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 02:18:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04681 for ; Mon, 25 Mar 2002 02:18:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P751t00196; Sun, 24 Mar 2002 23:05:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P74Tt00180 for ; Sun, 24 Mar 2002 23:04:29 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2P7Ee649926 for ; Sun, 24 Mar 2002 23:14:40 -0800 (PST) X-JNPR-Received-From: outside Received: from web11207.mail.yahoo.com ([216.136.131.189]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 24 Mar 2002 23:11:53 -0800 Message-ID: <20020325071325.69853.qmail@web11207.mail.yahoo.com> Received: from [203.196.145.150] by web11207.mail.yahoo.com via HTTP; Sun, 24 Mar 2002 23:13:25 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1208872431-1017040405=:68872" X-OriginalArrivalTime: 25 Mar 2002 07:11:53.0875 (UTC) FILETIME=[578D4630:01C1D3CC] Subject: [Isis-wg] few doubts on LSP purging Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 24 Mar 2002 23:13:25 -0800 (PST) --0-1208872431-1017040405=:68872 Content-Type: text/plain; charset=us-ascii Hi All, ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining life time we should retain the header in the database for ZeroAgeLifetime and if we are purging because of any other reson we have to retain the header in the database for MaxAge. Am I correct in assuming that the purging of old Designated IS's pseudoNode LSP by the new Designated system and the purging of local pseudonode LSP when the system is resigning as designated system are two such situations, where we are purging eventhough the remaining life time has not become zero? My doubts are as follows: 1. What exactly is the purpose of retaining the header for MaxAge ? 2. What are the things for which we should'nt use such an aged out LSP retained in our database and what are the things for which the LSP can be used? 3. Can we include it in CSNPs? 4. Can we consider them while doing look up in the database (for eg: while trying to add entry into database) . If we do consider and if the IS becomes Designated IS again, before the pseudoNode LSPs from the earlier stint as Designated IS are removed from the LS database A. What should be done, with the header of the aged out pseudonode LSPs retained in the database? B.Should we take the sequence number of the aged out LSP into consideration while generating the new pseudonode LSP? Thanks in advance. Aravind --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1208872431-1017040405=:68872 Content-Type: text/html; charset=us-ascii

Hi All,

ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining
life time we should retain the header in  the database for ZeroAgeLifetime
and  if we are purging because of any other reson we have to retain the
header in the database for MaxAge.

Am I correct in assuming that the purging of old Designated IS's pseudoNode
LSP by the new Designated system and the purging of local pseudonode LSP
when the system is resigning as designated system are two such situations,
where we are purging eventhough the remaining life time has not become zero?

My doubts are as follows:

1. What exactly is the purpose of retaining the header for MaxAge ?

2. What are the things for which we should'nt use such an aged out LSP retained
   in our database and what are the things for which the LSP  can be used?

3. Can we include it in CSNPs?

4. Can we consider them while doing look up in the database (for eg: while
   trying to add entry into database) . If we do consider and if the IS
   becomes Designated IS again, before the pseudoNode LSPs from the earlier
   stint as Designated IS are removed from the LS database

   A. What should be done, with the header of the aged out pseudonode LSPs
       retained in the database?

   B.Should we take the sequence number of the aged out LSP into consideration
      while generating the new pseudonode LSP?


Thanks in advance.

Aravind


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1208872431-1017040405=:68872-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 04:13:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05798 for ; Mon, 25 Mar 2002 04:13:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P901t00750; Mon, 25 Mar 2002 01:00:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P8xSt00732 for ; Mon, 25 Mar 2002 00:59:28 -0800 (PST) (envelope-from mshand@cisco.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2P99d651513 for ; Mon, 25 Mar 2002 01:09:39 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 01:07:38 -0800 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp143.cisco.com [10.50.0.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA10910; Mon, 25 Mar 2002 09:09:06 GMT Message-Id: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Aravind Ravikumar From: mike shand Subject: Re: [Isis-wg] few doubts on LSP purging Cc: isis-wg@juniper.net In-Reply-To: <20020325071325.69853.qmail@web11207.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 25 Mar 2002 09:07:38.0343 (UTC) FILETIME=[82C6FF70:01C1D3DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2P8xSt00733 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 09:08:59 +0000 Content-Transfer-Encoding: 8bit At 23:13 24/03/2002 -0800, Aravind Ravikumar wrote: >Hi All, > >ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining >life time we should retain the header in the database for ZeroAgeLifetime >and if we are purging because of any other reson we have to retain the >header in the database for MaxAge. > >Am I correct in assuming that the purging of old Designated IS's pseudoNode >LSP by the new Designated system and the purging of local pseudonode LSP >when the system is resigning as designated system are two such situations, >where we are purging eventhough the remaining life time has not become zero? Yes >My doubts are as follows: > >1. What exactly is the purpose of retaining the header for MaxAge ? Because if the network partitions such that some copies of the old LSP are left unpurged, and then the partition is healed, there must be a purge header still alive to cause those LSPs to be properly purged. Note that the strict requirement in all cases is that the purge header is retained for the maximum possible lifetime of any copy of the LSP in the network. So you COULD use just the actual remaining lifetime (plus a bit). This becomes interesting when we consider having variable max lifetimes. >2. What are the things for which we should'nt use such an aged out LSP >retained > in our database and what are the things for which the LSP can be used? Nothing and everything. You use it exactly as a normal LSP. Of course it won't have any data, so you wouldn't use it in an SPF, but you wouldn't do that anyway since npobody else's LSP would point to it. >3. Can we include it in CSNPs? >Yes you MUST. >4. Can we consider them while doing look up in the database (for eg: while > trying to add entry into database) . If we do consider and if the IS > becomes Designated IS again, before the pseudoNode LSPs from the earlier > stint as Designated IS are removed from the LS database I'm not quite sure what you mean by this. Can you re-phrase the question? > A. What should be done, with the header of the aged out pseudonode LSPs > retained in the database? It will get overwritten by the NEW version > B.Should we take the sequence number of the aged out LSP into > consideration > while generating the new pseudonode LSP? Yes if you have it, but you don't have to, since if you start at 1 and there are any old copies of the purge header out there, they will cause their sequence number to be propagated back to you, and you will then automatically issue your new LSP with the next highest number. i.e. it all just works. Mike >Thanks in advance. > >Aravind > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 04:25:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05892 for ; Mon, 25 Mar 2002 04:25:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P9D1t00830; Mon, 25 Mar 2002 01:13:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P9CQt00818 for ; Mon, 25 Mar 2002 01:12:26 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2P9Mc651610 for ; Mon, 25 Mar 2002 01:22:38 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 01:20:11 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id 69BB934432; Mon, 25 Mar 2002 01:25:33 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2P9LgvM026886; Mon, 25 Mar 2002 01:21:42 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2P9Lg4C001664; Mon, 25 Mar 2002 01:21:42 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15518.60454.503308.514679@alpha-tli.procket.com> To: mike shand Cc: Aravind Ravikumar , isis-wg@juniper.net Subject: Re: [Isis-wg] few doubts on LSP purging In-Reply-To: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> References: <20020325071325.69853.qmail@web11207.mail.yahoo.com> <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 25 Mar 2002 09:20:11.0500 (UTC) FILETIME=[43B1A2C0:01C1D3DE] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 01:21:42 -0800 Content-Transfer-Encoding: 7bit | >3. Can we include it in CSNPs? | | Yes you MUST. Interesting. Why? Omitting the LSP from the CSNP is an indication of not having valid information for the LSP, which should be identical to including it with zero lifetime. Tony p.s. Dave, warm up a PR for me... ;-) _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 04:27:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05912 for ; Mon, 25 Mar 2002 04:27:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P9F0t00865; Mon, 25 Mar 2002 01:15:00 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P9Eut00850 for ; Mon, 25 Mar 2002 01:14:56 -0800 (PST) (envelope-from tli@procket.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2P9P7887129 for ; Mon, 25 Mar 2002 01:25:07 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz1.procket.com ([65.174.124.36]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 01:16:40 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz1.procket.com (Postfix) with ESMTP id 4188223C2C; Mon, 25 Mar 2002 01:07:57 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2P9IBvM026783; Mon, 25 Mar 2002 01:18:11 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2P9IBd8001660; Mon, 25 Mar 2002 01:18:11 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15518.60243.358599.281794@alpha-tli.procket.com> To: Aravind Ravikumar Cc: isis-wg@juniper.net Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <20020325071325.69853.qmail@web11207.mail.yahoo.com> References: <20020325071325.69853.qmail@web11207.mail.yahoo.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 25 Mar 2002 09:16:40.0234 (UTC) FILETIME=[C5C500A0:01C1D3DD] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 01:18:11 -0800 Content-Transfer-Encoding: 7bit | Am I correct in assuming that the purging of old Designated IS's pseudoNode | LSP by the new Designated system and the purging of local pseudonode LSP | when the system is resigning as designated system are two such situations, | where we are purging eventhough the remaining life time has not become zero? A fine example. | My doubts are as follows: | | 1. What exactly is the purpose of retaining the header for MaxAge ? It's been demonstrated quite conclusively with extensive field experience that if a node does not retain the header and simply flush it, then the node will somehow relearn the LSP through some peer and reinstate it. It then purges it and the cycle continues. | 2. What are the things for which we should'nt use such an aged out LSP | retained | in our database and what are the things for which the LSP can be used? There is no point in using it for anything other than a fine indication that you don't want to relearn it. | 3. Can we include it in CSNPs? Not adviseable. I'd bet that it's against the letter of the law and in any case it would not help anything to advertise it. | 4. Can we consider them while doing look up in the database (for eg: while | trying to add entry into database) . If we do consider and if the IS | becomes Designated IS again, before the pseudoNode LSPs from the earlier | stint as Designated IS are removed from the LS database | | B.Should we take the sequence number of the aged out LSP into | consideration while generating the new pseudonode LSP? Absolutely. Despite the purge, there will be some system out there somewhere that has hung onto the old LSP. | A. What should be done, with the header of the aged out pseudonode LSPs | retained in the database? I would compare the newly received LSP against the aged out header and perform standard sequence number checks. This should discard duplicate echos of what was just purged. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 05:02:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06177 for ; Mon, 25 Mar 2002 05:02:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P9o1t01065; Mon, 25 Mar 2002 01:50:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2P9nct01050 for ; Mon, 25 Mar 2002 01:49:38 -0800 (PST) (envelope-from mshand@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2P9xo651959 for ; Mon, 25 Mar 2002 01:59:50 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 01:57:39 -0800 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp143.cisco.com [10.50.0.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA12349; Mon, 25 Mar 2002 09:59:06 GMT Message-Id: <4.3.2.7.2.20020325093543.035bd008@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Li From: mike shand Subject: Re: [Isis-wg] few doubts on LSP purging Cc: Aravind Ravikumar , isis-wg@juniper.net In-Reply-To: <15518.60454.503308.514679@alpha-tli.procket.com> References: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> <20020325071325.69853.qmail@web11207.mail.yahoo.com> <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 25 Mar 2002 09:57:40.0155 (UTC) FILETIME=[7FFF28B0:01C1D3E3] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 09:58:34 +0000 At 01:21 25/03/2002 -0800, Tony Li wrote: > | >3. Can we include it in CSNPs? > | > | Yes you MUST. > > >Interesting. Why? > >Omitting the LSP from the CSNP is an indication of not having valid >information for the LSP, which should be identical to including it with >zero lifetime. Its not quite the same as having no information. It says "I have no information and YOU shouldn't have any either". SO suppose the DR has a purge header for an LSP. Some other router on the LAN has the full copy. It sends that out on the LAN and the DR realizes that it has a newer version (i.e. the purge has half a bit more sequence number), so it floods it on the LAN. But the packet gets lost. Oh OK, maybe you are right. The CSNP claims nothing, so the other router re-sends its full copy, which causes the DR to resend the purge. I guess it all gets sorted out in the end. But its slightly "unnatural". But my immediate reaction was that you should always do the normal thing and not special case the purge header. As far as the update process is concerned, the only interesting thing about a purge header is that it appears to be newer than a non-purged LSP with the same sequence number. The only special casing that I know about is that you must not set SRMflags for a zero sequence number "LSP". Mike >Tony > >p.s. Dave, warm up a PR for me... ;-) _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 05:35:21 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06393 for ; Mon, 25 Mar 2002 05:35:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PAM1t01226; Mon, 25 Mar 2002 02:22:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PAL0t01214 for ; Mon, 25 Mar 2002 02:21:00 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2PAVC652383 for ; Mon, 25 Mar 2002 02:31:12 -0800 (PST) X-JNPR-Received-From: outside Received: from web11202.mail.yahoo.com ([216.136.131.184]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 02:28:48 -0800 Message-ID: <20020325103020.92920.qmail@web11202.mail.yahoo.com> Received: from [203.196.145.150] by web11202.mail.yahoo.com via HTTP; Mon, 25 Mar 2002 02:30:20 PST From: Aravind Ravikumar Subject: Re: [Isis-wg] few doubts on LSP purging To: mike shand Cc: isis-wg@juniper.net In-Reply-To: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-771338235-1017052220=:90002" X-OriginalArrivalTime: 25 Mar 2002 10:28:48.0859 (UTC) FILETIME=[D9D4C2B0:01C1D3E7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 02:30:20 -0800 (PST) --0-771338235-1017052220=:90002 Content-Type: text/plain; charset=us-ascii Hi Mike, Thanks for the reply and now I have understood the issues, but for a small clarifcation. If an IS finds out, while processing the CSNP (which includes the aged out entry in it) from a DIS, that it is not having the aged out LSP in its database or is having an older copy, then it will make a request for the LSP in its next PSNP. But since only the header of the aged out LSP is sent in response to the PSNP, won't it be rejected because of authentication faliure, in case authentication is configured and this sequence will keep on repeating. Am I right or wrong, please clarify? >>4. Can we consider them while doing look up in the database (for eg: while >> trying to add entry into database) . If we do consider and if the IS >> becomes Designated IS again, before the pseudoNode LSPs from the earlier >> stint as Designated IS are removed from the LS database >I'm not quite sure what you mean by this. Can you re-phrase the question? Sorry for putting the above question in a wrong way in my earlier mail. Any way its more to the implementation side and is clear now from your answers to the two questions that followed it. I was trying to describe a situation followed by the doubts on that. I'll put the situation in a proper way as follows System A is Designated IS for a LAN System B comes up and becomes the designated IS Now the pseudonode LSPs generated by A will be purged and the headers will be retained. System B goes down and system A again becomes the designated IS. A is still having the headers of the old pseudonode LSPs,which it comes across while trying to add the new pseudonode LSPs to the database It was in this context I asked the other two questions Aravind --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-771338235-1017052220=:90002 Content-Type: text/html; charset=us-ascii

Hi Mike,

Thanks for the reply and now I have understood the issues, but for a small clarifcation.

If an IS finds out, while processing the CSNP (which includes the aged out entry in it) from a DIS, that

it is not having the aged out LSP in its database or is having an older copy, then it will make a request for the LSP

in its next PSNP. But since only the header of the aged out LSP is sent in response to the PSNP, won't

it be rejected because of authentication faliure, in case authentication is configured and this sequence will keep on

repeating. Am I right or wrong, please clarify?

>>4. Can we consider them while doing look up in the database (for eg: while
>> trying to add entry into database) . If we do consider and if the IS
>> becomes Designated IS again, before the pseudoNode LSPs from the earlier
>> stint as Designated IS are removed from the LS database

>I'm not quite sure what you mean by this. Can you re-phrase the question?

Sorry for putting the above question in a wrong way in my earlier mail. Any way its more to the implementation

side and is clear now from your answers to the two questions that followed it. I was trying to describe

a situation followed by the doubts on that.

I'll put the situation in a proper way as follows

System A is Designated IS for a LAN

System B comes up and becomes the designated IS

Now the pseudonode LSPs generated by A will be purged and the headers will be retained.

System B goes down and system A again becomes the designated IS.

A is still having the headers of the old pseudonode LSPs,which it comes across while

trying to add the new pseudonode LSPs to the database

It was in this context I asked the other two questions

Aravind


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-771338235-1017052220=:90002-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 05:36:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06414 for ; Mon, 25 Mar 2002 05:36:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PAO1t01253; Mon, 25 Mar 2002 02:24:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PANft01239 for ; Mon, 25 Mar 2002 02:23:41 -0800 (PST) (envelope-from mshand@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2PAXq888189 for ; Mon, 25 Mar 2002 02:33:52 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 02:32:09 -0800 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp143.cisco.com [10.50.0.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA13482; Mon, 25 Mar 2002 10:33:38 GMT Message-Id: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Aravind Ravikumar From: mike shand Subject: Re: [Isis-wg] few doubts on LSP purging Cc: isis-wg@juniper.net In-Reply-To: <20020325103020.92920.qmail@web11202.mail.yahoo.com> References: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 25 Mar 2002 10:32:09.0984 (UTC) FILETIME=[51B60000:01C1D3E8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2PANft01240 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 10:33:34 +0000 Content-Transfer-Encoding: 8bit At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote: >Hi Mike, > >Thanks for the reply and now I have understood the issues, but for a small >clarifcation. > >If an IS finds out, while processing the CSNP (which includes the aged out >entry in it) from a DIS, that > >it is not having the aged out LSP in its database or is having an older >copy, then it will make a request for the LSP > >in its next PSNP. But since only the header of the aged out LSP is sent in >response to the PSNP, won't > >it be rejected because of authentication faliure, in case authentication >is configured and this sequence will keep on > >repeating. Am I right or wrong, please clarify? No. you have to include authentication even for purge headers. Mike > >>4. Can we consider them while doing look up in the database (for eg: while > >> trying to add entry into database) . If we do consider and if the IS > >> becomes Designated IS again, before the pseudoNode LSPs from the earlier > >> stint as Designated IS are removed from the LS database > > >I'm not quite sure what you mean by this. Can you re-phrase the question? > >Sorry for putting the above question in a wrong way in my earlier mail. >Any way its more to the implementation > >side and is clear now from your answers to the two questions that followed >it. I was trying to describe > >a situation followed by the doubts on that. > >I'll put the situation in a proper way as follows > >System A is Designated IS for a LAN > >System B comes up and becomes the designated IS > >Now the pseudonode LSPs generated by A will be purged and the headers will >be retained. > >System B goes down and system A again becomes the designated IS. > >A is still having the headers of the old pseudonode LSPs,which it comes >across while > >trying to add the new pseudonode LSPs to the database > >It was in this context I asked the other two questions > >Aravind > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 13:40:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25398 for ; Mon, 25 Mar 2002 13:40:51 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PIS1t03748; Mon, 25 Mar 2002 10:28:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PIRPt03736 for ; Mon, 25 Mar 2002 10:27:25 -0800 (PST) (envelope-from dkatz@juniper.net) 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 g2PIbOT60709; Mon, 25 Mar 2002 10:37:24 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g2PIbOf19019; Mon, 25 Mar 2002 10:37:24 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200203251837.g2PIbOf19019@cirrus.juniper.net> From: Dave Katz To: tli@procket.com CC: mshand@cisco.com, aravindravikumar@yahoo.com, isis-wg@juniper.net In-reply-to: <15518.60454.503308.514679@alpha-tli.procket.com> (message from Tony Li on Mon, 25 Mar 2002 01:21:42 -0800) Subject: Re: [Isis-wg] few doubts on LSP purging References: <20020325071325.69853.qmail@web11207.mail.yahoo.com> <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> <15518.60454.503308.514679@alpha-tli.procket.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 10:37:24 -0800 (PST) Omitting the LSP from the CSNP is an indication of not having valid information for the LSP, which should be identical to including it with zero lifetime. Tony p.s. Dave, warm up a PR for me... ;-) I agree with you here; in the partition case, if there's no information on one side of the network and the spent LSP is on the other, everybody's on the same foot; if there is a live LSP on one side and the spent LSP on the other, the live one will be flooded into the other side when the partition heals and the originator (who is presumably on the spent side) will do the right thing. Moreover, this is an optimization, as there's no harm in the stale LSP hanging around (which will only happen if the originator is disconnected from the rest of the network) as it will just take up space in the database until it times out of its own accord. Having said that, many years ago Tony and I got a first-hand education on why holding negative (purged) state is necessary. A certain west coast regional network running OSPF on equipment made by a certain common former employer of ours was having regular network meltdowns of MAXAGE LSAs. Turns out there was a simple and subtle bug in the flooding mechanism (something was being acked when it should have just been dropped, I believe) and the net result was that old MAXAGE LSAs would repeatedly come falling in from the network Oort Cloud and ricochet around inside the network, with several different sequence numbers. The lesson learned from this is that you have to hold onto negative state long enough to make sure that it will never come back to you, so that its flooding damps out (since there is no lifetime limit to this information.) OSPF takes an agressive, but fragile approach to this--if all of your neighbors have acknowledged the purged LSA, then you can toss the state (since those neighbors will not flood it to you again, and by extrapolation their neighbors will not flood it to them, etc.) Works perfectly as long as there's no bug, but it gets really ugly when things aren't quite right. ISIS, because it doesn't use a positive acknowledgement scheme on LANs (a feature) must hold the negative state until it is guaranteed that it has reached all corners of the network; otherwise it could slosh back and forth through the network repeatedly. (I *think* it is guaranteed to stabilize eventually as the LSP wavefronts will cancel one another out, but if you put a flapping link or two into the picture I think you can come up with a somewhat plausible scenario in which it might not ever stop.) Link state protocols are not as simple as they appear, as has been discovered repeatedly by those who have attempted to roll their own. _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 16:56:41 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05165 for ; Mon, 25 Mar 2002 16:56:40 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PLi1t04624; Mon, 25 Mar 2002 13:44:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PLh6t04612 for ; Mon, 25 Mar 2002 13:43:06 -0800 (PST) (envelope-from padma@juniper.net) Received: from padma-bsd.juniper.net (padma-bsd.juniper.net [172.17.12.219]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g2PLrKT73438; Mon, 25 Mar 2002 13:53:20 -0800 (PST) (envelope-from padma@juniper.net) Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.8.8/8.7.3) with ESMTP id NAA27221; Mon, 25 Mar 2002 13:53:20 -0800 (PST) Message-ID: <3C9F9C50.17C598E4@juniper.net> From: Padma Pillay-Esnault Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jparker@axiowave.com CC: padma@juniper.net, isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] About the IS Adjacency Area Address Table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 13:53:20 -0800 Content-Transfer-Encoding: 7bit Jeff I have a couple of questions about the IS Adjacency Area Address Table Index as compared to the IS Adjacency IP Address Table. isisISAdjAreaAddrEntry OBJECT-TYPE SYNTAX IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one Area Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjAreaAddrAdjIndex, <<<<<<<<< (1) isisISAdjAreaAddress } <<<<<<<<< (2) ::= { isisISAdjAreaAddrTable 1 } ----------- isisISAdjIPAddrEntry OBJECT-TYPE SYNTAX IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex, <<<<<<<<<<<<< isisISAdjIPAddrAdjIndex <<<<<<<<<<<<< } ::= { isisISAdjIPAddrTable 1 } Why is it that we have the isisISAdjAreaAddrAdjIndex I believe that the isisISAdjIndex could be used here as well ? We have isisISAdjIPAddrAdjIndex for the ip addresses why not have an index for the area addresses as well. IMHO, this would simplify greatly the code having an index (len 1) instead of the address (len 22) Lastly this would make the two tables consistent. Any light appreciated as to why they are implemented differently Padma _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 17:53:48 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07005 for ; Mon, 25 Mar 2002 17:53:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PMg1t04886; Mon, 25 Mar 2002 14:42:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PMf7t04874 for ; Mon, 25 Mar 2002 14:41:07 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Ramalingam, Swaminathan'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] RE: IS Adjacency table MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 17:50:34 -0500 > Also description for isisISAdjNeighPriority reads like: > > isisISAdjNeighPriority OBJECT-TYPE > SYNTAX ISPriority > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Priority of the neighboring Intermediate System for > becoming the LAN Level 1 Designated Intermediate System > if the value of isisISAdjNeighSysType is > L1IntermediateSystem or LAN Level 2 Designated > Intermediate System if the value of > isisISAdjNeighSysType is L2IntermediateSystem." > REFERENCE "{ISIS.aoi lANPriority (86)}" > ::= { isisISAdjEntry 8 } > > > what it mean when isisISAdjNeighSysType is > "l1l2IntermediateSystem"?. You are right. It is confusing. It is only relevant on a LAN, where there will be an adjacency per level. It may be simplest to simplest to say isisISAdjNeighPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the Designated Intermediate System." REFERENCE "{ISIS.aoi lANPriority (86)}" ::= { isisISAdjEntry 8 } > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object > conveying the message what "type" of adjacency is that (either Level1 or > Level2) I believe that the isisISAdjUsage variable conveys this information. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 18:41:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08174 for ; Mon, 25 Mar 2002 18:41:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PNO1t05081; Mon, 25 Mar 2002 15:24:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PNNvt05069 for ; Mon, 25 Mar 2002 15:23:57 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Padma Pillay-Esnault'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: About the IS Adjacency Area Address Table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 18:34:07 -0500 > Jeff > > I have a couple of questions about the IS Adjacency Area Address Table > Index as compared to > the IS Adjacency IP Address Table. > > Why is it that we have the isisISAdjAreaAddrAdjIndex I believe that > the isisISAdjIndex could be used here as well ? Good suggestion. Done. > > We have isisISAdjIPAddrAdjIndex for the ip addresses why not have an > index for the area addresses as well. > IMHO, this would simplify greatly the code having an index (len 1) > instead of the address (len 22) > > Padma You are not the first person to complain about the efforts needed to walk the Adj Address Table, given that ISO addresses are variable length. I will add an index to simplify implementation. - jeff parker IsisISAdjAreaAddrEntry ::= SEQUENCE { isisISAdjAreaAddrIndex Integer32, isisISAdjAreaAddress OSINSAddress } isisISAdjAreaAddrIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index for the areas associated with one neighbor. This provides a simpler way to walk the table." ::= { isisISAdjAreaAddrEntry 1 } _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 18:48:31 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08471 for ; Mon, 25 Mar 2002 18:48:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PNY1t05138; Mon, 25 Mar 2002 15:34:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PNXSt05126 for ; Mon, 25 Mar 2002 15:33:28 -0800 (PST) (envelope-from padma@juniper.net) Received: from padma-bsd.juniper.net (padma-bsd.juniper.net [172.17.12.219]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g2PNhgT80813; Mon, 25 Mar 2002 15:43:42 -0800 (PST) (envelope-from padma@juniper.net) Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.8.8/8.7.3) with ESMTP id PAA27371; Mon, 25 Mar 2002 15:43:42 -0800 (PST) Message-ID: <3C9FB62E.BD6F072@juniper.net> From: Padma Pillay-Esnault Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "IS-IS-WG (E-mail)" , padma@juniper.net References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Re: About the IS Adjacency Area Address Table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 15:43:42 -0800 Content-Transfer-Encoding: 7bit Jeff I also came up with the same situation with the isisISAdjProtSuppTable we could make all the tables under adjacency consistent by putting the isisISAdjIndex and an index on the entry we are walking Thanks Padma Jeff Parker wrote: > > Jeff > > > > I have a couple of questions about the IS Adjacency Area Address Table > > Index as compared to > > the IS Adjacency IP Address Table. > > > > Why is it that we have the isisISAdjAreaAddrAdjIndex I believe that > > the isisISAdjIndex could be used here as well ? > > Good suggestion. Done. > > > > We have isisISAdjIPAddrAdjIndex for the ip addresses why not have an > > index for the area addresses as well. > > IMHO, this would simplify greatly the code having an index (len 1) > > instead of the address (len 22) > > > > Padma > > You are not the first person to complain about the efforts needed to > walk the Adj Address Table, given that ISO addresses are variable > length. I will add an index to simplify implementation. > > - jeff parker > > IsisISAdjAreaAddrEntry ::= > SEQUENCE { > isisISAdjAreaAddrIndex > Integer32, > isisISAdjAreaAddress > OSINSAddress > } > > isisISAdjAreaAddrIndex OBJECT-TYPE > SYNTAX Integer32 (1..2000000000) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An index for the areas associated with one neighbor. > This provides a simpler way to walk the table." > ::= { isisISAdjAreaAddrEntry 1 } _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 18:57:46 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08721 for ; Mon, 25 Mar 2002 18:57:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PNk0t05261; Mon, 25 Mar 2002 15:46:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2PNjVt05249 for ; Mon, 25 Mar 2002 15:45:31 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Padma Pillay-Esnault'" Cc: "IS-IS-WG (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: About the IS Adjacency Area Address Table Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 18:55:41 -0500 > Jeff > > I also came up with the same situation with the > isisISAdjProtSuppTable we could make all the > tables under adjacency consistent > by putting the isisISAdjIndex Done > and an index on the entry we are walking > > Padma I understand the problems in walking complex types like the new IP address or an OSI address. But help me understand why we need an index to walk a scalar. Isn't this something that GetNext papers over for us? - jeff parker isisISAdjProtSuppEntry OBJECT-TYPE SYNTAX IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by a neighboring Intermediate System as reported in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex, isisISAdjProtSuppProtocol } ::= { isisISAdjProtSuppTable 1 } IsisISAdjProtSuppEntry ::= SEQUENCE { isisISAdjProtSuppProtocol SupportedProtocol } isisISAdjProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "One supported protocol as reported in IIH PDUs received from the neighbor." ::= { isisISAdjProtSuppEntry 1 } -- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 19:19:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09082 for ; Mon, 25 Mar 2002 19:19:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q071t05387; Mon, 25 Mar 2002 16:07:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q06ht05375 for ; Mon, 25 Mar 2002 16:06:43 -0800 (PST) (envelope-from padma@juniper.net) Received: from padma-bsd.juniper.net (padma-bsd.juniper.net [172.17.12.219]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g2Q0GwT83022; Mon, 25 Mar 2002 16:16:58 -0800 (PST) (envelope-from padma@juniper.net) Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.8.8/8.7.3) with ESMTP id QAA27414; Mon, 25 Mar 2002 16:16:58 -0800 (PST) Message-ID: <3C9FBDFA.D6A835BA@juniper.net> From: Padma Pillay-Esnault Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "IS-IS-WG (E-mail)" , padma@juniper.net Subject: Re: [Isis-wg] RE: About the IS Adjacency Area Address Table References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 16:16:58 -0800 Content-Transfer-Encoding: 7bit Jeff Parker wrote: > > > Jeff > > > > I also came up with the same situation with the > > isisISAdjProtSuppTable we could make all the > > tables under adjacency consistent > > by putting the isisISAdjIndex > > Done > > > and an index on the entry we are walking > > > > Padma > > I understand the problems in walking complex types > like the new IP address or an OSI address. But > help me understand why we need an index to walk > a scalar. Isn't this something that GetNext papers > over for us? I was thinking of a list built from the tlv which is not necessarily ordered . Then it is easier to to code a lookup on an index than run thru the list to find the next entry based on the value ... I guess I could do that differently. May be I am uniformizing too much ;-) Padma > > - jeff parker > > isisISAdjProtSuppEntry OBJECT-TYPE > SYNTAX IsisISAdjProtSuppEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry contains one protocol supported by a > neighboring Intermediate System as reported in its IIH > PDUs." > INDEX { isisSysInstance, > isisCircIndex, > isisISAdjIndex, > isisISAdjProtSuppProtocol } > ::= { isisISAdjProtSuppTable 1 } > > IsisISAdjProtSuppEntry ::= > SEQUENCE { > isisISAdjProtSuppProtocol > SupportedProtocol > } > > isisISAdjProtSuppProtocol OBJECT-TYPE > SYNTAX SupportedProtocol > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "One supported protocol as reported in IIH PDUs received > from the neighbor." > ::= { isisISAdjProtSuppEntry 1 } > -- > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 19:46:23 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09433 for ; Mon, 25 Mar 2002 19:46:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q0Y1t05520; Mon, 25 Mar 2002 16:34:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q0XUt05508 for ; Mon, 25 Mar 2002 16:33:30 -0800 (PST) (envelope-from lliu@chiaro.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2Q0hj669445 for ; Mon, 25 Mar 2002 16:43:45 -0800 (PST) X-JNPR-Received-From: outside Received: from rchss001.chiaro.com ([63.88.196.81]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 16:41:34 -0800 Received: (qmail 7779 invoked from network); 26 Mar 2002 00:37:05 -0000 Received: from rchss001.chiaro.com (HELO mail.chiaro.com) (63.88.196.81) by rchss001.chiaro.com with SMTP; 26 Mar 2002 00:37:05 -0000 Received: by MAIL with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 18:42:23 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A50701F451AD@MAIL> From: Laura Liu To: Aravind Ravikumar , isis-wg@juniper.net Subject: RE: [Isis-wg] few doubts on LSP purging MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="--ISVW_ISUX_boundary" X-OriginalArrivalTime: 26 Mar 2002 00:41:34.0640 (UTC) FILETIME=[FB035B00:01C1D45E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 18:42:22 -0600 ----ISVW_ISUX_boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D45F.17802420" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D45F.17802420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 To add another situation: router A has multiple LSP fragments of router = B, when router B made some changes, purged it LSPs and the new lsp can fit = into one pdu (lsp #0), router A need to purge the old lsp fragments (lsp #1 = and above), those lsp headers should be retained in the database for = MaxAge. =20 Am I right? =20 thanks in advance! =20 Laura -----Original Message-----=20 From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, March 25, 2002 1:13 AM To: isis-wg@juniper.net Subject: [Isis-wg] few doubts on LSP purging Hi All, ISO 10589 section 7.3.16.4 says when we purge an LSP with zero = remaining=20 life time we should retain the header in the database for = ZeroAgeLifetime and if we are purging because of any other reson we have to retain the = header in the database for MaxAge. Am I correct in assuming that the purging of old Designated IS's = pseudoNode LSP by the new Designated system and the purging of local pseudonode = LSP=20 when the system is resigning as designated system are two such = situations, where we are purging eventhough the remaining life time has not become = zero? My doubts are as follows: 1. What exactly is the purpose of retaining the header for MaxAge ? 2. What are the things for which we should'nt use such an aged out LSP retained in our database and what are the things for which the LSP can be = used? 3. Can we include it in CSNPs? 4. Can we consider them while doing look up in the database (for eg: = while trying to add entry into database) . If we do consider and if the IS = becomes Designated IS again, before the pseudoNode LSPs from the = earlier stint as Designated IS are removed from the LS database=20 A. What should be done, with the header of the aged out pseudonode = LSPs retained in the database? B.Should we take the sequence number of the aged out LSP into consideration while generating the new pseudonode LSP? Thanks in advance. Aravind _____ =20 Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards=AE ------_=_NextPart_001_01C1D45F.17802420 Content-Type: text/html; charset="iso-8859-1"
Hi All,
 
To add another situation: router A has multiple LSP fragments of router B, when router B made some changes, purged it LSPs and the new lsp can fit into one pdu (lsp #0), router A need to purge the old lsp fragments (lsp #1 and above), those lsp headers should be retained in the database for MaxAge.
 
Am I right?
 
thanks in advance!
 
Laura
-----Original Message----- 
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, March 25, 2002 1:13 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] few doubts on LSP purging

Hi All,

ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining
life time we should retain the header in  the database for ZeroAgeLifetime
and  if we are purging because of any other reson we have to retain the
header in the database for MaxAge.

Am I correct in assuming that the purging of old Designated IS's pseudoNode
LSP by the new Designated system and the purging of local pseudonode LSP
when the system is resigning as designated system are two such situations,
where we are purging eventhough the remaining life time has not become zero?

My doubts are as follows:

1. What exactly is the purpose of retaining the header for MaxAge ?

2. What are the things for which we should'nt use such an aged out LSP retained
   in our database and what are the things for which the LSP  can be used?

3. Can we include it in CSNPs?

4. Can we consider them while doing look up in the database (for eg: while
   trying to add entry into database) . If we do consider and if the IS
   becomes Designated IS again, before the pseudoNode LSPs from the earlier
   stint as Designated IS are removed from the LS database

   A. What should be done, with the header of the aged out pseudonode LSPs
       retained in the database?

   B.Should we take the sequence number of the aged out LSP into consideration
      while generating the new pseudonode LSP?


Thanks in advance.

Aravind


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
------_=_NextPart_001_01C1D45F.17802420-- ----ISVW_ISUX_boundary Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit ----------------------------------------- (on rchss001) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- ----ISVW_ISUX_boundary-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 20:15:45 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10073 for ; Mon, 25 Mar 2002 20:15:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q131t05712; Mon, 25 Mar 2002 17:03:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q12Ot05700 for ; Mon, 25 Mar 2002 17:02:24 -0800 (PST) (envelope-from prz@redback.com) 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 g2Q1Cd808145 for ; Mon, 25 Mar 2002 17:12:39 -0800 (PST) X-JNPR-Received-From: outside Received: from mta7.pltn13.pbi.net ([64.164.98.8]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 17:10:40 -0800 Received: from redback.com ([63.200.51.130]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GTK00DQS3AO8G@mta7.pltn13.pbi.net> for isis-wg@juniper.net; Mon, 25 Mar 2002 17:11:13 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] few doubts on LSP purging To: Laura Liu Cc: Aravind Ravikumar , isis-wg@juniper.net Message-id: <3C9FAB7A.7AD3DD6D@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: <2383E22BDFF6D311BB8400B0D021A50701F451AD@MAIL> X-OriginalArrivalTime: 26 Mar 2002 01:10:40.0687 (UTC) FILETIME=[0BBCFBF0:01C1D463] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 14:58:03 -0800 Content-Transfer-Encoding: 7BIT Laura Liu wrote: > Hi All,To add another situation: router A has multiple LSP fragments of router B, when router > B made some changes, purged it LSPs and the new lsp can fit into one pdu (lsp #0), router A > need to purge the old lsp fragments (lsp #1 and above), those lsp headers should be retained > in the database for MaxAge. > > you do not 'compact' fragments into a single fragment again. That would make the semantics of > information > deletion/addition within fragments hard to track and would lead to extensive flapping of e.g. > prefixes if you're > unlucky. > > > Each fragment is basically an independent entity when it comes to flooding and purging > > thanks > > > > -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 20:54:13 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10859 for ; Mon, 25 Mar 2002 20:54:11 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1g1t05906; Mon, 25 Mar 2002 17:42:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1fWt05894 for ; Mon, 25 Mar 2002 17:41:32 -0800 (PST) (envelope-from rayq@riverstonenet.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2Q1pm670725 for ; Mon, 25 Mar 2002 17:51:48 -0800 (PST) X-JNPR-Received-From: outside Received: from exc-sc1.yagosys.com ([63.113.148.3]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 17:48:22 -0800 Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 17:48:59 -0800 Message-ID: <329F35B18824D511B9C30008C73395583300@exc-sc1> From: "Qiu, Ray" To: "'isis-wg@juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" X-OriginalArrivalTime: 26 Mar 2002 01:48:22.0780 (UTC) FILETIME=[500CFBC0:01C1D468] Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 17:48:57 -0800 Hi, I got one stupid question about this draft. It seems that MT ID are 12 bits as defined in the draft. But the reserved MT ID value is up to 8191. How can we get to 8191 by using 12 bits? Thanks, Ray _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 20:54:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10883 for ; Mon, 25 Mar 2002 20:54:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1h1t05930; Mon, 25 Mar 2002 17:43:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from exc-sc1.yagosys.com (host3.riverstonenet.com [63.113.148.3]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1gYt05912 for ; Mon, 25 Mar 2002 17:42:34 -0800 (PST) (envelope-from rayq@riverstonenet.com) Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 17:51:54 -0800 Message-ID: <329F35B18824D511B9C30008C73395583301@exc-sc1> From: "Qiu, Ray" To: "'isis-wg@spider.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 17:51:53 -0800 Hi, I got one stupid question about this draft. It seems that MT ID are 12 bits as defined in the draft. But the reserved MT ID value is up to 8191. How can we get to 8191 by using 12 bits? Thanks, Ray _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 20:57:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10979 for ; Mon, 25 Mar 2002 20:57:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1k1t05963; Mon, 25 Mar 2002 17:46:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.227.69]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1jet05951 for ; Mon, 25 Mar 2002 17:45:40 -0800 (PST) (envelope-from svemulap@cisco.com) Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.102.160]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA12576; Mon, 25 Mar 2002 17:55:54 -0800 (PST) From: Shankar Vemulapalli To: "Qiu, Ray" cc: "'isis-wg@spider.juniper.net'" Subject: Re: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt In-Reply-To: <329F35B18824D511B9C30008C73395583301@exc-sc1> 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@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 17:55:52 -0800 (PST) This has already been pointed out ... and I believe Naiming is taking care of it in the next version :-) /Shankar At 5:51pm 03/25/02 -0800, Qiu, Ray wrote: > Hi, > > I got one stupid question about this draft. > > It seems that MT ID are 12 bits as defined in the draft. But the reserved > MT ID > value is up to 8191. How can we get to 8191 by using 12 bits? > > Thanks, > Ray > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Mar 25 21:00:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11149 for ; Mon, 25 Mar 2002 21:00:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1n1t05993; Mon, 25 Mar 2002 17:49:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from exc-sc1.yagosys.com (host3.riverstonenet.com [63.113.148.3]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q1mWt05981 for ; Mon, 25 Mar 2002 17:48:32 -0800 (PST) (envelope-from rayq@riverstonenet.com) Received: by exc-sc1 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 17:57:52 -0800 Message-ID: <329F35B18824D511B9C30008C73395583302@exc-sc1> From: "Qiu, Ray" To: "'Shankar Vemulapalli'" , "Qiu, Ray" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.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@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 17:57:52 -0800 Shankar, Thanks. Sorry that I didn't know. :) Ray -----Original Message----- From: Shankar Vemulapalli [mailto:svemulap@cisco.com] Sent: Monday, March 25, 2002 5:56 PM To: Qiu, Ray Cc: 'isis-wg@spider.juniper.net' Subject: Re: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt This has already been pointed out ... and I believe Naiming is taking care of it in the next version :-) /Shankar At 5:51pm 03/25/02 -0800, Qiu, Ray wrote: > Hi, > > I got one stupid question about this draft. > > It seems that MT ID are 12 bits as defined in the draft. But the reserved > MT ID > value is up to 8191. How can we get to 8191 by using 12 bits? > > Thanks, > Ray > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 00:18:40 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16393 for ; Tue, 26 Mar 2002 00:18:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q561t06905; Mon, 25 Mar 2002 21:06:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q55Xt06893 for ; Mon, 25 Mar 2002 21:05:33 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 00:15:49 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Jeff Parker'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] RE: IS Adjacency table MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 00:15:45 -0500 See Inline > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Tuesday, March 26, 2002 4:21 AM > To: 'Ramalingam, Swaminathan' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] RE: IS Adjacency table > > > > > Also description for isisISAdjNeighPriority reads like: > > > > isisISAdjNeighPriority OBJECT-TYPE > > SYNTAX ISPriority > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Priority of the neighboring Intermediate System for > > becoming the LAN Level 1 Designated Intermediate System > > if the value of isisISAdjNeighSysType is > > L1IntermediateSystem or LAN Level 2 Designated > > Intermediate System if the value of > > isisISAdjNeighSysType is L2IntermediateSystem." > > REFERENCE "{ISIS.aoi lANPriority (86)}" > > ::= { isisISAdjEntry 8 } > > > > > > what it mean when isisISAdjNeighSysType is > > "l1l2IntermediateSystem"?. > > You are right. It is confusing. It is only relevant on a LAN, > where there will be an adjacency per level. It may be simplest > to simplest to say > > isisISAdjNeighPriority OBJECT-TYPE > SYNTAX ISPriority > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Priority of the neighboring Intermediate System for > becoming the Designated Intermediate System." > REFERENCE "{ISIS.aoi lANPriority (86)}" > ::= { isisISAdjEntry 8 } > > > > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object > > conveying the message what "type" of adjacency is that > (either Level1 or > > Level2) > > I believe that the isisISAdjUsage variable conveys this information. This is true for Point-to-Point. But in broadcast network, We create two adjacencies Level 1 and Level 2 separtely even the IS is configured as "L2 IS with manualL2Only false" i.e L1L2. In Sec 8.4.2 of ISO 10589, last paragraph reads like: "Level 2 Intermediate Systems (with manualL2onlyMode "False") shall perform both of the above actions.Separate Level 1 and Level 2 LAN IIH PDUs shall be sent to the multi-destination addresses AllL1ISs and AllL2ISs describing the neighbor Intermediate systems for Level 1 and Level 2 respectively.Separate Adjacencies shall be created by the receipt of Level 1 and Level 2 LAN IIH PDUs". It means even the IS is configured for L1L2, we create two Adjacencies with "neighbourSystemType" with L1 and L2 separately. My Point is there is no adjacencyUsage called "L1L2" in BROADCAST NETWORK. So any two "L1L2IS" will have 2 Adjacency separately for Level 1 & 2 respectively (as there are two different hellos) Also whenever we receive L1 IIH or L2 IIH, we need to set the neighbourSystemType to 'L1 IS' or 'L2 IS' as per sec 8.4.2.2 & 8.4.2.3. It will be easy to implement when one create two separate adjacency with L1 and L2 as "Adjacency Type". Let me know if we are not in sync.. > > - jeff parker > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 00:20:51 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16412 for ; Tue, 26 Mar 2002 00:20:50 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q591t06940; Mon, 25 Mar 2002 21:09:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q58xt06928 for ; Mon, 25 Mar 2002 21:08:59 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2Q5JG673087 for ; Mon, 25 Mar 2002 21:19:16 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 21:16:27 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id B839234436; Mon, 25 Mar 2002 21:21:50 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2Q5HxvM028676; Mon, 25 Mar 2002 21:17:59 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2Q5Hxtd003084; Mon, 25 Mar 2002 21:17:59 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15520.1159.205579.971259@alpha-tli.procket.com> To: Tony Przygienda Cc: Laura Liu , Aravind Ravikumar , isis-wg@juniper.net Subject: Re: [Isis-wg] few doubts on LSP purging In-Reply-To: <3C9FAB7A.7AD3DD6D@redback.com> References: <2383E22BDFF6D311BB8400B0D021A50701F451AD@MAIL> <3C9FAB7A.7AD3DD6D@redback.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 26 Mar 2002 05:16:27.0359 (UTC) FILETIME=[61708EF0:01C1D485] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 25 Mar 2002 21:17:59 -0800 Content-Transfer-Encoding: 7bit | > Hi All,To add another situation: router A has multiple LSP fragments of router B, when router | > B made some changes, purged it LSPs and the new lsp can fit into one pdu (lsp #0), router A | > need to purge the old lsp fragments (lsp #1 and above), those lsp headers should be retained | > in the database for MaxAge. | > | > you do not 'compact' fragments into a single fragment again. That would make the semantics of | > information | > deletion/addition within fragments hard to track and would lead to extensive flapping of e.g. | > prefixes if you're | > unlucky. | > | > | > Each fragment is basically an independent entity when it comes to flooding and purging Further.... if a IS does decide to regenerate its LSP, then it should simply bump the sequence number and flood the new version. The IS should NEVER purge an LSP with just the intent of replacing it with another subsequent verison. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 04:52:44 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28253 for ; Tue, 26 Mar 2002 04:52:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q9d1t08169; Tue, 26 Mar 2002 01:39:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2Q9cNt08157 for ; Tue, 26 Mar 2002 01:38:23 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2Q9me676409 for ; Tue, 26 Mar 2002 01:48:40 -0800 (PST) X-JNPR-Received-From: outside Received: from web11202.mail.yahoo.com ([216.136.131.184]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Mar 2002 01:44:15 -0800 Message-ID: <20020326094547.13926.qmail@web11202.mail.yahoo.com> Received: from [203.196.145.150] by web11202.mail.yahoo.com via HTTP; Tue, 26 Mar 2002 01:45:47 PST From: Aravind Ravikumar Subject: Re: [Isis-wg] few doubts on LSP purging To: mike shand Cc: isis-wg@juniper.net In-Reply-To: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1160155901-1017135947=:13833" X-OriginalArrivalTime: 26 Mar 2002 09:44:15.0062 (UTC) FILETIME=[CA897760:01C1D4AA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 01:45:47 -0800 (PST) --0-1160155901-1017135947=:13833 Content-Type: text/plain; charset=us-ascii Hi, 1.While purging if we retain only the header and the authentication CLV, the existing checksum will be inconsistent as we are removing rest of the data portion So Do we need to A.Recompute checksum? or B.Leave it as it is? or C.Make it 0 In second case mentioned above,the receiving IS will generate corruptedLSPReceived circuit event, according to section section 7.3.14.2.e.1 and will treat it as an aged out LSP. In the third case the receiving IS will treat the LSP as an aged outLSP without generating a corruptedLSPReceived circuit event according to section 7.3.14.2.i I personally feel, the third option is the better one. Am I right? 2.What does the following note in the section 7.3.16.4 of ISO 10589 imply NOTE 32 A check of the checksum of a zero Remaining Lifetime LSP succeeds even though the data portion is not present Does it mean that since LSP received with corrupted checksum are treated as if the remaining life time is zero,we can afford to have a wrong checksum for the LSP we are trying to purge so that any IS which receives it considers it as an aged out LSP 3.What are we supposed to do in response to corruptedLSPReceived circuit event,I think we don't have any management variable corresponding to this event.What is the pupose of generating this event Aravind mike shand wrote: At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote: >Hi Mike, > >Thanks for the reply and now I have understood the issues, but for a small >clarifcation. > >If an IS finds out, while processing the CSNP (which includes the aged out >entry in it) from a DIS, that > >it is not having the aged out LSP in its database or is having an older >copy, then it will make a request for the LSP > >in its next PSNP. But since only the header of the aged out LSP is sent in >response to the PSNP, won't > >it be rejected because of authentication faliure, in case authentication >is configured and this sequence will keep on > >repeating. Am I right or wrong, please clarify? No. you have to include authentication even for purge headers. Mike > >>4. Can we consider them while doing look up in the database (for eg: while > >> trying to add entry into database) . If we do consider and if the IS > >> becomes Designated IS again, before the pseudoNode LSPs from the earlier > >> stint as Designated IS are removed from the LS database > > >I'm not quite sure what you mean by this. Can you re-phrase the question? > >Sorry for putting the above question in a wrong way in my earlier mail. >Any way its more to the implementation > >side and is clear now from your answers to the two questions that followed >it. I was trying to describe > >a situation followed by the doubts on that. > >I'll put the situation in a proper way as follows > >System A is Designated IS for a LAN > >System B comes up and becomes the designated IS > >Now the pseudonode LSPs generated by A will be purged and the headers will >be retained. > >System B goes down and system A again becomes the designated IS. > >A is still having the headers of the old pseudonode LSPs,which it comes >across while > >trying to add the new pseudonode LSPs to the database > >It was in this context I asked the other two questions > >Aravind > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1160155901-1017135947=:13833 Content-Type: text/html; charset=us-ascii

Hi,

1.While purging if we retain only the header and the authentication CLV,
the existing checksum will be inconsistent as we are removing rest of the
data portion So Do we need to

A.Recompute checksum? or

B.Leave it as it is? or

C.Make it 0

In second case mentioned above,the receiving IS
will generate corruptedLSPReceived circuit event, according to section
section 7.3.14.2.e.1 and will treat it as an aged out LSP.

In the third case the receiving IS will treat the LSP as an aged outLSP
without generating a corruptedLSPReceived circuit event according to
section 7.3.14.2.i

I personally feel, the third option is the better one. Am I right?

 


2.What does the following note in the section 7.3.16.4 of ISO 10589 imply

NOTE 32 A check of the checksum of a zero Remaining
Lifetime LSP succeeds even though the data portion is not
present

Does it mean that since LSP received with corrupted checksum
are treated as if the remaining life time is zero,we can afford
to have a wrong checksum for the LSP we are trying to purge so that any IS
which receives it considers it as an aged out LSP

 

3.What are we supposed to do in response to corruptedLSPReceived
circuit event,I think we don't have any management variable
corresponding to this event.What is the pupose of generating
this event

Aravind
 

 

 

 

 

  mike shand <mshand@cisco.com> wrote:

At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote:

>Hi Mike,
>
>Thanks for the reply and now I have understood the issues, but for a small
>clarifcation.
>
>If an IS finds out, while processing the CSNP (which includes the aged out
>entry in it) from a DIS, that
>
>it is not having the aged out LSP in its database or is having an older
>copy, then it will make a request for the LSP
>
>in its next PSNP. But since only the header of the aged out LSP is sent in
>response to the PSNP, won't
>
>it be rejected because of authentication faliure, in case authentication
>is configured and this sequence will keep on
>
>repeating. Am I right or wrong, please clarify?

No. you have to include authentication even for purge headers.

Mike



> >>4. Can w! e consider them while doing look up in the database (for eg: while
> >> trying to add entry into database) . If we do consider and if the IS
> >> becomes Designated IS again, before the pseudoNode LSPs from the earlier
> >> stint as Designated IS are removed from the LS database
>
> >I'm not quite sure what you mean by this. Can you re-phrase the question?
>
>Sorry for putting the above question in a wrong way in my earlier mail.
>Any way its more to the implementation
>
>side and is clear now from your answers to the two questions that followed
>it. I was trying to describe
>
>a situation followed by the doubts on that.
>
>I'll put the situation in a proper way as follows
>
>System A is Designated IS for a LAN
>
>System B comes up and becomes the designated IS
>
>Now the pseudonode LSPs generated by A will be purged and the he! aders will
>be retained.
>
>System B goes down and system A again becomes the designated IS.
>
>A is still having the headers of the old pseudonode LSPs,which it comes
>across while
>
>trying to add the new pseudonode LSPs to the database
>
>It was in this context I asked the other two questions
>
>Aravind
>
>
>
>Do You Yahoo!?
>Yahoo! Movies - coverage of the 74th Academy Awards®


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1160155901-1017135947=:13833-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 06:00:22 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28826 for ; Tue, 26 Mar 2002 06:00:21 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QAm1t08542; Tue, 26 Mar 2002 02:48:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QAl2t08530 for ; Tue, 26 Mar 2002 02:47:02 -0800 (PST) (envelope-from mshand@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2QAvK816362 for ; Tue, 26 Mar 2002 02:57:20 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Mar 2002 02:45:41 -0800 Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp16.cisco.com [144.254.108.83]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA26418; Tue, 26 Mar 2002 10:47:11 GMT Message-Id: <4.3.2.7.2.20020326103406.035d4618@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Aravind Ravikumar From: mike shand Subject: Re: [Isis-wg] few doubts on LSP purging Cc: isis-wg@juniper.net In-Reply-To: <20020326094547.13926.qmail@web11202.mail.yahoo.com> References: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-OriginalArrivalTime: 26 Mar 2002 10:45:41.0858 (UTC) FILETIME=[6009E420:01C1D4B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2QAl2t08531 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 10:47:04 +0000 Content-Transfer-Encoding: 8bit At 01:45 26/03/2002 -0800, Aravind Ravikumar wrote: >Hi, > >1.While purging if we retain only the header and the authentication CLV, >the existing checksum will be inconsistent as we are removing rest of the >data portion So Do we need to > >A.Recompute checksum? or > >B.Leave it as it is? or > >C.Make it 0 The original design assumed that you would make it zero. However you can in fact do any of the above because the checksum is not checked for a zero lifetime PDU. >In second case mentioned above,the receiving IS >will generate corruptedLSPReceived circuit event, according to section >section 7.3.14.2.e.1 and will treat it as an aged out LSP. Note that this is in fact wrong, and has been corrected by a defect report which is incorporated in 10589 version2. The correct thing to do with a corrupt LSP is to ignore it, NOT to purge it. The latter action can create storms (and indeed has been observed to do so) in the presence of a flakey link which causes excessive LSP corruption. However, your assumption that the second case will lead to this action is incorrect because of the note you refer to below. The checksum will be ignored if the lifetime is zero. >In the third case the receiving IS will treat the LSP as an aged outLSP >without generating a corruptedLSPReceived circuit event according to >section 7.3.14.2.i Yes. that (as I said) was the original intention - that the checksum should be zero. Note that a Fletcher Checksum can never genuinely be zero, so there is no confusion with unpurged LSPs. >I personally feel, the third option is the better one. Am I right? Yes. > > > >2.What does the following note in the section 7.3.16.4 of ISO 10589 imply > >NOTE 32 A check of the checksum of a zero Remaining >Lifetime LSP succeeds even though the data portion is not >present > >Does it mean that since LSP received with corrupted checksum >are treated as if the remaining life time is zero,we can afford >to have a wrong checksum for the LSP we are trying to purge so that any IS >which receives it considers it as an aged out LSP No. It means that since there is no data portion (or strictly needn't be, because I believe some strange implementation persist in retaining the data portion of a zero age LSP - it doesn't matter - it's just a waste of space), there is no need to check the checksum. As I said above, it is no longer thought desirable to purge a corrupt LSP. > > >3.What are we supposed to do in response to corruptedLSPReceived >circuit event,I think we don't have any management variable >corresponding to this event.What is the pupose of generating >this event As far as the protocol is concerned, just ignore it. The idea of the event is to draw some manager's attention to the fact that weird things are happening. Mike >Aravind > > > > > > > > > > > mike shand wrote: >>At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote: >> >> >Hi Mike, >> > >> >Thanks for the reply and now I have understood the issues, but for a small >> >clarifcation. >> > >> >If an IS finds out, while processing the CSNP (which includes the aged out >> >entry in it) from a DIS, that >> > >> >it is not having the aged out LSP in its database or is having an older >> >copy, then it will make a request for the LSP >> > >> >in its next PSNP. But since only the header of the aged out LSP is sent in >> >response to the PSNP, won't >> > >> >it be rejected because of authentication faliure, in case authentication >> >is configured and this sequence will keep on >> > >> >repeating. Am I right or wrong, please clarify? >> >>No. you have to include authentication even for purge headers. >> >>Mike >> >> >> >> > >>4. Can w! e consider them while doing look up in the database (for >> eg: while >> > >> trying to add entry into database) . If we do consider and if the IS >> > >> becomes Designated IS again, before the pseudoNode LSPs from the >> earlier >> > >> stint as Designated IS are removed from the LS database >> > >> > >I'm not quite sure what you mean by this. Can you re-phrase the question? >> > >> >Sorry for putting the above question in a wrong way in my earlier mail. >> >Any way its more to the implementation >> > >> >side and is clear now from your answers to the two questions that followed >> >it. I was trying to describe >> > >> >a situation followed by the doubts on that. >> > >> >I'll put the situation in a proper way as follows >> > >> >System A is Designated IS for a LAN >> > >> >System B comes up and becomes the designated IS >> > >> >Now the pseudonode LSPs generated by A will be purged and the hea! ders >> will >> >be retained. >> > >> >System B goes d! own and system A again becomes the designated IS. >> > >> >A is still having the headers of the old pseudonode LSPs,which it comes >> >across while >> > >> >trying to add the new pseudonode LSPs to the database >> > >> >It was in this context I asked the other two questions >> > >> >Aravind >> > >> > >> > >> >Do You Yahoo!? >> >Yahoo! Movies - coverage of the 74th Academy Awards® > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 09:46:29 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04648 for ; Tue, 26 Mar 2002 09:46:27 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QEX1t09957; Tue, 26 Mar 2002 06:33:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QEWKt09945 for ; Tue, 26 Mar 2002 06:32:20 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Ramalingam, Swaminathan'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] RE: IS Adjacency table MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 09:42:01 -0500 We are not in sync. There are two variables for each adjacency: what the type (l1, l2, both) the other IS is, and how the adj is being used (l1 or l2 on LAN, one of l1, l2, or both on p2p). I think we have everything you need. Perhaps you could explain again what you need. - jeff parker > > > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object > > > conveying the message what "type" of adjacency is that > > (either Level1 or > > > Level2) > > > > I believe that the isisISAdjUsage variable conveys this information. > > > This is true for Point-to-Point. But in broadcast network, We > create two > adjacencies Level 1 and Level 2 separtely even the IS is > configured as "L2 > IS with manualL2Only false" i.e L1L2. > In Sec 8.4.2 of ISO 10589, last paragraph reads like: > > "Level 2 Intermediate Systems (with manualL2onlyMode > "False") shall perform > both of the above actions.Separate Level 1 and Level 2 LAN > IIH PDUs shall be > sent to the multi-destination addresses AllL1ISs and AllL2ISs > describing the > neighbor Intermediate systems for Level 1 and Level 2 > respectively.Separate > Adjacencies shall be created by the receipt of Level 1 and > Level 2 LAN IIH > PDUs". > > It means even the IS is configured for L1L2, we create two > Adjacencies with > "neighbourSystemType" with L1 and L2 separately. My Point is > there is no > adjacencyUsage called "L1L2" in BROADCAST NETWORK. So any two > "L1L2IS" will > have 2 Adjacency separately for Level 1 & 2 respectively (as > there are two > different hellos) > > Also whenever we receive L1 IIH or L2 IIH, we need to set the > neighbourSystemType to 'L1 IS' or 'L2 IS' as per sec 8.4.2.2 > & 8.4.2.3. It > will be easy to implement when one create two separate > adjacency with L1 and > L2 as "Adjacency Type". > > Let me know if we are not in sync.. > > > > > > - jeff parker > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 10:20:58 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06223 for ; Tue, 26 Mar 2002 10:20:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QF91t10177; Tue, 26 Mar 2002 07:09:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QF8Bt10165 for ; Tue, 26 Mar 2002 07:08:11 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 10:18:29 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Jeff Parker'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] RE: IS Adjacency table MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 10:18:25 -0500 > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Tuesday, March 26, 2002 8:12 PM > To: 'Ramalingam, Swaminathan' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] RE: IS Adjacency table > > > We are not in sync. > > There are two variables for each adjacency: what the type > (l1, l2, both) the other IS is, and how the adj is being > used (l1 or l2 on LAN, one of l1, l2, or both on p2p). Yes.There can be *either* l1 or l2 on LAN. This is the one I need. I was assuming that you meant for LAN, Usage can be l1, l2 or both. All the confusion came to me when usage is "both" in a broadcast network. Thanks for the clarification. -- Swaminathan > > I think we have everything you need. Perhaps you could > explain again what you need. > > - jeff parker > > > > > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is > no object > > > > conveying the message what "type" of adjacency is that > > > (either Level1 or > > > > Level2) > > > > > > I believe that the isisISAdjUsage variable conveys this > information. > > > > > > This is true for Point-to-Point. But in broadcast network, We > > create two > > adjacencies Level 1 and Level 2 separtely even the IS is > > configured as "L2 > > IS with manualL2Only false" i.e L1L2. > > In Sec 8.4.2 of ISO 10589, last paragraph reads like: > > > > "Level 2 Intermediate Systems (with manualL2onlyMode > > "False") shall perform > > both of the above actions.Separate Level 1 and Level 2 LAN > > IIH PDUs shall be > > sent to the multi-destination addresses AllL1ISs and AllL2ISs > > describing the > > neighbor Intermediate systems for Level 1 and Level 2 > > respectively.Separate > > Adjacencies shall be created by the receipt of Level 1 and > > Level 2 LAN IIH > > PDUs". > > > > It means even the IS is configured for L1L2, we create two > > Adjacencies with > > "neighbourSystemType" with L1 and L2 separately. My Point is > > there is no > > adjacencyUsage called "L1L2" in BROADCAST NETWORK. So any two > > "L1L2IS" will > > have 2 Adjacency separately for Level 1 & 2 respectively (as > > there are two > > different hellos) > > > > Also whenever we receive L1 IIH or L2 IIH, we need to set the > > neighbourSystemType to 'L1 IS' or 'L2 IS' as per sec 8.4.2.2 > > & 8.4.2.3. It > > will be easy to implement when one create two separate > > adjacency with L1 and > > L2 as "Adjacency Type". > > > > Let me know if we are not in sync.. > > > > > > > > > > - jeff parker > > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 12:27:08 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13872 for ; Tue, 26 Mar 2002 12:27:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QHF1t10726; Tue, 26 Mar 2002 09:15:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QHEOt10711 for ; Tue, 26 Mar 2002 09:14:24 -0800 (PST) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2QHOi683966 for ; Tue, 26 Mar 2002 09:24:44 -0800 (PST) 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); Tue, 26 Mar 2002 09:20:51 -0800 Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 20AADF2C53; Tue, 26 Mar 2002 09:22:24 -0800 (PST) Message-ID: <3CA08F16.125E3A4E@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: Aravind Ravikumar Cc: mike shand , isis-wg@juniper.net Subject: Re: [Isis-wg] few doubts on LSP purging References: <20020326094547.13926.qmail@web11202.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2002 17:20:51.0374 (UTC) FILETIME=[9402ECE0:01C1D4EA] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 07:09:11 -0800 Content-Transfer-Encoding: 7bit Aravind Ravikumar wrote: > Hi, > > 1.While purging if we retain only the header and the authentication CLV, > the existing checksum will be inconsistent as we are removing rest of the > data portion So Do we need to > I would recommend to read the hmac draft and ponder over it some. Basically it is undesirable for anyone _but_ the originator to purge the originated LSP (and modern implementations adhere to this rule AFAIK) and in doing so, it should remove the content of the LSP except for the authentication TLV. This has denial-of-service protection implications that are spelled out. Coming back to the Dave-Tony reciprocal shoulder-patting on the 'maintain aged-out LSP' instead of dropping it after all neighbors acked ;-) IMHO I liked OSPF better when memory was at a premium and always went along the line 'if you can't write robust software, do something else in your life' since the OSPF spec was correct. Given the dramatic increase in memory & CPU availability in modern embedded systems and the constant or rather dropping amount of engineer brain cycles facing an onslaught of features and protocols, I tend to concur with them. Robust, over-engineered designs are better, except when they keep excessive amounts of redundant state. thqanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 12:29:55 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14043 for ; Tue, 26 Mar 2002 12:29:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QHI1t10756; Tue, 26 Mar 2002 09:18:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from bridge.axiowave.com (ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QHHIt10742 for ; Tue, 26 Mar 2002 09:17:19 -0800 (PST) (envelope-from jparker@axiowave.com) Message-ID: From: Jeff Parker To: "'Gavin McPherson'" , "Isis working group (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: Local IP addresses in the ISIS MIB. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 12:27:29 -0500 > Hi Jeff > > The isisCircTable and isisCircLevelTable allow me to configure > a circuit, but not the IP addresses on that circuit (advertised > in TLV 132 in IIH PDUs). > > Are we expected to get this information from elsewhere? If not, > I think we should add a table to configure this information. > > Thanks > Gavin Gavin - I hope you won't think it a copout if I say that we shouldn't configure that. The IP address on an interface will be used by many others. Rather than invent our own storage for this, we should use standard MIBs for this purpose. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 13:25:28 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17482 for ; Tue, 26 Mar 2002 13:25:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QID1t11023; Tue, 26 Mar 2002 10:13:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QICht11011 for ; Tue, 26 Mar 2002 10:12:43 -0800 (PST) (envelope-from rja@extremenetworks.com) Received: from mosquito.inet.org (unknown [10.18.3.102]) by gnat.inet.org (Postfix) with ESMTP id 5935A67103; Tue, 26 Mar 2002 13:46:40 -0500 (EST) Subject: Re: [Isis-wg] RE: Local IP addresses in the ISIS MIB. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "Isis working group (E-mail)" To: Jeff Parker From: RJ Atkinson In-Reply-To: Message-Id: <7EDD9FD3-40E6-11D6-BFF7-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 13:22:56 -0500 Content-Transfer-Encoding: 7bit On Tuesday, March 26, 2002, at 12:27 , Jeff Parker wrote: >> Hi Jeff >> >> The isisCircTable and isisCircLevelTable allow me to configure >> a circuit, but not the IP addresses on that circuit (advertised >> in TLV 132 in IIH PDUs). >> >> Are we expected to get this information from elsewhere? If not, >> I think we should add a table to configure this information. >> >> Thanks >> Gavin > > Gavin - > I hope you won't think it a copout if I say that we > shouldn't configure that. > > The IP address on an interface will be used by many > others. Rather than invent our own storage for this, we > should use standard MIBs for this purpose. To paraphrase Jeff: One should use an existing Interface MIB (rather than IS-IS MIB) to configure the IP Addresses on interfaces. Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 13:45:47 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18614 for ; Tue, 26 Mar 2002 13:45:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QIS1t11112; Tue, 26 Mar 2002 10:28:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QIRxt11100 for ; Tue, 26 Mar 2002 10:27:59 -0800 (PST) (envelope-from prz@redback.com) 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 g2QIcJu54032 for ; Tue, 26 Mar 2002 10:38:19 -0800 (PST) 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); Tue, 26 Mar 2002 10:35:36 -0800 Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 35991CAB64 for ; Tue, 26 Mar 2002 10:37:09 -0800 (PST) Message-ID: <3CA0A09B.E306CC58@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: 26 Mar 2002 18:35:36.0312 (UTC) FILETIME=[053E2780:01C1D4F5] Subject: [Isis-wg] overran by spam, only posts by subscribed members will be appearing ... Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 08:23:55 -0800 Content-Transfer-Encoding: 7bit L&G, this list got overrun by spam. I used quietly to clean up somewhere between 30 and 200 messages per week of spam through the admin interface to pick out the few legitimate postings by un-subscribed people. Unfortunately, it's at the point where the effort is not worth it anymore. I just let the spam sit there and die. Which means, if you want your posting to appear, pls make sure you're subscribed to the list ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 14:03:26 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19210 for ; Tue, 26 Mar 2002 14:03:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QIp2t11266; Tue, 26 Mar 2002 10:51:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from miles.dataconnection.com (smtp2.dataconnection.com [192.91.191.8]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QHCYt10683 for ; Tue, 26 Mar 2002 09:12:34 -0800 (PST) (envelope-from GMcP@dataconnection.com) Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2655.55) id ; Tue, 26 Mar 2002 17:22:55 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B50832@baker.datcon.co.uk> From: Gavin McPherson To: "Isis working group (E-mail)" Cc: "Jeff Parker (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Local IP addresses in the ISIS MIB. Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 17:22:51 -0000 Hi Jeff The isisCircTable and isisCircLevelTable allow me to configure a circuit, but not the IP addresses on that circuit (advertised in TLV 132 in IIH PDUs). Are we expected to get this information from elsewhere? If not, I think we should add a table to configure this information. Thanks Gavin _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 14:07:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19340 for ; Tue, 26 Mar 2002 14:07:24 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QIt1t11315; Tue, 26 Mar 2002 10:55:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from blush.juniper.net (colo-blush-ext.juniper.net [207.17.137.35] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QIs3t11295 for ; Tue, 26 Mar 2002 10:54:03 -0800 (PST) (envelope-from danny@dog.tcb.net) 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 g2QJ4Nu54390 for ; Tue, 26 Mar 2002 11:04:23 -0800 (PST) X-JNPR-Received-From: outside Received: from tcb.net ([205.168.100.1]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Mar 2002 10:53:22 -0800 Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g2QIhYj26387; Tue, 26 Mar 2002 11:43:35 -0700 Message-Id: <200203261843.g2QIhYj26387@tcb.net> X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 To: Tony Przygienda cc: isis-wg@juniper.net From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] overran by spam, only posts by subscribed members will be appearing ... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 26 Mar 2002 18:53:22.0749 (UTC) FILETIME=[80E386D0:01C1D4F7] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 11:43:34 -0700 Don't forget then to add explicit accept rules for the addresses outlined here: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt -danny > this list got overrun by spam. I used quietly to clean up somewhere > between 30 and 200 messages per week of spam through the admin > interface to pick out the few legitimate postings by un-subscribed > people. Unfortunately, it's at the point where the effort is not worth > it anymore. I just let the spam sit there and die. Which means, if > you want your posting to appear, pls make sure you're subscribed to > the list ... _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 14:08:25 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19363 for ; Tue, 26 Mar 2002 14:08:23 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QIu1t11341; Tue, 26 Mar 2002 10:56:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QItRt11329 for ; Tue, 26 Mar 2002 10:55:27 -0800 (PST) (envelope-from prz@redback.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2QJ5m685586 for ; Tue, 26 Mar 2002 11:05:48 -0800 (PST) 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); Tue, 26 Mar 2002 11:03:54 -0800 Received: from redback.com (dhcp-33-194.redback.com [155.53.33.194]) by prattle.redback.com (Postfix) with ESMTP id 7EE291DCC7A; Tue, 26 Mar 2002 11:05:27 -0800 (PST) Message-ID: <3CA0A73D.8B09239@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: danny@tcb.net Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] overran by spam, only posts by subscribed members will be appearing ... References: <200203261843.g2QIhYj26387@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Mar 2002 19:03:54.0796 (UTC) FILETIME=[F99E3EC0:01C1D4F8] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 08:52:14 -0800 Content-Transfer-Encoding: 7bit Danny McPherson wrote: > Don't forget then to add explicit accept rules for the > addresses outlined here: > > http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt > Danny, thanks, done, actually this is just a threat, I'll look @ the big spam collection infrequently to pick out important stuff. It's just I wanted to forcce people to subscribe if they want to post and therefore make my job easier ;-) thanks -- tony > > -danny > > > this list got overrun by spam. I used quietly to clean up somewhere > > between 30 and 200 messages per week of spam through the admin > > interface to pick out the few legitimate postings by un-subscribed > > people. Unfortunately, it's at the point where the effort is not worth > > it anymore. I just let the spam sit there and die. Which means, if > > you want your posting to appear, pls make sure you're subscribed to > > the list ... _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Mar 26 17:53:20 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28785 for ; Tue, 26 Mar 2002 17:53:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QMf2t12444; Tue, 26 Mar 2002 14:41:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2QMeIt12432 for ; Tue, 26 Mar 2002 14:40:18 -0800 (PST) (envelope-from dkatz@juniper.net) 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 g2QMoWT41509; Tue, 26 Mar 2002 14:50:32 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g2QMoWM23230; Tue, 26 Mar 2002 14:50:32 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) Message-Id: <200203262250.g2QMoWM23230@cirrus.juniper.net> From: Dave Katz To: prz@redback.com CC: aravindravikumar@yahoo.com, mshand@cisco.com, isis-wg@juniper.net In-reply-to: <3CA08F16.125E3A4E@redback.com> (message from Tony Przygienda on Tue, 26 Mar 2002 07:09:11 -0800) Subject: Re: [Isis-wg] few doubts on LSP purging References: <20020326094547.13926.qmail@web11202.mail.yahoo.com> <3CA08F16.125E3A4E@redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 14:50:32 -0800 (PST) Coming back to the Dave-Tony reciprocal shoulder-patting on the 'maintain aged-out LSP' instead of dropping it after all neighbors acked ;-) IMHO I liked OSPF better when memory was at a premium and always went along the line 'if you can't write robust software, do something else in your life' since the OSPF spec was correct. Given the dramatic increase in memory & CPU availability in modern embedded systems and the constant or rather dropping amount of engineer brain cycles facing an onslaught of features and protocols, I tend to concur with them. Robust, over-engineered designs are better, except when they keep excessive amounts of redundant state. Obviously it was a formative moment for both of us. ;-) There is an existence proof that writing a robust routing protocol implementation is difficult, and becoming moreso by the day as the demands of features, scalability, and dynamism all increase. A brittle system has an unfortunate but quite spectacular way of failing catastrophically. Designs that are more forgiving are more practical to implement. On the other hand, brittle designs help reduce competition. It's all tradeoffs, of course, but if keeping the purged LSPs around for awhile cramps the memory footprint, you're probably already dead given the dynamic memory usage profiles of most implementations. (I think this equine corpse has been sufficiently beaten.) _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 00:50:15 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08822 for ; Wed, 27 Mar 2002 00:50:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R5b1t14078; Tue, 26 Mar 2002 21:37:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from xover.netplane.com (cnxt10002.conexant.com [198.62.10.2]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R5aat14066 for ; Tue, 26 Mar 2002 21:36:36 -0800 (PST) (envelope-from swaminathanr@netplane.com) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 00:46:58 -0500 Message-ID: From: "Ramalingam, Swaminathan" To: "'Jeff Parker'" Cc: "'isis-wg@spider.juniper.net'" Subject: RE: [Isis-wg] RE: IS Adjacency table MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 00:46:54 -0500 > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Tuesday, March 26, 2002 8:12 PM > To: 'Ramalingam, Swaminathan' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] RE: IS Adjacency table > > > We are not in sync. > > There are two variables for each adjacency: what the type > (l1, l2, both) the other IS is, and how the adj is being > used (l1 or l2 on LAN, one of l1, l2, or both on p2p). I have a doubt when I look in to Circ Level Table Indices. It has only 'level1IS' and 'level2IS'. If we have l1l2 adjacency (in p2p), we need l1l2IS Level Index, right?. Pl. Clarify Thanks, ~ Swaminathan > > I think we have everything you need. Perhaps you could > explain again what you need. > > - jeff parker > > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 02:21:59 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18152 for ; Wed, 27 Mar 2002 02:21:58 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R791t14474; Tue, 26 Mar 2002 23:09:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R78gt14462 for ; Tue, 26 Mar 2002 23:08:42 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) 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 g2R7J5838013 for ; Tue, 26 Mar 2002 23:19:05 -0800 (PST) X-JNPR-Received-From: outside Received: from web11201.mail.yahoo.com ([216.136.131.171]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Mar 2002 23:10:01 -0800 Message-ID: <20020327071135.83418.qmail@web11201.mail.yahoo.com> Received: from [203.196.145.150] by web11201.mail.yahoo.com via HTTP; Tue, 26 Mar 2002 23:11:35 PST From: Aravind Ravikumar To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1036385184-1017213095=:82549" X-OriginalArrivalTime: 27 Mar 2002 07:10:01.0500 (UTC) FILETIME=[6965B5C0:01C1D55E] Subject: [Isis-wg] confusion regarding IP summarization Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 26 Mar 2002 23:11:35 -0800 (PST) --0-1036385184-1017213095=:82549 Content-Type: text/plain; charset=us-ascii Hi, All I am not clear about, what other information should be included in IP reachability field of level 2 LSP by a L1L2 IS, apart from IP addresses which are directly reachable via its own interfaces. Is it required to advertise ALL IP networks that are learned from other system's L1 LSP's IP reachability entries? or is it enough if the IS advetises(in its level2 LSP) ,only those networks which it considers reachable after the level1 SPF? Thanks in advance Aravind --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1036385184-1017213095=:82549 Content-Type: text/html; charset=us-ascii

Hi, All

I am not  clear about, what other information
should be included in IP reachability
field of level 2 LSP by a L1L2 IS, apart from IP addresses
which are directly reachable via its own interfaces.

Is it required to advertise ALL IP networks that are learned
from other system's L1 LSP's IP reachability entries?

 or

is it enough if the IS  advetises(in its level2 LSP) ,only those networks
which it considers reachable after the level1 SPF?


Thanks in advance
Aravind


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1036385184-1017213095=:82549-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 03:08:02 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18761 for ; Wed, 27 Mar 2002 03:08:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R7u1t14750; Tue, 26 Mar 2002 23:56:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R7tSt14738 for ; Tue, 26 Mar 2002 23:55:28 -0800 (PST) (envelope-from tli@procket.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2R85p695759 for ; Wed, 27 Mar 2002 00:05:51 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz1.procket.com ([65.174.124.36]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 00:00:44 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz1.procket.com (Postfix) with ESMTP id 7D5E523C2D; Tue, 26 Mar 2002 23:51:59 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2R82HvM018979; Wed, 27 Mar 2002 00:02:17 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2R82H7a004710; Wed, 27 Mar 2002 00:02:17 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15521.31881.626226.935425@alpha-tli.procket.com> To: Aravind Ravikumar Cc: isis-wg@juniper.net Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <20020327071135.83418.qmail@web11201.mail.yahoo.com> References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 27 Mar 2002 08:00:44.0655 (UTC) FILETIME=[7F424FF0:01C1D565] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 00:02:17 -0800 Content-Transfer-Encoding: 7bit | I am not clear about, what other information | should be included in IP reachability | field of level 2 LSP by a L1L2 IS, apart from IP addresses | which are directly reachable via its own interfaces. | | Is it required to advertise ALL IP networks that are learned | from other system's L1 LSP's IP reachability entries? | | or | | is it enough if the IS advetises(in its level2 LSP) ,only those networks | which it considers reachable after the level1 SPF? My interpretation is that the L2 is only required to include all of its local prefixes. Additional route injection is an implementation decision. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 03:53:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19712 for ; Wed, 27 Mar 2002 03:53:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R8f2t14964; Wed, 27 Mar 2002 00:41:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2R8eht14952 for ; Wed, 27 Mar 2002 00:40:43 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2R8p7696168 for ; Wed, 27 Mar 2002 00:51:07 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 00:47:38 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id DB8513442D; Wed, 27 Mar 2002 00:53:04 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2R8nBvM021402; Wed, 27 Mar 2002 00:49:11 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2R8nBgS004855; Wed, 27 Mar 2002 00:49:11 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15521.34695.503552.591936@alpha-tli.procket.com> To: mike shand Cc: Aravind Ravikumar , isis-wg@juniper.net Subject: Re: [Isis-wg] few doubts on LSP purging In-Reply-To: <4.3.2.7.2.20020326103406.035d4618@jaws.cisco.com> References: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> <4.3.2.7.2.20020326103406.035d4618@jaws.cisco.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 27 Mar 2002 08:47:38.0562 (UTC) FILETIME=[0C7A7220:01C1D56C] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 00:49:11 -0800 Content-Transfer-Encoding: 7bit | >1.While purging if we retain only the header and the authentication CLV, | >the existing checksum will be inconsistent as we are removing rest of the | >data portion So Do we need to | > | >A.Recompute checksum? or | > | >B.Leave it as it is? or | > | >C.Make it 0 | | The original design assumed that you would make it zero. However you can in | fact do any of the above because the checksum is not checked for a zero | lifetime PDU. IMHO, you should do A, in keeping with the general idea that checksums are good. Even if an implementation doesn't check them, you can be strict in what you send to insure interoperability. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 10:09:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01595 for ; Wed, 27 Mar 2002 10:09:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2REv1t17038; Wed, 27 Mar 2002 06:57:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2REuUt17026 for ; Wed, 27 Mar 2002 06:56:30 -0800 (PST) (envelope-from rsaluja@nortelnetworks.com) 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 g2RF6t844346 for ; Wed, 27 Mar 2002 07:06:55 -0800 (PST) X-JNPR-Received-From: outside Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 06:56:10 -0800 Received: from zrtps0m6.us.nortel.com (zrtps0m6.us.nortel.com [47.140.192.58]) by zrtps06s.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2REvhi09897; Wed, 27 Mar 2002 09:57:43 -0500 (EST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by zrtps0m6.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2REsmC06544; Wed, 27 Mar 2002 09:54:49 -0500 (EST) 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 JAA19871; Wed, 27 Mar 2002 09:57:27 -0500 for Received: from nortelnetworks.com (localhost [127.0.0.1]) by lead.engeast (8.9.3+Sun/8.9.1) with ESMTP id JAA20500; Wed, 27 Mar 2002 09:57:26 -0500 (EST) Message-ID: <3CA1DDD6.DABBBAD1@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: Aravind Ravikumar CC: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Mar 2002 14:56:10.0390 (UTC) FILETIME=[8827A360:01C1D59F] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 09:57:26 -0500 Content-Transfer-Encoding: 8bit Aravind Ravikumar wrote: > Hi, All > > I am not clear about, what other information > should be included in IP reachability > field of level 2 LSP by a L1L2 IS, apart from IP addresses > which are directly reachable via its own interfaces. > > Is it required to advertise ALL IP networks that are learned > from other system's L1 LSP's IP reachability entries? > > or > > is it enough if the IS advetises(in its level2 LSP) ,only those > networks > which it considers reachable after the level1 SPF? I think you should advertise the configured summary addresses and then go through the networks reachable after the level1 SPF and if the network is not covered by the summary address, you should advertise that network as well. Thanks, Rajesh > > > > Thanks in advance > Aravind > > > ----------------------------------------------------------------------- > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy Awards® -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 10:27:10 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02358 for ; Wed, 27 Mar 2002 10:27:10 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFF1t17153; Wed, 27 Mar 2002 07:15:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFECt17138 for ; Wed, 27 Mar 2002 07:14:12 -0800 (PST) (envelope-from sprevidi@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2RFOc844964 for ; Wed, 27 Mar 2002 07:24:38 -0800 (PST) X-JNPR-Received-From: outside Received: from strange-brew.cisco.com ([144.254.15.119]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 07:20:03 -0800 Received: from there (dhcp-bru-peg1-vl11-144-254-4-43.cisco.com [144.254.4.43]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA25108; Wed, 27 Mar 2002 16:21:27 +0100 (MET) Message-Id: <200203271521.QAA25108@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-1" From: stefano previdi To: "Rajesh Saluja", Aravind Ravikumar Subject: Re: [Isis-wg] confusion regarding IP summarization X-Mailer: KMail [version 1.3.1] Cc: isis-wg@juniper.net References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> <3CA1DDD6.DABBBAD1@nortelnetworks.com> In-Reply-To: <3CA1DDD6.DABBBAD1@nortelnetworks.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Mar 2002 15:20:03.0593 (UTC) FILETIME=[DE690F90:01C1D5A2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2RFECt17139 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 16:21:25 +0100 Content-Transfer-Encoding: 8bit On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: > > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? > > I think you should advertise the configured summary addresses and then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise that > network as well. I would suggest to advertise summary addresses only if you have more specific routes. s. > > Thanks, > Rajesh > > > > > > > > > Thanks in advance > > Aravind > > > > > > ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards® > > -- > > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 10:40:27 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02946 for ; Wed, 27 Mar 2002 10:40:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFS1t17238; Wed, 27 Mar 2002 07:28:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFRJt17226 for ; Wed, 27 Mar 2002 07:27:19 -0800 (PST) (envelope-from rsaluja@nortelnetworks.com) 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 g2RFbi846427 for ; Wed, 27 Mar 2002 07:37:44 -0800 (PST) X-JNPR-Received-From: outside Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 07:28:04 -0800 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RFTKb22224; Wed, 27 Mar 2002 09:29:20 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 07:29:20 -0800 Message-ID: <8B888AAAAB0FD31189590008C7918443080F52AA@zbl6c002.corpeast.baynetworks.com> From: "Rajesh Saluja" To: "'stefano previdi'" , Aravind Ravikumar Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5A4.29461098" X-OriginalArrivalTime: 27 Mar 2002 15:28:04.0359 (UTC) FILETIME=[FCF82170:01C1D5A3] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 07:29:18 -0800 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D5A4.29461098 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, advertise summary address only if you have at least one more = specific network (for this summary) calculated through level 1 SPF.=20 Thanks, Rajesh -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: Wednesday, March 27, 2002 10:21 AM To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: >=20 > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? >=20 > I think you should advertise the configured summary addresses and = then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise = that > network as well. I would suggest to advertise summary addresses only if you have=20 more specific routes. s. >=20 > Thanks, > Rajesh >=20 > > > > > > > > Thanks in advance > > Aravind > > > > > > = ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards=AE >=20 > -- >=20 > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- >=20 >=20 >=20 > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg >=20 ------_=_NextPart_001_01C1D5A4.29461098 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] confusion regarding IP summarization

Yes, advertise summary address only if you have at = least one more specific network (for this summary) calculated through = level 1 SPF.

Thanks,
Rajesh

-----Original Message-----
From: stefano previdi [mailto:sprevidi@cisco.com]=
Sent: Wednesday, March 27, 2002 10:21 AM
To: Saluja, Rajesh [BL60:432:EXCH]; Aravind = Ravikumar
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] confusion regarding IP = summarization


On Wednesday 27 March 2002 15:57, Rajesh Saluja = wrote:
> Aravind Ravikumar wrote:
>
> > Hi, All
> >
> > I am not  clear about, what other = information
> > should be included in IP = reachability
> > field of level 2 LSP by a L1L2 IS, apart = from IP addresses
> > which are directly reachable via its own = interfaces.
> >
> > Is it required to advertise ALL IP = networks that are learned
> > from other system's L1 LSP's IP = reachability entries?
> >
> >  or
> >
> > is it enough if the IS  advetises(in = its level2 LSP) ,only those
> > networks
> > which it considers reachable after the = level1 SPF?
>
> I think you should advertise the configured = summary addresses and then
> go through the networks reachable after the = level1 SPF and if the
> network is not covered by the summary address, = you should advertise that
> network as well.

I would suggest to advertise summary addresses only = if you have
more specific routes.

s.

>
> Thanks,
> Rajesh
>
> >
> >
> >
> > Thanks in advance
> > Aravind
> >
> >
> > = -----------------------------------------------------------------------<= /FONT>
> > Do You Yahoo!?
> > Yahoo! Movies - coverage of the 74th = Academy Awards=AE
>
> --
>
> = -------------------------------------------------------------
> Rajesh Saluja
> Nortel Networks Inc 600 Technology Park = Billerica, MA  01821
> Ph: (978) = 288-7791      Fax: (978) 670-8760
> = --------------------------------------------------------------
>
>
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>

------_=_NextPart_001_01C1D5A4.29461098-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 10:42:54 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03036 for ; Wed, 27 Mar 2002 10:42:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFV1t17271; Wed, 27 Mar 2002 07:31:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFUft17259 for ; Wed, 27 Mar 2002 07:30:41 -0800 (PST) (envelope-from prz@redback.com) 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 g2RFf6846772 for ; Wed, 27 Mar 2002 07:41:06 -0800 (PST) X-JNPR-Received-From: outside Received: from mta7.pltn13.pbi.net ([64.164.98.8]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 07:39:26 -0800 Received: from redback.com ([63.200.48.2]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GTN00FXJ28COV@mta7.pltn13.pbi.net> for isis-wg@juniper.net; Wed, 27 Mar 2002 07:41:00 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] confusion regarding IP summarization To: Rajesh Saluja Cc: Aravind Ravikumar , isis-wg@juniper.net Message-id: <3CA1C8D1.A387F82B@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: <20020327071135.83418.qmail@web11201.mail.yahoo.com> <3CA1DDD6.DABBBAD1@nortelnetworks.com> X-OriginalArrivalTime: 27 Mar 2002 15:39:26.0968 (UTC) FILETIME=[93D5FF80:01C1D5A5] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 05:27:45 -0800 Content-Transfer-Encoding: 7BIT Rajesh Saluja wrote: > Aravind Ravikumar wrote: > > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? > > I think you should advertise the configured summary addresses and then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise that > network as well. Rajesh, that's implementation advice which is ok to discuss on the list IMHO with big disclaimers disclosing it as such and preferrably declining any liability ;-) Now, giving questionable or wrong implementaiton advice as I think you're doing here ;-) can be taken as sign of naivite or as subtle influence ... This kind of stretches my judgement capability as of whether it's ok or not since it has been done by major players within IETF as well ;-) thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 10:52:38 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03531 for ; Wed, 27 Mar 2002 10:52:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFe2t17387; Wed, 27 Mar 2002 07:40:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RFdTt17365 for ; Wed, 27 Mar 2002 07:39:29 -0800 (PST) (envelope-from canningt@nortelnetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2RFnt846934 for ; Wed, 27 Mar 2002 07:49:55 -0800 (PST) X-JNPR-Received-From: outside Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 07:48:11 -0800 Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RFngg03750; Wed, 27 Mar 2002 16:49:42 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RFn8h22690; Wed, 27 Mar 2002 15:49:08 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 15:49:40 -0000 Message-ID: <17A46A8BD7E7D41199E300508BE3A94C03F3E335@zirey00b.europe.nortel.com> From: "Terry Canning" To: stefano previdi , "Rajesh Saluja", Aravind Ravikumar Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5A7.00939A14" X-OriginalArrivalTime: 27 Mar 2002 15:48:13.0015 (UTC) FILETIME=[CD626670:01C1D5A6] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 15:49:38 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D5A7.00939A14 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, RFC 1195 is quite clear on this matter. Section 3.2 states: The manually configured addresses are included in level 2 LSPs only if they correspond to at least one address which is reachable in the area. For manually configured level 2 addresses, the associated metric values to announce in level 2 LSPs are also manually configured. The configured addresses will supercede reachable = address entries from level 1 LSPs based only on the IP address and subnet mask -- metric values are not considered when determining if a given configured address supercedes an address obtained from a level 1 = LSP. =20 Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. Regards Terry Canning -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: 27 March 2002 15:21 To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: >=20 > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? >=20 > I think you should advertise the configured summary addresses and = then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise = that > network as well. I would suggest to advertise summary addresses only if you have=20 more specific routes. s. >=20 > Thanks, > Rajesh >=20 > > > > > > > > Thanks in advance > > Aravind > > > > > > = ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards=AE >=20 > -- >=20 > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- >=20 >=20 >=20 > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg >=20 _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1D5A7.00939A14 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] confusion regarding IP summarization

Folks,



RFC 1195 is quite clear on this matter. Section 3.2 states:



   The manually configured addresses are included in level 2 LSPs only

   if they correspond to at least one address which is reachable in the

   area. For manually configured level 2 addresses, the associated

   metric values to announce in level 2 LSPs are also manually

   configured. The configured addresses will supercede reachable address

   entries from level 1 LSPs based only on the IP address and subnet

   mask -- metric values are not considered when determining if a given

   configured address supercedes an address obtained from a level 1 LSP.

 

   Any address obtained from a level 1 LSP which is not superceded by

   the manually configured information is included in the level 2 LSPs.



Regards

Terry Canning



-----Original Message-----
From: stefano previdi [mailto:sprevidi@cisco.com]
Sent: 27 March 2002 15:21
To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] confusion regarding IP summarization


On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote:

> Aravind Ravikumar wrote:

>

> > Hi, All

> >

> > I am not  clear about, what other information

> > should be included in IP reachability

> > field of level 2 LSP by a L1L2 IS, apart from IP addresses

> > which are directly reachable via its own interfaces.

> >

> > Is it required to advertise ALL IP networks that are learned

> > from other system's L1 LSP's IP reachability entries?

> >

> >  or

> >

> > is it enough if the IS  advetises(in its level2 LSP) ,only those

> > networks

> > which it considers reachable after the level1 SPF?

>

> I think you should advertise the configured summary addresses and then

> go through the networks reachable after the level1 SPF and if the

> network is not covered by the summary address, you should advertise that

> network as well.



I would suggest to advertise summary addresses only if you have

more specific routes.



s.



>

> Thanks,

> Rajesh

>

> >

> >

> >

> > Thanks in advance

> > Aravind

> >

> >

> > -----------------------------------------------------------------------

> > Do You Yahoo!?

> > Yahoo! Movies - coverage of the 74th Academy Awards®

>

> --

>

> -------------------------------------------------------------

> Rajesh Saluja

> Nortel Networks Inc 600 Technology Park Billerica, MA  01821

> Ph: (978) 288-7791      Fax: (978) 670-8760

> --------------------------------------------------------------

>

>

>

> _______________________________________________

> Isis-wg mailing list  -  Isis-wg@spider.juniper.net

> http://spider.juniper.net/mailman/listinfo/isis-wg

>

_______________________________________________

Isis-wg mailing list  -  Isis-wg@spider.juniper.net

http://spider.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C1D5A7.00939A14-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 15:20:39 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20615 for ; Wed, 27 Mar 2002 15:20:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RK81t18581; Wed, 27 Mar 2002 12:08:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RK7et18569 for ; Wed, 27 Mar 2002 12:07:40 -0800 (PST) (envelope-from cast@allegronetworks.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2RKI7853188 for ; Wed, 27 Mar 2002 12:18:07 -0800 (PST) X-JNPR-Received-From: outside Received: from tahoe.allegronetworks.com ([63.115.58.10]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 12:14:53 -0800 Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:15:01 -0800 Message-ID: From: Neal Castagnoli To: "'Terry Canning'" , stefano previdi , Rajesh Saluja , Aravind Ravikumar Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 27 Mar 2002 20:14:53.0280 (UTC) FILETIME=[0E491600:01C1D5CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id g2RK7et18570 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 12:14:59 -0800 Content-Transfer-Encoding: 8bit RFC 2966 has something to say about this too: Another detail that implementors should be aware of is the fact that L1L2 routers should only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They should not unconditionally advertise into L2 all prefixes from LSPs in the L1 database. Is it OK to discuss on this list about whether or not the whole specified automatic redistribution thing is good default behavior? --Neal -----Original Message----- From: Terry Canning [mailto:canningt@nortelnetworks.com] Sent: Wednesday, March 27, 2002 7:50 AM To: stefano previdi; Rajesh Saluja; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization Folks, RFC 1195 is quite clear on this matter. Section 3.2 states: The manually configured addresses are included in level 2 LSPs only if they correspond to at least one address which is reachable in the area. For manually configured level 2 addresses, the associated metric values to announce in level 2 LSPs are also manually configured. The configured addresses will supercede reachable address entries from level 1 LSPs based only on the IP address and subnet mask -- metric values are not considered when determining if a given configured address supercedes an address obtained from a level 1 LSP. Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. Regards Terry Canning -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: 27 March 2002 15:21 To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: > > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? > > I think you should advertise the configured summary addresses and then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise that > network as well. I would suggest to advertise summary addresses only if you have more specific routes. s. > > Thanks, > Rajesh > > > > > > > > > Thanks in advance > > Aravind > > > > > > ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards® > > -- > > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 16:01:01 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22608 for ; Wed, 27 Mar 2002 16:00:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RKn1t18794; Wed, 27 Mar 2002 12:49:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RKmwt18782 for ; Wed, 27 Mar 2002 12:48:58 -0800 (PST) (envelope-from tli@procket.com) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2RKxO608029 for ; Wed, 27 Mar 2002 12:59:25 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz2.procket.com ([65.174.124.37]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 12:57:17 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz2.procket.com (Postfix) with ESMTP id 22EEB34422; Wed, 27 Mar 2002 13:02:46 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2RKwovM005072; Wed, 27 Mar 2002 12:58:50 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2RKwob5006496; Wed, 27 Mar 2002 12:58:50 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15522.12938.630184.132444@alpha-tli.procket.com> To: Neal Castagnoli Cc: "'Terry Canning'" , stefano previdi , Rajesh Saluja , Aravind Ravikumar , isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization In-Reply-To: References: X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 27 Mar 2002 20:57:17.0296 (UTC) FILETIME=[FAA31F00:01C1D5D1] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 12:58:50 -0800 Content-Transfer-Encoding: 7bit | Is it OK to discuss on this list about whether or not the whole specified | automatic redistribution thing is good default behavior? It's fine by me within reason. Just understand that it's an off-topic conversation about implementation issues and isn't a WG issue. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Mar 27 16:22:49 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24304 for ; Wed, 27 Mar 2002 16:22:48 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RLA2t18924; Wed, 27 Mar 2002 13:10:02 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2RL97t18909 for ; Wed, 27 Mar 2002 13:09:07 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2RLJY854305 for ; Wed, 27 Mar 2002 13:19:34 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 13:12:34 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2RLEOL29888; Wed, 27 Mar 2002 16:14:24 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-116.cisco.com [10.82.240.116]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABB60634; Wed, 27 Mar 2002 16:14:00 -0500 (EST) Message-Id: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Li From: Jeff Learman Subject: RE: [Isis-wg] confusion regarding IP summarization Cc: Neal Castagnoli , isis-wg@juniper.net In-Reply-To: <15522.12938.630184.132444@alpha-tli.procket.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 27 Mar 2002 21:12:39.0249 (UTC) FILETIME=[2029FC10:01C1D5D4] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 27 Mar 2002 16:13:55 -0500 Tony, based on an earlier post, it seems to me that 1195 requires automatic L2 distribution of L1 routes that aren't covered by L2 configured summary routes. You didn't contradict it, but I think that the text in 2966 that Neal quoted did. Sounds to me that there's more than an implementation issue here. Jeff At 03:58 PM 3/27/2002, Tony Li wrote: > | Is it OK to discuss on this list about whether or not the whole specified > | automatic redistribution thing is good default behavior? > > >It's fine by me within reason. Just understand that it's an off-topic >conversation about implementation issues and isn't a WG issue. > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 28 04:43:06 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20072 for ; Thu, 28 Mar 2002 04:43:05 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2S9U1t21963; Thu, 28 Mar 2002 01:30:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2S9TJt21948 for ; Thu, 28 Mar 2002 01:29:19 -0800 (PST) (envelope-from aravindravikumar@yahoo.com) 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 g2S9do864591 for ; Thu, 28 Mar 2002 01:39:50 -0800 (PST) X-JNPR-Received-From: outside Received: from web11202.mail.yahoo.com ([216.136.131.184]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Mar 2002 01:25:28 -0800 Message-ID: <20020328092702.63680.qmail@web11202.mail.yahoo.com> Received: from [203.196.145.150] by web11202.mail.yahoo.com via HTTP; Thu, 28 Mar 2002 01:27:02 PST From: Aravind Ravikumar Subject: RE: [Isis-wg] confusion regarding IP summarization To: Jeff Learman , Tony Li Cc: Neal Castagnoli , isis-wg@juniper.net In-Reply-To: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1866968233-1017307622=:60859" X-OriginalArrivalTime: 28 Mar 2002 09:25:28.0140 (UTC) FILETIME=[7FAA50C0:01C1D63A] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 01:27:02 -0800 (PST) --0-1866968233-1017307622=:60859 Content-Type: text/plain; charset=us-ascii Hi, I also feel that its not an implementation issue. I was trying to find what exactly certain section of RFC 1195 means The quoted section of RFC 1195 ( More specifically the following sentance was the source of my confusion, "Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs.") Some of these IP addresses which we get in L1 LSP may not be added to our forwarding database as a result of there being no path to the advertising router. I think that it will be inconsistent if an we advertises about routes that we ourselves are not using.The question was asked in this context The quoted section of rfc 2966 also seems to say the same thing, So if we go strictly by the words the section of rfc 1195 and the section of rfc 2966 sounds contradictory The section next to the quoted section of rfc 2966 says this "Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs." RFC 1195 seems to give no such choice and is strictly saying to advertise all address obtained from level 1 LSP.(Either advertise the Summary which supercedes it or if no such summary is configured it advertise the netwok itself) But the following section of rfc 1195 wchich talks about cost computation of advertised IP addresses seems to help "Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. In this case, the metric value announced in the level 2 LSPs is calculated from the sum of the metric value announced in the corresponding level 1 LSP, plus the distance from the level 2 router to the appropriate level 1 router . Note: If this sum resultsin a metric value greater than 63 (the maximum value that can be reported in level 2 LSPs), thenthe value 63 must be used." Does this section imply that if we don't have an entry to the advertising level1 router we should'nt advertise those IP address in level 2 LSP,since we cannot compute the cost If this interpretation is corrrect then there is no contradiction. Is it correct? Aravind Jeff Learman wrote: Tony, based on an earlier post, it seems to me that 1195 requires automatic L2 distribution of L1 routes that aren't covered by L2 configured summary routes. You didn't contradict it, but I think that the text in 2966 that Neal quoted did. Sounds to me that there's more than an implementation issue here. Jeff At 03:58 PM 3/27/2002, Tony Li wrote: > | Is it OK to discuss on this list about whether or not the whole specified > | automatic redistribution thing is good default behavior? > > >It's fine by me within reason. Just understand that it's an off-topic >conversation about implementation issues and isn't a WG issue. > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1866968233-1017307622=:60859 Content-Type: text/html; charset=us-ascii

Hi,

I also feel that its not an implementation issue.

I was trying to find what exactly certain section of RFC 1195 means

The  quoted section of RFC 1195 ( More specifically the following
sentance was the source of my confusion,
"Any address obtained from a level 1 LSP which is not superceded by
the manually configured information is included in the level 2 LSPs.")

Some of these IP addresses which we get in L1 LSP
may not be added to our forwarding database as a result of
there being no path to the advertising router.
I think that it will be inconsistent if an we advertises about routes
that we ourselves are not using.The question was asked in this context

The quoted section of rfc 2966 also seems to say the same thing,
So if we go strictly by the words the section of
rfc 1195 and the  section of rfc 2966 sounds contradictory


The section next to the quoted section of rfc 2966 says this

   "Not all prefixes need to be advertised up or down the hierarchy.
   Implementations might allow for additional manual filtering or
   summarization to further bring down the number of inter-area prefixes
   they advertise in their LSPs."

RFC 1195 seems to give no such choice and is strictly saying to
advertise all address obtained from level 1 LSP.(Either advertise
the Summary which supercedes it or if no such summary is
configured it advertise the netwok itself)

But the following section of rfc 1195 wchich talks about cost computation of advertised
IP addresses seems to help

"Any address obtained from a level 1 LSP which is not superceded by the
manually configured information is included in the level 2 LSPs. In this
case, the metric value announced in the level 2 LSPs is calculated from
the sum of the metric value announced in the corresponding level 1 LSP,
plus the distance from the level 2 router to the appropriate level 1 router
. Note: If this sum resultsin a metric value greater than 63 (the maximum
value that can be reported in level 2 LSPs), thenthe value 63 must be used."

Does this section imply that if we don't have an entry to the advertising level1
router we should'nt advertise those IP address in level 2 LSP,since we cannot compute the cost

If this interpretation is corrrect
then there is no contradiction. Is it correct?

Aravind

 


 

  Jeff Learman <jlearman@cisco.com> wrote:


Tony, based on an earlier post, it seems to me that 1195 requires
automatic L2 distribution of L1 routes that aren't covered by L2
configured summary routes. You didn't contradict it, but I think
that the text in 2966 that Neal quoted did.

Sounds to me that there's more than an implementation issue here.

Jeff


At 03:58 PM 3/27/2002, Tony Li wrote:


> | Is it OK to discuss on this list about whether or not the whole specified
> | automatic redistribution thing is good default behavior?
>
>
>It's fine by me within reason. Just understand that it's an off-topic
>conversation about implementation issues and isn't a WG issue.
>
>Tony
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list - Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1866968233-1017307622=:60859-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 28 07:17:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22785 for ; Thu, 28 Mar 2002 07:17:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2SC41t23074; Thu, 28 Mar 2002 04:04:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2SC3Ct23062 for ; Thu, 28 Mar 2002 04:03:12 -0800 (PST) (envelope-from nsyracus@cnri.reston.va.us) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2SCDg866212 for ; Thu, 28 Mar 2002 04:13:43 -0800 (PST) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Mar 2002 04:05:56 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22210; Thu, 28 Mar 2002 07:07:28 -0500 (EST) Message-Id: <200203281207.HAA22210@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: 28 Mar 2002 12:05:57.0109 (UTC) FILETIME=[EAFA6250:01C1D650] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-09.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 07:07:28 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-09.txt Pages : 10 Date : 27-Mar-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-gmpls-extensions-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-09.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: <20020327152124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152124.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 28 08:34:36 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24976 for ; Thu, 28 Mar 2002 08:34:35 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2SDLit23498; Thu, 28 Mar 2002 05:21:44 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2SDHNt23472 for ; Thu, 28 Mar 2002 05:17:23 -0800 (PST) (envelope-from jlearman@cisco.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2SDRs621474 for ; Thu, 28 Mar 2002 05:27:54 -0800 (PST) X-JNPR-Received-From: outside Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Mar 2002 05:23:03 -0800 Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2SDOwN23847; Thu, 28 Mar 2002 08:24:58 -0500 (EST) Received: from JLEARMAN-W2K1.cisco.com (rtp-vpn2-116.cisco.com [10.82.240.116]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABB73373; Thu, 28 Mar 2002 08:24:33 -0500 (EST) Message-Id: <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Aravind Ravikumar From: Jeff Learman Subject: RE: [Isis-wg] confusion regarding IP summarization Cc: Tony Li , Neal Castagnoli , isis-wg@juniper.net In-Reply-To: <20020328092702.63680.qmail@web11202.mail.yahoo.com> References: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_146718500==_.ALT" X-OriginalArrivalTime: 28 Mar 2002 13:23:03.0843 (UTC) FILETIME=[B0B9F730:01C1D65B] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 08:24:11 -0500 --=====================_146718500==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While it may be safer to include only reachable L1 routes in one's L2 LSPs, the existence of any unreachable L1 routes indicates that the area is partitioned. I don't think it was the intent of 1195 (and it clearly was not the intent of 10589) to deal with area partitions by changing L2 address advertisements. Offhand, I can't see what harm would be caused by omitting unreachable addresses, other than a little more L2 SPF churn for a flapping L1 link that partitions an area. Regards, Jeff Disclaimer: I do not work on IS-IS at Cisco, and my opinions do not necessarily reflect those of my employer. At 04:27 AM 3/28/2002, Aravind Ravikumar wrote: >Hi,=20 > >I also feel that its not an implementation issue. > >I was trying to find what exactly certain section of RFC 1195 means > >The quoted section of RFC 1195 ( More specifically the following >sentance was the source of my confusion, >"Any address obtained from a level 1 LSP which is not superceded by=20 >the manually configured information is included in the level 2 LSPs.") > >Some of these IP addresses which we get in L1 LSP >may not be added to our forwarding database as a result of >there being no path to the advertising router. >I think that it will be inconsistent if an we advertises about routes >that we ourselves are not using.The question was asked in this context=20 > >The quoted section of rfc 2966 also seems to say the same thing, >So if we go strictly by the words the section of=20 >rfc 1195 and the section of rfc 2966 sounds contradictory=20 > > >The section next to the quoted section of rfc 2966 says this=20 > > "Not all prefixes need to be advertised up or down the hierarchy. > Implementations might allow for additional manual filtering or > summarization to further bring down the number of inter-area prefixes > they advertise in their LSPs."=20 > >RFC 1195 seems to give no such choice and is strictly saying to=20 >advertise all address obtained from level 1 LSP.(Either advertise=20 >the Summary which supercedes it or if no such summary is >configured it advertise the netwok itself)=20 > >But the following section of rfc 1195 wchich talks about cost computation= of advertised=20 >IP addresses seems to help=20 > >"Any address obtained from a level 1 LSP which is not superceded by the=20 >manually configured information is included in the level 2 LSPs. In this=20 >case, the metric value announced in the level 2 LSPs is calculated from=20 >the sum of the metric value announced in the corresponding level 1 LSP, >plus the distance from the level 2 router to the appropriate level 1 router >. Note: If this sum resultsin a metric value greater than 63 (the maximum= =20 >value that can be reported in level 2 LSPs), thenthe value 63 must be= used."=20 > >Does this section imply that if we don't have an entry to the advertising= level1 >router we should'nt advertise those IP address in level 2 LSP,since we= cannot compute the cost > >If this interpretation is corrrect >then there is no contradiction. Is it correct? > >Aravind=20 > > =20 > > > =20 > > Jeff Learman wrote:=20 >> >>Tony, based on an earlier post, it seems to me that 1195 requires >>automatic L2 distribution of L1 routes that aren't covered by L2 >>configured summary routes. You didn't contradict it, but I think >>that the text in 2966 that Neal quoted did. >> >>Sounds to me that there's more than an implementation issue here. >> >>Jeff >> >> >>At 03:58 PM 3/27/2002, Tony Li wrote: >> >> >>> | Is it OK to discuss on this list about whether or not the whole= specified >>> | automatic redistribution thing is good default behavior? >>> >>> >>>It's fine by me within reason. Just understand that it's an off-topic >>>conversation about implementation issues and isn't a WG issue. >>> >>>Tony >>>_______________________________________________ >>>Isis-wg mailing list - Isis-wg@spider.juniper.net >>>http://spider.juniper.net/mailman/listinfo/isis-wg >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@spider.juniper.net >>http://spider.juniper.net/mailman/listinfo/isis-wg > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards=AE=20 --=====================_146718500==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
While it may be safer to include only reachable L1 routes in one's
L2 LSPs, the existence of any unreachable L1 routes indicates that
the area is partitioned.  I don't think it was the intent of 1195
(and it clearly was not the intent of 10589) to deal with area partitions
by changing L2 address advertisements.

Offhand, I can't see what harm would be caused by omitting unreachable
addresses, other than a little more L2 SPF churn for a flapping L1 link
that partitions an area.

Regards,
Jeff

Disclaimer: I do not work on IS-IS at Cisco, and my opinions do not
necessarily reflect those of my employer.



At 04:27 AM 3/28/2002, Aravind Ravikumar wrote:

Hi,

I also feel that its not an implementation issue.

I was trying to find what exactly certain section of RFC 1195 means

The  quoted section of RFC 1195 ( More specifically the following
sentance was the source of my confusion,
"Any address obtained from a level 1 LSP which is not superceded by
the manually configured information is included in the level 2 LSPs.")

Some of these IP addresses which we get in L1 LSP
may not be added to our forwarding database as a result of
there being no path to the advertising router.
I think that it will be inconsistent if an we advertises about routes
that we ourselves are not using.The question was asked in this context

The quoted section of rfc 2966 also seems to say the same thing,
So if we go strictly by the words the section of
rfc 1195 and the  section of rfc 2966 sounds contradictory


The section next to the quoted section of rfc 2966 says this

   "Not all prefixes need to be advertised up or down the hierarchy.
   Implementations might allow for additional manual filtering or
   summarization to further bring down the number of inter-area prefixes
   they advertise in their LSPs."

RFC 1195 seems to give no such choice and is strictly saying to
advertise all address obtained from level 1 LSP.(Either advertise
the Summary which supercedes it or if no such summary is
configured it advertise the netwok itself)

But the following section of rfc 1195 wchich talks about cost computation of advertised
IP addresses seems to help

"Any address obtained from a level 1 LSP which is not superceded by the
manually configured information is included in the level 2 LSPs. In this
case, the metric value announced in the level 2 LSPs is calculated from
the sum of the metric value announced in the corresponding level 1 LSP,
plus the distance from the level 2 router to the appropriate level 1 router
. Note: If this sum resultsin a metric value greater than 63 (the maximum
value that can be reported in level 2 LSPs), thenthe value 63 must be used."

Does this section imply that if we don't have an entry to the advertising level1
router we should'nt advertise those IP address in level 2 LSP,since we cannot compute the cost

If this interpretation is corrrect
then there is no contradiction. Is it correct?

Aravind

 


 

  Jeff Learman <jlearman@cisco.com> wrote:=20

Tony, based on an earlier post, it seems to me that 1195 requires
automatic L2 distribution of L1 routes that aren't covered by L2
configured summary routes. You didn't contradict it, but I think
that the text in 2966 that Neal quoted did.

Sounds to me that there's more than an implementation issue here.

Jeff


At 03:58 PM 3/27/2002, Tony Li wrote:


> | Is it OK to discuss on this list about whether or not the whole specified
> | automatic redistribution thing is good default behavior?
>
>
>It's fine by me within reason. Just understand that it's an off-topic
>conversation about implementation issues and isn't a WG issue.
>
>Tony
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________
Isis-wg mailing list - Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards=AE
--=====================_146718500==_.ALT-- _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Mar 28 14:00:05 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10689 for ; Thu, 28 Mar 2002 14:00:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2SIl1t25075; Thu, 28 Mar 2002 10:47:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2SIkWt25063 for ; Thu, 28 Mar 2002 10:46:32 -0800 (PST) (envelope-from tli@procket.com) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id g2SIv5873870 for ; Thu, 28 Mar 2002 10:57:05 -0800 (PST) X-JNPR-Received-From: outside Received: from dmz1.procket.com ([65.174.124.36]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Mar 2002 10:50:33 -0800 Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by dmz1.procket.com (Postfix) with ESMTP id 15A8123C34; Thu, 28 Mar 2002 10:41:46 -0800 (PST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g2SIq7vM003709; Thu, 28 Mar 2002 10:52:07 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g2SIq7pb008759; Thu, 28 Mar 2002 10:52:07 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.26199.642001.684563@alpha-tli.procket.com> To: Jeff Learman Cc: Aravind Ravikumar , Tony Li , Neal Castagnoli , isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization In-Reply-To: <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> References: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> X-Mailer: VM 6.92 under Emacs 20.5.1 X-OriginalArrivalTime: 28 Mar 2002 18:50:33.0843 (UTC) FILETIME=[710A0430:01C1D689] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 28 Mar 2002 10:52:07 -0800 Content-Transfer-Encoding: 7bit | Offhand, I can't see what harm would be caused by omitting unreachable | addresses, other than a little more L2 SPF churn for a flapping L1 link | that partitions an area. If your L1 is partitioned and you have multiple L1L2s for the area, then you want each L1L2 to only advertise its reachable addresses. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Mar 29 02:33:04 2002 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06202 for ; Fri, 29 Mar 2002 02:33:03 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2T7J1t28068; Thu, 28 Mar 2002 23:19:01 -0800 (PST) (envelope-from isis-wg-admin@spider.juniper.net) Received: from pinot.juniper.net (pinot.juniper.net [207.17.137.58]) by external.juniper.net (8.11.6/8.11.6) with ESMTP id g2T7IIt28056 for ; Thu, 28 Mar 2002 23:18:18 -0800 (PST) (envelope-from prz@net4u.ch) Received: from ping.juniper.net (ping.juniper.net [207.17.137.101]) by pinot.juniper.net (8.11.2/8.11.2) with ESMTP id g2T7Sr637635 for ; Thu, 28 Mar 2002 23:28:54 -0800 (PST) X-JNPR-Received-From: outside Received: from mta6.snfc21.pbi.net ([206.13.28.240]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Mar 2002 23:26:59 -0800 Received: from net4u.ch ([63.200.50.53]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GTQ00CVQ4RL01@mta6.snfc21.pbi.net> for isis-wg@juniper.net; Thu, 28 Mar 2002 23:28:34 -0800 (PST) From: Tony Przygienda Subject: Re: [Isis-wg] confusion regarding IP summarization To: Tony Li Cc: Jeff Learman , Aravind Ravikumar , Neal Castagnoli , isis-wg@juniper.net Message-id: <3CA41FE3.5080005@net4u.ch> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 References: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> <15523.26199.642001.684563@alpha-tli.procket.com> X-OriginalArrivalTime: 29 Mar 2002 07:26:59.0140 (UTC) FILETIME=[1CC8C040:01C1D6F3] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@spider.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 29 Mar 2002 00:03:47 -0800 Content-Transfer-Encoding: 7BIT Tony Li wrote: > > | Offhand, I can't see what harm would be caused by omitting unreachable > | addresses, other than a little more L2 SPF churn for a flapping L1 link > | that partitions an area. > > >If your L1 is partitioned and you have multiple L1L2s for the area, then >you want each L1L2 to only advertise its reachable addresses. > so this is just one example of why e.g. you would _not_ aggregate even you have an aggregate configured. I had a half-written ospf draft 1-2 years ago after discussions with John & Rob suggesting that if you see advertisement from an ABR in your area that is not connected (kind of easy to figure out when you ran intra-area computation), you should _deaggregate_ into area 0. Never seemed quite worth it since as pointed out, aggregation is so implementation-dependent. And guess what, changes to ABR behavior specified recently would influence all that stuff again. Another problem is e.g. that you may be tempted and go ahead and deploy an implementation that per default leaks all L1s into L2s as 1195 seems to suggest. Any customer with any serious multi-level backbone will very quickly teach you to abandon that practice unless he wants to have hundreds of level-1 addresses sloshing around the network and defeat purpose of level-2 to a good extent. Another one to make the heads of the let's-standardize-aggregation crowd spin: If an aggregate subsumes another aggregate, which and how many do you advertise? Funny enough, there are more than a single possible correct answer depending on your deployment scenario. And last juicy morcel: 1195 and OSPF want you to set aggregate metric to max. metric of aggregated prefixes. Go check the largest deployed implementaion and you'll be in for a surprise. Yes, it could loop if you really, really try but there is a method to this madness as well. We can go on and on ... We're kind of getting down the drain that I tried to plug so before I chime out of this discussion: Aggregation is very implementation and deployment dependent and I would strongly object any push to standardize it unless interoperability problems can be pointed out. Don't forget that this list has an Occam's razor: if it's not needed for interoperability, don't standardize it and especially, don't standardize for fun and to pass time! So a draft describing possibilites and problems with aggregation is fine but at a first MUST or SHOULD I'll probably get vocal ;-) thanks & out -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg