From isis-wg-bounces@ietf.org Wed Feb 01 15:03:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4OBx-0000MX-Vw; Wed, 01 Feb 2006 15:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4OBq-0000Kn-Ht; Wed, 01 Feb 2006 15:02:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00430; Wed, 1 Feb 2006 15:01:17 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ON5-0003Xx-9C; Wed, 01 Feb 2006 15:14:31 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F4OBp-0002i4-Md; Wed, 01 Feb 2006 15:02:53 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 01 Feb 2006 15:02:53 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isis-wg@ietf.org Subject: [Isis-wg] Last Call: 'Routing IPv6 with IS-IS' to Proposed Standard X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org The IESG has received a request from the IS-IS for IP Internets WG to consider the following document: - 'Routing IPv6 with IS-IS ' as a Proposed Standard The implementation report for this specification is available at http://www.ietf.org/IESG/Implementations/isis-ipv6-imp.txt The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-15. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Feb 08 13:51:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6uPy-00004u-Vx; Wed, 08 Feb 2006 13:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6uPw-0008UE-PN; Wed, 08 Feb 2006 13:51:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21374; Wed, 8 Feb 2006 13:50:03 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6ucR-0000Sh-QI; Wed, 08 Feb 2006 14:04:49 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k18IpPHa031781; Wed, 8 Feb 2006 20:51:25 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k18IpOQf031778; Wed, 8 Feb 2006 20:51:24 +0200 Date: Wed, 8 Feb 2006 20:51:24 +0200 (EET) From: Pekka Savola To: iesg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1280/Tue Feb 7 12:11:53 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isis-wg@ietf.org Subject: [Isis-wg] Re: Last Call: 'Routing IPv6 with IS-IS' to Proposed Standard X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org On Wed, 1 Feb 2006, The IESG wrote: > The IESG has received a request from the IS-IS for IP Internets WG to consider > the following document: > > - 'Routing IPv6 with IS-IS ' > as a Proposed Standard > > The implementation report for this specification is available at > http://www.ietf.org/IESG/Implementations/isis-ipv6-imp.txt ... > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-15. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-06.txt There is a procedural problem here: a normative reference to [[RFC3784]] (references list not updated), which is informational, while this spec is going for Standards Track. This is a down-ref issue. On our network, we also observed a Cisco bug where the router redistributed FE80::/10 an FF00::/8 into IS-IS, which caused a bit of mess. Maybe the document should say something about this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Feb 15 07:50:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9M7C-0007sb-6X; Wed, 15 Feb 2006 07:50:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9M7A-0007sW-QC for isis-wg@megatron.ietf.org; Wed, 15 Feb 2006 07:50:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05684 for ; Wed, 15 Feb 2006 07:48:49 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9MLC-0000Gf-Dv for isis-wg@ietf.org; Wed, 15 Feb 2006 08:05:06 -0500 Received: by wproxy.gmail.com with SMTP id i28so1275672wra for ; Wed, 15 Feb 2006 04:50:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=txirKV80XU+C1oMLtp0Hov9CbxkzIhKaJv+8aW9YBivrmcXQw7LDhq2NJdCLkYIeeJAxfRTv9mmfDgv5RMPK/e/1xSHdU28blEi0n3OfvywuIQ2tlVnLrrYa0rcrNEDQnvUET5Eo1S1NHoURAG4hPMpaBg2KZvhB3lSFrL7z29c= Received: by 10.64.91.12 with SMTP id o12mr2574307qbb; Wed, 15 Feb 2006 04:50:35 -0800 (PST) Received: by 10.64.27.3 with HTTP; Wed, 15 Feb 2006 04:50:35 -0800 (PST) Message-ID: <93df11c00602150450h75715b84hbd2f6e30e32283b1@mail.gmail.com> Date: Wed, 15 Feb 2006 18:20:35 +0530 From: apoorv kulshrestha To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Subject: [Isis-wg] up/down bit confusion X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, As per rfc 2966, section 2: " A simple extension would be to allow a L1L2 router to advertise routes learned via L2 routing in its L1 LSP. However, to prevent routing-loops, L1L2 routers must never advertise L2->L1 inter-area routes that they learn via L1 routing, back into L2. Therefore, there must be a way to distinguish L2->L1 inter-area routes from L1 intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down bit" for this purpose. ... L1L2 routers must set this bit to one for prefixes that are derived from L2 routing and are advertised into L1 LSPs. The bit must be set to zero for all other IP prefixes in L1 or L2 LSPs." Ok there can be formed, routing loops. As per my understanding, it will create problem only if the original IS which advertised the prefix (to which advertised prefix is directly connected) goes down (or that interface to which prefix is connected goes down). Otherwise it would be like A --- B--- C (all are L1L2 systems) | prefix X At C, L2 LSP contain route to prefix X (directly connected), metric 10. At B, L2 LSP contain route to prefix X due routing loop, metric 20. At A, in L2 SPF, both LSP will result in route to prefix X with metric 30 and B as next hop (same next hop, so ECMP also will not arise). So, in normal operation, there should not be any problem due to L2 ->L1 route leakage. But if interface on C to which prefix X is connected, goes down, a 'count to infinity' sort of problem will come up. Now, my confusions are: 1. This problem will be with L1->L2 leakage also, but in the proposed solution to break routing loops, ie, up/down bit, it is not possible to distinguish between L1->L2 leaked route (has up/down bit set to up, ie, 0) and L2 routes (has up/down bit set to reserved, ie, 0). How to break routing loop in that case? 2. Am I correct in my understanding? Or are there some more issues due to routing loop in normal operation also? Please help. Regards and thanks, Apoorv _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Feb 15 10:18:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9OPv-00012V-CN; Wed, 15 Feb 2006 10:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9OPq-0000p4-DN for isis-wg@megatron.ietf.org; Wed, 15 Feb 2006 10:18:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16612 for ; Wed, 15 Feb 2006 10:16:14 -0500 (EST) Received: from knint.xs4all.nl ([80.126.131.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Ods-0005mV-Fl for isis-wg@ietf.org; Wed, 15 Feb 2006 10:32:33 -0500 Received: from knint.xs4all.nl (localhost.localdomain [127.0.0.1]) by knint.xs4all.nl (8.12.8/8.12.8) with ESMTP id k1FFHuUb002109; Wed, 15 Feb 2006 16:17:58 +0100 Received: (from henk@localhost) by knint.xs4all.nl (8.12.8/8.12.8/Submit) id k1FFHtWK002106; Wed, 15 Feb 2006 16:17:55 +0100 From: Henk Smit Message-Id: <200602151517.k1FFHtWK002106@knint.xs4all.nl> Subject: Re: [Isis-wg] up/down bit confusion To: apoorvkul@gmail.com (apoorv kulshrestha) Date: Wed, 15 Feb 2006 16:17:55 +0100 (CET) In-Reply-To: <93df11c00602150450h75715b84hbd2f6e30e32283b1@mail.gmail.com> from "apoorv kulshrestha" at Feb 15, 2006 06:20:35 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Some remarks inline. > Hi, > > As per rfc 2966, section 2: > > " A simple extension would be to allow a L1L2 router to advertise > routes learned via L2 routing in its L1 LSP. However, to prevent > routing-loops, L1L2 routers must never advertise L2->L1 inter-area > routes that they learn via L1 routing, back into L2. Therefore, there > must be a way to distinguish L2->L1 inter-area routes from L1 > intra-area routes. Draft-ietf-isis-traffic-01.txt defines the "up/down > bit" for this purpose. > ... > L1L2 routers must set this bit to one for prefixes that are derived > from L2 routing and are advertised into L1 LSPs. The bit must be set > to zero for all other IP prefixes in L1 or L2 LSPs." > > Ok there can be formed, routing loops. As per my understanding, it > will create problem only if the original IS which advertised the > prefix (to which advertised prefix is directly connected) goes down > (or that interface to which prefix is connected goes down). Otherwise > it would be like > > A --- B--- C (all are L1L2 systems) > | > prefix X > At C, L2 LSP contain route to prefix X (directly connected), metric 10. > At B, L2 LSP contain route to prefix X due routing loop, metric 20. I'm not sure I understand that sentence. There will be no routing loop. B will see prefix X twice in its databases. Once in the L1 LSPDB and once in the L2 LSPDB. B will find 2 paths to X, one via L1 SPF and one via L2 SPF. However, DIFFERENT TYPES of routes have DIFFERENT PREFERENCES. In this case, the L1 route will always be preferred over teh L2 routes, regardless of the cost of the path. > At A, in L2 SPF, both LSP will result in route to prefix X with metric > 30 and B as next hop (same next hop, so ECMP also will not arise). ECMP will not arise because the L1 route to X as advertised by C will be preferred to the L2 routes that can be derived from advertisements in B's or C's L2 LSP. > So, in normal operation, there should not be any problem due to L2 > ->L1 route leakage. But if interface on C to which prefix X is > connected, goes down, a 'count to infinity' sort of problem will come > up. I hope not. First there is the difference in preference in route types. Secondly, the up/down bit will shorten the maximum "path of advertisement" to L1->L2->L1. After that the prefix can not be advertised back up. > Now, my confusions are: > 1. This problem will be with L1->L2 leakage also, but in the proposed > solution to break routing loops, ie, up/down bit, it is not possible > to distinguish between L1->L2 leaked route (has up/down bit set to up, > ie, 0) and L2 routes (has up/down bit set to reserved, ie, 0). How to > break routing loop in that case? Pure L1 routes are to be preferred over L2->L1 routes. That should prevent counting to infinity. There can be short periods of time where a L1 route will go away, and then the L1 routes can still see the L2->L1 route advertised back into the area. However 1) this should usually not happen as the L1L2 routers of that area will not have that prefixes installed in their globabl RIB as L2 route, but as a L1 route. So they won't advertise the L1 route back into their L1 LSP anyway. And secondly, if they do, after their next SPF they will realize that the prefix went away, and regenerate their L1 LSP, without that prefix. > 2. Am I correct in my understanding? Or are there some more issues due > to routing loop in normal operation also? No, I think you are missing a few things. It's not trivial. But the issues you bring up should not happen. Hope this helps, Henk. > Please help. > > Regards and thanks, > Apoorv > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 16 00:23:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bcO-0003Hq-An; Thu, 16 Feb 2006 00:23:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bYh-0000gN-Mt for isis-wg@megatron.ietf.org; Thu, 16 Feb 2006 00:20:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11417 for ; Wed, 15 Feb 2006 22:37:36 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9aDF-0000yC-Vo for isis-wg@ietf.org; Wed, 15 Feb 2006 22:53:52 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUR00IXRHC3NJ@szxga02-in.huawei.com> for isis-wg@ietf.org; Thu, 16 Feb 2006 11:50:27 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUR00I2HHC34T@szxga02-in.huawei.com> for isis-wg@ietf.org; Thu, 16 Feb 2006 11:50:27 +0800 (CST) Received: from z11024 ([10.111.12.75]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUR00HHXHBW79@szxml02-in.huawei.com> for isis-wg@ietf.org; Thu, 16 Feb 2006 11:50:20 +0800 (CST) Date: Thu, 16 Feb 2006 11:38:04 +0800 From: Suping Zhai To: "isis-wg@ietf.org" Message-id: <0IUR00HHYHBW79@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Subject: [Isis-wg] A question with integrated IS-IS protocol X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, I have a question with regard to the integrated IS-IS protocol of RFC1195, and wish someone can help me. In section 3.1 exchange of routing information, it's stated that, IS-IS requires that: "Any codes in a received PDU that are not recognised are ignored and passed through unchanged". This requirement applies to all routers implementing IS-IS, including OSI-only, IP-only, and dual routers. >From above,what I understand is that this require the OSI-only, IP-only and dual router to recognize OSI and IP packet simultanously. But I think this is not the fact, and also I find text in section 1.4 as following, In a pure OSI routing domain, all routers must be OSI-capable. OSI- only routers may be freely mixed with dual routers. Some fields specifically related to IP operation may be included by dual routers, and will be ignored by OSI-only routers. Only OSI traffic will be routed in a pure OSI domain. Any IP traffic may be discarded. The same situation is with the IP-only routers, that is in IP-only area, all the OSI traffic may be discarded. So my question is, should the OSI-only(IP-only) routers discard the PDU with unrecognised code, and not passed through unchanged? Best Regards, zhaisuping@huawei.com Huawei Technologies Co., Ltd. Tel: +86-10-82882867 Fax: +86-10-82882770 2006-02-16 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 16 03:21:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9eOE-0006mP-SI; Thu, 16 Feb 2006 03:21:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9eMr-00065B-Ig for isis-wg@megatron.ietf.org; Thu, 16 Feb 2006 03:20:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27907 for ; Thu, 16 Feb 2006 03:18:13 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9eb2-0001bY-FF for isis-wg@ietf.org; Thu, 16 Feb 2006 03:34:41 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 16 Feb 2006 00:19:51 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,119,1139212800"; d="scan'208"; a="530204806:sNHT23040356" Received: from [172.26.200.59] ([172.26.200.59]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 00:19:50 -0800 Message-ID: <43F435A4.2090603@juniper.net> Date: Thu, 16 Feb 2006 09:19:48 +0100 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: zhaisuping@huawei.com Subject: Re: [Isis-wg] A question with integrated IS-IS protocol References: <0IUR00HHYHBW79@szxml02-in.huawei.com> In-Reply-To: <0IUR00HHYHBW79@szxml02-in.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2006 08:19:50.0873 (UTC) FILETIME=[C1DDCC90:01C632D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: "isis-wg@ietf.org" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Suping Zhai wrote: > Hi, > I have a question with regard to the integrated IS-IS protocol of RFC1195, and wish someone can help me. > In section 3.1 exchange of routing information, it's stated that, > > IS-IS requires that: > "Any codes in a received PDU that are not recognised are ignored and passed through unchanged". This > requirement applies to all routers implementing IS-IS, including > OSI-only, IP-only, and dual routers. > >>From above,what I understand is that this require the OSI-only, IP-only and dual router to recognize OSI and IP packet simultanously. no, it means that any router who does not recognize a TLV must pass it through unchanged. > But I think this is not the fact, and also I find text in section 1.4 as following, > > In a pure OSI routing domain, all routers must be OSI-capable. OSI- > only routers may be freely mixed with dual routers. Some fields > specifically related to IP operation may be included by dual routers, > and will be ignored by OSI-only routers. Only OSI traffic will be > routed in a pure OSI domain. Any IP traffic may be discarded. > > > The same situation is with the IP-only routers, that is in IP-only area, all the OSI traffic may be discarded. the text did not say "discard" but rather "ignored" > So my question is, should the OSI-only(IP-only) routers discard the PDU with unrecognised code, and not passed through unchanged? all unrecognized TLVs should get passed through unchanged. HTH, /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 16 03:37:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9edw-0004WZ-91; Thu, 16 Feb 2006 03:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9edu-0004WU-LL for isis-wg@megatron.ietf.org; Thu, 16 Feb 2006 03:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28927 for ; Thu, 16 Feb 2006 03:35:50 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9es6-00028X-Iz for isis-wg@ietf.org; Thu, 16 Feb 2006 03:52:18 -0500 Received: by wproxy.gmail.com with SMTP id i32so119618wra for ; Thu, 16 Feb 2006 00:37:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FCf51Judp30OHaVCL6ejoAg+Mp1E3RLl8KusduD/awqRVskTBoKtfdiVLHqkZj/CI+7hfDi7lCaNbaZ0T+sGKchgKcwEIWHB1K9tMyQ9/+RyxnFyrI5A6JTdbtZx2nowzBc87QTXknaFJRlDOhaUmsvD4+oZtM/g2qLs2SdMFRI= Received: by 10.65.194.19 with SMTP id w19mr76172qbp; Thu, 16 Feb 2006 00:37:37 -0800 (PST) Received: by 10.64.27.3 with HTTP; Thu, 16 Feb 2006 00:37:37 -0800 (PST) Message-ID: <93df11c00602160037p444aad18y3dad2913bc82de5c@mail.gmail.com> Date: Thu, 16 Feb 2006 14:07:37 +0530 From: apoorv kulshrestha To: Henk Smit Subject: Re: [Isis-wg] up/down bit confusion In-Reply-To: <200602151517.k1FFHtWK002106@knint.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <93df11c00602150450h75715b84hbd2f6e30e32283b1@mail.gmail.com> <200602151517.k1FFHtWK002106@knint.xs4all.nl> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org Hi, I missed to specify one thing in the routing loop scenario I discussed: A --- B--- C (all are L1L2 systems) | prefix X "At C, L2 LSP contain route to prefix X (directly connected), metric 10. At B, L2 LSP contain route to prefix X due routing loop, metric 20. At A, in L2 SPF, both LSP will result in route to prefix X with metric 30 and B as next hop (same next hop, so ECMP also will not arise). So, in normal operation, there should not be any problem due to L2 ->L1 route leakage. But if interface on C to which prefix X is connected, goes down, a 'count to infinity' sort of problem will come up." Here all A, B and C are in differnet areas. At B, L2 LSP containing route to prefix X is recieved and it will participate in L2 SPF. Due to L2->L1 route leakage, L1 LSP will list routes resulted from L2 SPF which will include route to prefix X. This L1 LSP will take part in L1 SPF, and thus L1 SPF will also result in route to prefix X. Now, while building L2 LSP B will take L1->L2 routes also, ie routes learned via L1 SPF which contain route to prefix X. Thus L2 LSP of B will also contain prefix to X. Preference order is involved in building routing table only. While building LSP of one level, it will simply take routes which it learned from other level SPF. And both level SPF will give a route to prefix X, so it will be in both LSPs - L1 and L2. So now B and C both are advertising route to prefix X in their LSP. So a routing loop is formed. However it should create problem only when interface of C connected to prefix X goes down. To break this loop, RFC 2966, suggests use of up/down bit to distinguish L2->L1 route, so that we can discard them while building L2 LSP. But the problem is what about reverse situation, L1->L2->L1 loop? Regards, Apoorv _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 16 05:33:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9gRq-0000lH-1I; Thu, 16 Feb 2006 05:33:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9gRp-0000lC-8J for isis-wg@megatron.ietf.org; Thu, 16 Feb 2006 05:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08188 for ; Thu, 16 Feb 2006 05:31:30 -0500 (EST) Received: from knint.xs4all.nl ([80.126.131.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9gg1-0006sR-Vb for isis-wg@ietf.org; Thu, 16 Feb 2006 05:47:58 -0500 Received: from knint.xs4all.nl (localhost.localdomain [127.0.0.1]) by knint.xs4all.nl (8.12.8/8.12.8) with ESMTP id k1GASC5R001110; Thu, 16 Feb 2006 11:28:12 +0100 Received: (from henk@localhost) by knint.xs4all.nl (8.12.8/8.12.8/Submit) id k1GASC1b001107; Thu, 16 Feb 2006 11:28:12 +0100 From: Henk Smit Message-Id: <200602161028.k1GASC1b001107@knint.xs4all.nl> Subject: Re: [Isis-wg] up/down bit confusion To: apoorvkul@gmail.com (apoorv kulshrestha) Date: Thu, 16 Feb 2006 11:28:12 +0100 (CET) In-Reply-To: <93df11c00602160037p444aad18y3dad2913bc82de5c@mail.gmail.com> from "apoorv kulshrestha" at Feb 16, 2006 02:07:37 PM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org > Hi, > I missed to specify one thing in the routing loop scenario I discussed: > A --- B--- C (all are L1L2 systems) > | > prefix X > "At C, L2 LSP contain route to prefix X (directly connected), metric 10. > At B, L2 LSP contain route to prefix X due routing loop, metric 20. > At A, in L2 SPF, both LSP will result in route to prefix X with metric > 30 and B as next hop (same next hop, so ECMP also will not arise). > So, in normal operation, there should not be any problem due to L2 > ->L1 route leakage. But if interface on C to which prefix X is > connected, goes down, a 'count to infinity' sort of problem will come > up." > > Here all A, B and C are in differnet areas. So this is the biggest change with the scenario you described in your previous email ? > At B, L2 LSP containing route to prefix X is recieved and it will > participate in L2 SPF. > Due to L2->L1 route leakage, L1 LSP will list routes resulted from L2 > SPF which will include route to prefix X. This L1 LSP will take part > in L1 SPF, and thus L1 SPF will also result in route to prefix X. At B ? I don't think so. When you do an SPF computation, you start by doing two things. 1) Either put all your neighbors on the PATHS list first. This will ensure you will not compute routes from your own LSP. Or 2) you put your own LSP on the PATHS list first. But then you must skip the IP prefixes in that LSP. There is no point installing routes in the routing table that you learned from your own advertisements. > Now, while building L2 LSP B will take L1->L2 routes also, ie routes > learned via L1 SPF which contain route to prefix X. Thus L2 LSP of B > will also contain prefix to X. First of all you, in the above scenario should never see that prefix X as a L1 route on B or A. Secondly, a general rule of thumb, which holds true for most routing protocols is: you should never advertise a route you are not using yourself ! Third of all, the prefix that B put in its L1 LSP will have the up/down bit set ! It must. So therefor even if B would compute L1 SPF and would see a L1 route to X, it is not allowed to include that prefix back into its L2 LSP. > Preference order is involved in building routing table only. While > building LSP of one level, it will simply take routes which it learned > from other level SPF. No, there is nothing "simply". There's all sorts of conditions. Which I will not re-list here. > And both level SPF will give a route to prefix > X, so it will be in both LSPs - L1 and L2. No. B will not put prefix X in its L2 LSP. Never. > So now B and C both are advertising route to prefix X in their LSP. B (and A) will never advertise X in their L2 LSP. > So > a routing loop is formed. However it should create problem only when > interface of C connected to prefix X goes down. > > To break this loop, RFC 2966, suggests use of up/down bit to > distinguish L2->L1 route, so that we can discard them while building > L2 LSP. No. Your implementation needs to use a few simple old rules. Don't listen to your own route advertisements. (In the case of a Linkstate routing protocol: don't pick up routes from your own LSPs). And: don't advertise a route you don't use yourself. The up/down bit was introduced for network topologies where you have a backbone, and 2 L1 areas, where each area is connected by 2 L1L2 routers. That is where consistent routing loops could occur. That is where the up/down bit solves a problem. > But the problem is what about reverse situation, L1->L2->L1 loop? If you use the above 2 general rules, you will see that the addition of the up/down bit takes away those problems. Henk. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Feb 20 11:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDvg-000290-DV; Mon, 20 Feb 2006 11:30:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBDvf-00028m-9W for isis-wg@ietf.org; Mon, 20 Feb 2006 11:30:27 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBDve-0004d6-Ul for isis-wg@ietf.org; Mon, 20 Feb 2006 11:30:27 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2006 08:30:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KGTfgu003240 for ; Mon, 20 Feb 2006 08:30:24 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 08:30:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2006 08:30:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: An alternative to RFC 3786 thread-index: AcYzxMWtxFEclkjIQviTQ0jVKaFhRAAGRO6wAADVKs0AAAkAgAAALruPAIEpxFAAALRdYAAEeJHg From: "Les Ginsberg \(ginsberg\)" To: X-OriginalArrivalTime: 20 Feb 2006 16:30:07.0286 (UTC) FILETIME=[E9113560:01C6363A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Isis-wg] An alternative to RFC 3786 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Folks - IS-IS has a limited space to advertise TLVs for a given system-id (256 fragments * the maximum fragment size (nominally 1492 bytes). This space is quite generous when the only advertisements we need to be concerned with are reachability advertisements (neighbors, leaf nodes). However, ever since the days when TE extensions were first introduced, there has been concern about how to cope with what happens if the additional non-routing information the protocol is being asked to carry exceeds the carrying capacity of the LSP set. RFC 3786 was defined as a means of addressing this problem. However, RFC 3786 introduces interoperability issues with systems which do not support the extensions defined therein. These issues were addressed by the following: a)the introduction of two operating modes. Mode 1 is specified in cases where not all systems support the extensions. Mode 2 for when there are no legacy systems. b)Mode 2 also introduces changes to the SPF rules for considering LSPs to allow the normal LSPs and extended LSPs to be considered as a single set. (See RFC 3786 for details) I have long thought that a simpler means of solving the limited LSP space problem could be used if we recognized that the extended LSP space is only required to advertise information not used for the SPF computation. I recently discussed this idea with two of the authors of RFC 3786 and received positive responses. However, given the existence of RFC 3786, I thought it prudent to ask the WG the following questions before beginning the normal discussion procedures: Is the introduction of a simplified replacement for RFC 3786 of interest? Are there any existing deployments of RFC 3786? Thanx in advance for your feedback. Les _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Feb 21 02:52:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBSJk-000511-UA; Tue, 21 Feb 2006 02:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBSJj-00050w-3J for isis-wg@ietf.org; Tue, 21 Feb 2006 02:52:15 -0500 Received: from lhrga01-in.huawei.com ([57.66.76.5] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBSJi-0007GY-P4 for isis-wg@ietf.org; Tue, 21 Feb 2006 02:52:15 -0500 Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV100MBR0U4HV@lhrga01-in.huawei.com> for isis-wg@ietf.org; Tue, 21 Feb 2006 07:30:05 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV10006S20GWE@szxga01-in.huawei.com> for isis-wg@ietf.org; Tue, 21 Feb 2006 15:55:28 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV10059Y1W6UH@szxga01-in.huawei.com> for isis-wg@ietf.org; Tue, 21 Feb 2006 15:55:28 +0800 (CST) Received: from saravanapc ([10.110.102.73]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV100C0727JWX@szxml01-in.huawei.com>; Tue, 21 Feb 2006 15:59:43 +0800 (CST) Date: Tue, 21 Feb 2006 15:43:44 +0800 From: Saravana Kumar Subject: RE: [Isis-wg] An alternative to RFC 3786 In-reply-to: To: ginsberg@cisco.com Message-id: <000001c636ba$8b441670$49666e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Les, We have implemented this sometime back in 2003 and its been deployed in the field since late 2004. Our implementation is based on RFC 3786 but is somewhat simplified in the sense that, irrespective of the mode, we always ensure that the lower order TLVs (NBR, area etc) are present only in the original LSP set. This elimiates the need for adding extra complexities in the implementation, like for instance the mechanism to keep track of which (Extended) LSPSet a particular peer is being advertised in and use that extended virtual system id to form adjacencies with the peer. If I were to change RFC 3786 it would be something along these lines. I would also eliminate the mode-2 support while still keeping the SPF rules to consider the original and extended LSPs as a single LSP set (optional). I'am interested in knowing what alternative approach you are planning and how it is better/simpler than RFC 3786. - Saravana > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Tuesday, February 21, 2006 12:30 AM > To: isis-wg@ietf.org > Subject: [Isis-wg] An alternative to RFC 3786 > > > > Folks - > > IS-IS has a limited space to advertise TLVs for a given > system-id (256 fragments * the maximum fragment size > (nominally 1492 bytes). This space is quite generous when the > only advertisements we need to be concerned with are > reachability advertisements (neighbors, leaf nodes). However, > ever since the days when TE extensions were first introduced, > there has been concern about how to cope with what happens if > the additional non-routing information the protocol is being > asked to carry exceeds the carrying capacity of the LSP set. > > RFC 3786 was defined as a means of addressing this problem. > However, RFC 3786 introduces interoperability issues with > systems which do not support the extensions defined therein. > These issues were addressed by the following: > > a)the introduction of two operating modes. Mode 1 is > specified in cases where not all systems support the > extensions. Mode 2 for when there are no legacy systems. > b)Mode 2 also introduces changes to the SPF rules for > considering LSPs to allow the normal LSPs and extended LSPs > to be considered as a single set. > > (See RFC 3786 for details) > > I have long thought that a simpler means of solving the > limited LSP space problem could be used if we recognized that > the extended LSP space is only required to advertise > information not used for the SPF computation. > > I recently discussed this idea with two of the authors of RFC > 3786 and received positive responses. However, given the > existence of RFC 3786, I thought it prudent to ask the WG the > following questions before beginning the normal discussion procedures: > > Is the introduction of a simplified replacement for RFC 3786 > of interest? Are there any existing deployments of RFC 3786? > > Thanx in advance for your feedback. > > Les > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Tue Feb 21 13:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcGE-0000lz-Ah; Tue, 21 Feb 2006 13:29:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBcGC-0000li-P5 for isis-wg@ietf.org; Tue, 21 Feb 2006 13:29:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBcGC-00006N-Bt for isis-wg@ietf.org; Tue, 21 Feb 2006 13:29:16 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 21 Feb 2006 10:29:16 -0800 X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="1778321352:sNHT34136428" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1LIT1ZO016042; Tue, 21 Feb 2006 10:29:13 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 10:29:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] An alternative to RFC 3786 Date: Tue, 21 Feb 2006 10:29:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] An alternative to RFC 3786 Thread-Index: AcY2u2+k1wz8b10mTjyQVK+xxL8htwAWO17A From: "Les Ginsberg \(ginsberg\)" To: "Saravana Kumar" X-OriginalArrivalTime: 21 Feb 2006 18:29:11.0456 (UTC) FILETIME=[B5BCCA00:01C63714] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Saravana - Thanx for the feedback. It sounds to me that what we have in mind is very similar to what you have implemented - which is good!! As soon as I have a clearer indication that it makes sense to go forward I will make available a draft which will provide all the details. Les > -----Original Message----- > From: Saravana Kumar [mailto:saravanak@huawei.com] > Sent: Monday, February 20, 2006 11:44 PM > To: Les Ginsberg (ginsberg) > Cc: isis-wg@ietf.org > Subject: RE: [Isis-wg] An alternative to RFC 3786 >=20 > Les, >=20 > We have implemented this sometime back in 2003 and its been deployed in > the field since late 2004. Our implementation is based on RFC 3786 but > is somewhat simplified in the sense that, irrespective of the mode, we > always ensure that the lower order TLVs (NBR, area etc) are present only > in the original LSP set. This elimiates the need for adding extra > complexities in the implementation, like for instance the mechanism to > keep track of which (Extended) LSPSet a particular peer is being > advertised in and use that extended virtual system id to form > adjacencies with the peer. >=20 > If I were to change RFC 3786 it would be something along these lines. I > would also eliminate the mode-2 support while still keeping the SPF > rules to consider the original and extended LSPs as a single LSP set > (optional). >=20 > I'am interested in knowing what alternative approach you are planning > and how it is better/simpler than RFC 3786. >=20 > - Saravana >=20 > > -----Original Message----- > > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > > Sent: Tuesday, February 21, 2006 12:30 AM > > To: isis-wg@ietf.org > > Subject: [Isis-wg] An alternative to RFC 3786 > > > > > > > > Folks - > > > > IS-IS has a limited space to advertise TLVs for a given > > system-id (256 fragments * the maximum fragment size > > (nominally 1492 bytes). This space is quite generous when the > > only advertisements we need to be concerned with are > > reachability advertisements (neighbors, leaf nodes). However, > > ever since the days when TE extensions were first introduced, > > there has been concern about how to cope with what happens if > > the additional non-routing information the protocol is being > > asked to carry exceeds the carrying capacity of the LSP set. > > > > RFC 3786 was defined as a means of addressing this problem. > > However, RFC 3786 introduces interoperability issues with > > systems which do not support the extensions defined therein. > > These issues were addressed by the following: > > > > a)the introduction of two operating modes. Mode 1 is > > specified in cases where not all systems support the > > extensions. Mode 2 for when there are no legacy systems. > > b)Mode 2 also introduces changes to the SPF rules for > > considering LSPs to allow the normal LSPs and extended LSPs > > to be considered as a single set. > > > > (See RFC 3786 for details) > > > > I have long thought that a simpler means of solving the > > limited LSP space problem could be used if we recognized that > > the extended LSP space is only required to advertise > > information not used for the SPF computation. > > > > I recently discussed this idea with two of the authors of RFC > > 3786 and received positive responses. However, given the > > existence of RFC 3786, I thought it prudent to ask the WG the > > following questions before beginning the normal discussion procedures: > > > > Is the introduction of a simplified replacement for RFC 3786 > > of interest? Are there any existing deployments of RFC 3786? > > > > Thanx in advance for your feedback. > > > > Les > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www1.ietf.org/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 23 10:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIVH-0007AP-OA; Thu, 23 Feb 2006 10:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIVG-0007A9-LF for isis-wg@ietf.org; Thu, 23 Feb 2006 10:35:38 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIVF-0001ca-D2 for isis-wg@ietf.org; Thu, 23 Feb 2006 10:35:38 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 23 Feb 2006 07:35:36 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,141,1139212800"; d="scan'208"; a="529660960:sNHT23832308" Received: from [172.26.200.95] ([172.26.200.95]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 07:35:36 -0800 Message-ID: <43FDD646.9050400@juniper.net> Date: Thu, 23 Feb 2006 16:35:34 +0100 From: Hannes Gredler User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Les Ginsberg (ginsberg)" Subject: Re: [Isis-wg] An alternative to RFC 3786 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2006 15:35:36.0479 (UTC) FILETIME=[CAC0EAF0:01C6388E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org hi les, some comments inline; Les Ginsberg (ginsberg) wrote: [ ... ] > I have long thought that a simpler means of solving the limited LSP > space > problem could be used if we recognized that the extended LSP space is > only > required to advertise information not used for the SPF computation. well, since the original problem statement has been too store TE information attached to (extd)ID-REACH i would be curious to see your proposal - i am particularly interested how to solve the problem of detaching TE information from SPF relevant (=extd-IS-reach) TLVs ... > I recently discussed this idea with two of the authors of RFC 3786 and > received positive responses. However, given the existence of RFC 3786, > I thought it prudent to ask the WG the following questions before > beginning the normal discussion procedures: > > Is the introduction of a simplified replacement for RFC 3786 of > interest? i do not sense fragment space exhaustion b/c of IS-reach advertisments as a real production problem today. typically the biggest fragment-hog is the L1L2 router when performing route leaking. the largest networks L1L2 routers consume 20-50 fragments mostly for ext-IP reach TLVs today. i am not sure if the the "only" 80% headroom left problem should be tackled at all. > Are there any existing deployments of RFC 3786? none that i am aware of. tx, /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Thu Feb 23 13:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLMG-0003iL-CX; Thu, 23 Feb 2006 13:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLME-0003g9-H0 for isis-wg@ietf.org; Thu, 23 Feb 2006 13:38:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLME-00087I-5b for isis-wg@ietf.org; Thu, 23 Feb 2006 13:38:30 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 23 Feb 2006 10:38:29 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1NIcTHf002045; Thu, 23 Feb 2006 10:38:29 -0800 (PST) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 10:38:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] An alternative to RFC 3786 Date: Thu, 23 Feb 2006 10:38:28 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] An alternative to RFC 3786 Thread-Index: AcY4jsylaZA9x+o7SLykjJEp5lCGRAAGJ/3A From: "Les Ginsberg \(ginsberg\)" To: "Hannes Gredler" X-OriginalArrivalTime: 23 Feb 2006 18:38:29.0534 (UTC) FILETIME=[57343BE0:01C638A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isis-wg-bounces@ietf.org Hannes - Thanx for your reply. Inline. > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Thursday, February 23, 2006 7:36 AM > To: Les Ginsberg (ginsberg) > Cc: isis-wg@ietf.org > Subject: Re: [Isis-wg] An alternative to RFC 3786 >=20 > hi les, >=20 > some comments inline; >=20 > Les Ginsberg (ginsberg) wrote: > [ ... ] > > I have long thought that a simpler means of solving the limited LSP > > space > > problem could be used if we recognized that the extended LSP space is > > only > > required to advertise information not used for the SPF computation. >=20 > well, since the original problem statement has been too store > TE information attached to (extd)ID-REACH i would be curious to > see your proposal - i am particularly interested > how to solve the problem of detaching TE information from > SPF relevant (=3Dextd-IS-reach) TLVs ... >=20 That issue will be discussed in the proposal. (Sneak preview: there is no magic.) > > I recently discussed this idea with two of the authors of RFC 3786 and > > received positive responses. However, given the existence of RFC 3786, > > I thought it prudent to ask the WG the following questions before > > beginning the normal discussion procedures: > > > > Is the introduction of a simplified replacement for RFC 3786 of > > interest? >=20 > i do not sense fragment space exhaustion b/c of IS-reach > advertisments as a real production problem today. >=20 Neither do we. However, given the continued introduction of additional non-routing information to be carried by the IGPs (and more on the way) - it is a possibility. If RFC 3786 was not already defined, I think we would all be happy to wait until the problem became more imminent. But given the existence of RFC 3786, the concern is that when the problem has to be addressed there won't be enough time to agree on an alternative. Once RFC 3786 has significant deployment, it becomes much more difficult to advocate an alternative. So this is primarily an attempt to get what we think is the better alternative in place while there is still an opportunity to do so. Les > typically the biggest fragment-hog is the L1L2 router when performing > route leaking. >=20 > the largest networks L1L2 routers consume 20-50 fragments mostly > for ext-IP reach TLVs today. i am not sure if the > the "only" 80% headroom left problem should be > tackled at all. >=20 > > Are there any existing deployments of RFC 3786? >=20 > none that i am aware of. >=20 > tx, >=20 > /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg