From isis-wg-bounces@ietf.org Fri Jan 7 03:35:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25440 for ; Fri, 7 Jan 2005 03:35:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpYL-00074e-Id; Fri, 07 Jan 2005 03:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpVx-0005th-58 for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 03:30:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25009 for ; Fri, 7 Jan 2005 03:30:31 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmpir-00013M-IR for isis-wg@ietf.org; Fri, 07 Jan 2005 03:43:56 -0500 Received: by rproxy.gmail.com with SMTP id r35so239310rna for ; Fri, 07 Jan 2005 00:30:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=XjZ+ZmMCwDxpaBmsYyTtkhXv6i6Gqt+yL41HQjvrwPIAzBHmDKIdbU6HzZiwFattpJUHa8OuSaQ9NwHykVgOTZRuQ28sKtApSuM/jRaXeXd3FKlb7MhGPSX/XxUdXvejEOA2SgkUXdmbEWmWFUE/upfbZBKmTc5UQzufdSLUH+k= Received: by 10.38.74.75 with SMTP id w75mr376907rna; Fri, 07 Jan 2005 00:30:29 -0800 (PST) Received: by 10.38.102.34 with HTTP; Fri, 7 Jan 2005 00:30:28 -0800 (PST) Message-ID: Date: Fri, 7 Jan 2005 14:00:28 +0530 From: Abhishek Verma To: "ISIS-WG (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Flooding LSPs and HELLOs X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 Content-Transfer-Encoding: 7bit Hello, In link state protocols like ISIS we flood whatever LSPs that we get from our neighbors to our other neighbors, so that everybody fills in the pieces of a big jig-saw puzzle and everyone comes up with a consistent view of the network. Do we then flood all the HELLOs also that we recieve from our neighbors. I believe we dont. Please correct me if i am wrong. We, thus only flood the LSPs that we receive from our neighbors to the adjacent routers and nothing else. Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jan 7 03:54:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26498 for ; Fri, 7 Jan 2005 03:54:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmppb-0004gQ-DW; Fri, 07 Jan 2005 03:50:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmpi7-0002QB-5t for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 03:43:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25959 for ; Fri, 7 Jan 2005 03:43:03 -0500 (EST) Received: from c-230.static.at.kpnqwest.net ([193.154.188.230] helo=ghostrider.gredler.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmpv1-0001yP-9M for isis-wg@ietf.org; Fri, 07 Jan 2005 03:56:28 -0500 Received: from ghostrider.gredler.at (localhost [127.0.0.1]) by ghostrider.gredler.at (8.12.11/8.12.9) with ESMTP id j078gqme020653; Fri, 7 Jan 2005 09:42:53 +0100 Received: (from hannes@localhost) by ghostrider.gredler.at (8.12.11/8.12.11/Submit) id j078gqtx020652; Fri, 7 Jan 2005 09:42:52 +0100 Date: Fri, 7 Jan 2005 09:42:52 +0100 From: Hannes Gredler To: Abhishek Verma Subject: Re: [Isis-wg] Strange p2p adjacencies Message-ID: <20050107084252.GA20632@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "ISIS-WG \(E-mail\)" 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 Tue, Dec 28, 2004 at 04:36:20PM +0530, Abhishek Verma wrote: | Hi, | | In broadcast media by default we form both L1 and L2 adjacencies and | never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in | broadcast media - L1 only and L2 only. Two routers can either have any | one of these or both of these. | | But why in point-to-point do we have either (i) L1 only (ii) L2 only | and (iii) L1/L2. | | Why dont we have two adjacencies L1 and L2 between two p2p links? Why | do we have just one L1/L2 adjacency? on p2p links there is just one IIH codepoint (17) shared for L1/L2 hellos - contrary to bcast media where there is a dedicated codepoint per Level (15,16); /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jan 7 03:58:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26790 for ; Fri, 7 Jan 2005 03:58:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmppy-0004iO-Qh; Fri, 07 Jan 2005 03:51:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmplk-0002xb-J5 for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 03:46:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26141 for ; Fri, 7 Jan 2005 03:46:51 -0500 (EST) Received: from c-230.static.at.kpnqwest.net ([193.154.188.230] helo=ghostrider.gredler.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmpyh-0002CC-DS for isis-wg@ietf.org; Fri, 07 Jan 2005 04:00:16 -0500 Received: from ghostrider.gredler.at (localhost [127.0.0.1]) by ghostrider.gredler.at (8.12.11/8.12.9) with ESMTP id j078kb7d020665; Fri, 7 Jan 2005 09:46:37 +0100 Received: (from hannes@localhost) by ghostrider.gredler.at (8.12.11/8.12.11/Submit) id j078kZ7T020664; Fri, 7 Jan 2005 09:46:35 +0100 Date: Fri, 7 Jan 2005 09:46:35 +0100 From: Hannes Gredler To: Abhishek Verma Subject: Re: [Isis-wg] Strange p2p adjacencies Message-ID: <20050107084635.GB20632@juniper.net> References: <000001c4ecd7$c2da32a0$7204120a@in.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "ISIS-WG \(E-mail\)" 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 Tue, Dec 28, 2004 at 06:26:52PM +0530, Abhishek Verma wrote: | Hemanth, | | This tells me why we can have only one kind of adjacency in P2P links. | And thanks for that! | | But why is this so? Why has ISIS been so designed? Why do we then have | 2 kinds of adjacencies in Broadcast media? | | Any clues? the original idea was to save bandwidth on low-bandwidth links; given that most IS-IS adjacencies these days run on fat pipes and control-plane processors have suffiecient CPU IMHO the once optimization does more harm (e.g. confusion about per-Level passwords etc.) than good. /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jan 7 03:59:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26912 for ; Fri, 7 Jan 2005 03:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmpqk-00054Z-Gz; Fri, 07 Jan 2005 03:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmpmT-0003W1-3b for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 03:47:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26186 for ; Fri, 7 Jan 2005 03:47:35 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmpzN-0002CM-Tu for isis-wg@ietf.org; Fri, 07 Jan 2005 04:01:00 -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 <0I9X00NX3V391S@szxga02-in.huawei.com> for isis-wg@ietf.org; Fri, 07 Jan 2005 16:47:33 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I9X007YLV39YR@szxga02-in.huawei.com> for isis-wg@ietf.org; Fri, 07 Jan 2005 16:47:33 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0I9X00KRLV7II2@szxml01-in.huawei.com>; Fri, 07 Jan 2005 16:50:07 +0800 (CST) Date: Fri, 07 Jan 2005 14:23:25 +0530 From: hemanthbs Subject: RE: [Isis-wg] Flooding LSPs and HELLOs In-reply-to: To: "'Abhishek Verma'" , "'ISIS-WG (E-mail)'" Message-id: <000201c4f496$5a018fa0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7BIT X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@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 Content-Transfer-Encoding: 7BIT Hi, Yes we flooding only the LSPs. In link state protocols(ISIS,OSPF) all routers in the network should have identical information about the network(other routers), that is there should be a synchronization of the databases between all routers in the network. This is achieved with the help of flooding.i.e we flood the LSPs on all links except the one we received on. Hellos are not flooded.Hellos are significant only w.r.t to a pair of routers connected on that particular link(P2P) or set of routers (on LAN). Their main purpose is to establish & maintain peers. bye S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Abhishek Verma Sent: Friday, January 07, 2005 2:00 PM To: ISIS-WG (E-mail) Subject: [Isis-wg] Flooding LSPs and HELLOs Hello, In link state protocols like ISIS we flood whatever LSPs that we get from our neighbors to our other neighbors, so that everybody fills in the pieces of a big jig-saw puzzle and everyone comes up with a consistent view of the network. Do we then flood all the HELLOs also that we recieve from our neighbors. I believe we dont. Please correct me if i am wrong. We, thus only flood the LSPs that we receive from our neighbors to the adjacent routers and nothing else. Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ 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 Fri Jan 7 04:01:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27133 for ; Fri, 7 Jan 2005 04:01:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmprm-0005fC-7d; Fri, 07 Jan 2005 03:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmpnj-0004PN-Jd for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 03:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26244 for ; Fri, 7 Jan 2005 03:48:54 -0500 (EST) Received: from c-230.static.at.kpnqwest.net ([193.154.188.230] helo=ghostrider.gredler.at) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cmq0g-0002Qc-5S for isis-wg@ietf.org; Fri, 07 Jan 2005 04:02:19 -0500 Received: from ghostrider.gredler.at (localhost [127.0.0.1]) by ghostrider.gredler.at (8.12.11/8.12.9) with ESMTP id j078mqrj020672; Fri, 7 Jan 2005 09:48:52 +0100 Received: (from hannes@localhost) by ghostrider.gredler.at (8.12.11/8.12.11/Submit) id j078mqdf020671; Fri, 7 Jan 2005 09:48:52 +0100 Date: Fri, 7 Jan 2005 09:48:52 +0100 From: Hannes Gredler To: Abhishek Verma Subject: Re: [Isis-wg] Flooding LSPs and HELLOs Message-ID: <20050107084852.GC20632@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "ISIS-WG \(E-mail\)" 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 Fri, Jan 07, 2005 at 02:00:28PM +0530, Abhishek Verma wrote: | Hello, | | In link state protocols like ISIS we flood whatever LSPs that we get | from our neighbors to our other neighbors, so that everybody fills in | the pieces of a big jig-saw puzzle and everyone comes up with a | consistent view of the network. Do we then flood all the HELLOs also | that we recieve from our neighbors. I believe we dont. Please correct | me if i am wrong. there is no notion of flooding for IIHs, see IIHs are not "flooded" as they always have a link-local meaning and are not significant on other ends of teh network; | We, thus only flood the LSPs that we receive from our neighbors to the | adjacent routers and nothing else. not to forget the self-originated LSPs of course which are flooded to all the neighbors; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jan 7 06:36:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06655 for ; Fri, 7 Jan 2005 06:36:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmsNe-0001UL-Hz; Fri, 07 Jan 2005 06:34:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmsMq-00019F-3l for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 06:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06282 for ; Fri, 7 Jan 2005 06:33:16 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmsZl-0004wo-6Z for isis-wg@ietf.org; Fri, 07 Jan 2005 06:46:44 -0500 Received: by rproxy.gmail.com with SMTP id c16so381756rne for ; Fri, 07 Jan 2005 03:33:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ofMiZPCeatFq7gbjYuv2Me/lTiAqgxK+vhU90wgcU1BLHOk0WWpuY4eGIW4TkWQ7ndWXVp2KKZFpDscjvdsF8Fupf56Y4ciOLyTwnCLJeN+IbtsYokEszU0I2LM0TjaWvEkFMyzVvOxt9Xs2qAFY10nt6v8G72IkLm7lOaDNe6o= Received: by 10.38.68.14 with SMTP id q14mr359096rna; Fri, 07 Jan 2005 03:33:15 -0800 (PST) Received: by 10.38.102.7 with HTTP; Fri, 7 Jan 2005 03:33:15 -0800 (PST) Message-ID: Date: Fri, 7 Jan 2005 17:03:15 +0530 From: Abhishek Verma To: Hannes Gredler Subject: Re: [Isis-wg] Strange p2p adjacencies In-Reply-To: <20050107084635.GB20632@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <000001c4ecd7$c2da32a0$7204120a@in.huawei.com> <20050107084635.GB20632@juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "ISIS-WG \(E-mail\)" X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abhishek Verma 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 Content-Transfer-Encoding: 7bit Hi Hannes, > the original idea was to save bandwidth on low-bandwidth links; I fail to understand as to how this can result in saving the bandwidth on low-bandwidth links? In fact it now makes things even worse. With having two kinds of adjacecnies in broadcast networks arent we utilizing more bandwidth. Or did you mean that having an L1/L2 adjacency was because of lower bandwidth requirements! > > given that most IS-IS adjacencies these days run on fat pipes > and control-plane processors have suffiecient CPU > IMHO the once optimization does more harm (e.g. confusion about > per-Level passwords etc.) than good. > > /hannes > -- -- Class of 2004 Institute of Technology, BHU Varanasi, India _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Fri Jan 7 16:27:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00063 for ; Fri, 7 Jan 2005 16:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn1Yb-0007N9-K9; Fri, 07 Jan 2005 16:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cn1OV-0000W5-TL for isis-wg@megatron.ietf.org; Fri, 07 Jan 2005 16:11:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28786 for ; Fri, 7 Jan 2005 16:11:37 -0500 (EST) Received: from smtp5.indiatimes.com ([203.199.93.15] helo=WS0005.indiatimes.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cn1bW-0002ur-45 for isis-wg@ietf.org; Fri, 07 Jan 2005 16:25:09 -0500 Received: from 192.168.57.15 ([192.168.57.73]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id CAA03420; Sat, 8 Jan 2005 02:35:40 +0530 From: "appallar" Message-Id: <200501072105.CAA03420@WS0005.indiatimes.com> To: "Hannes Gredler", "Abhishek Verma" Subject: Re: Re: [Isis-wg] Strange p2p adjacencies Date: Sat, 08 Jan 2005 02:42:09 -0500 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.8 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ISIS-WG E-mail X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: appallar 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 Hello, In a broadcast medium, there could be multiple routers connected, hence we need to know which routers are L1 and which are L2 so we have two types of hellos to keep track of all L1 and L2 routers, where as in p2p network, we have only one system on the other end, hence we need to know the system type of the neighbor and have adjacency as L1 or L2 or L12. Suryanarayana "Hannes Gredler" wrote: On Tue, Dec 28, 2004 at 06:26:52PM +0530, Abhishek Verma wrote: | Hemanth, | | This tells me why we can have only one kind of adjacency in P2P links. | And thanks for that! | | But why is this so? Why has ISIS been so designed? Why do we then have | 2 kinds of adjacencies in Broadcast media? | | Any clues? the original idea was to save bandwidth on low-bandwidth links; given that most IS-IS adjacencies these days run on fat pipes and control-plane processors have suffiecient CPU IMHO the once optimization does more harm (e.g. confusion about per-Level passwords etc.) than good. /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg ------------------------------------------------------------------------- Email Powered and Protected by IronPort and Sophos Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Wed Jan 12 18:33:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29015 for ; Wed, 12 Jan 2005 18:33:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorkX-0002kO-Vo; Wed, 12 Jan 2005 18:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorhR-0000jP-DL; Wed, 12 Jan 2005 18:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27578; Wed, 12 Jan 2005 18:14:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CorvX-0002wr-Th; Wed, 12 Jan 2005 18:29:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:14:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNE6l2006174; Wed, 12 Jan 2005 15:14:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-181.cisco.com [10.86.240.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09242; Wed, 12 Jan 2005 15:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) To: Mailing List , mpls@ietf.org, idr@ietf.org, ccamp@ops.ietf.org, isis-wg@ietf.org Message-Id: From: JP Vasseur Date: Wed, 12 Jan 2005 18:14:19 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 Subject: [Isis-wg] Fwd: WG Action: Path Computation Element (pce) 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: , Content-Type: multipart/mixed; boundary="===============2125510145==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org --===============2125510145== Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577 --Apple-Mail-42-562924577 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: > From: The IESG > Date: January 12, 2005 3:39:31 PM EST > To: IETF-Announce@ietf.org > Cc: pce@ietf.org, Adrian Farrel , JP Vasseur > > Subject: WG Action: Path Computation Element (pce) > > A new IETF working group has been formed in the Routing Area. For > additional > information, please contact the Area Directors or the WG Chairs. > > Path Computation Element (pce) > ================================ > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > JP Vasseur > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: pce@ietf.org > To Subscribe: pce-request@ietf.org > In Body: subscribe pce > Archive: http://www.ietf.org/mail-archive/web/pce/ > > Description of Working Group: > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) > based architecture for the computation of paths for MPLS and GMPLS > Traffic > Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) > LSR, but on some other path computation entity that may physically not > be > located on the head-end LSR. > > The PCE WG will work on application of this model within a single > domain > or within a small group of domains (where a domain is a layer, IGP area > or Autonomous System with limited visibility from the head-end LSR). > At this time, applying this model to large groups of domains such as > the > Internet is not thought to be possible, and the PCE WG will not spend > energy on that topic. > > The WG will specify a protocol for communication between LSRs (termed > Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. > This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and > will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing > and > signaling protocols in support of PCE discovery and signaling of > inter-domain > paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, > ISIS-TE and > BGP. Any necessary extensions will be produced in collaboration with > the > Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to > evaluate path quality, scalability, responsiveness and robustness of > path computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path > computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) > reoptimization and load balancing. The WG will address the inter-area > (single IGP domain) scenario first. WG progress will be evaluated > before > inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving > PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in > conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > > Goals and Milestones: > > Feb 05: Submit first draft of PCE architecture document > > Feb 05: Submit first draft of PCE discovery requirements and protocol > extensions documents > > Apr 05: Submit first draft of the PCE communication protocol > requirements > > May 05: Submit first draft of the definition of objective metrics > > Jul 05: Submit first draft of the PCE communication protocol > specification > > Aug 05: Submit PCE architecture specification to the IESG to be > considered as Informational RFC > > Nov 05: Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols > and protocol extensions for inter-area MPLS and GMPLS Traffic > Engineering) > > Nov 05: Submit first draft of the MIB module for the PCE protocol > > Dec 05: Submit PCE communication protocol requirements to the IESG to > be > considered as an Informational RFC > > Dec 05: Submit PCE discovery protocol extensions specifications to the > IESG to be considered as a Proposed Standard > > Dec 05: Submit PCE communication protocol specification to the IESG to > be considered as a Proposed Standard > > Feb 06: Submit the applicability and metrics documents to the IESG to > be > considered as Informational RFC > > Feb 06: Evaluate WG progress, recharter or close. > --Apple-Mail-42-562924577 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: Helvetica0000,0000,0000From: HelveticaThe IESG < 0000,0000,0000Date: January 12, 2005 3:39:31 PM EST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: pce@ietf.org, Adrian Farrel <, JP Vasseur < 0000,0000,0000Subject: WG Action: Path Computation Element (pce) A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel < JP Vasseur < Routing Area Director(s): Bill Fenner < Alex Zinin < Routing Area Advisor: Alex Zinin < Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05: Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06: Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06: Evaluate WG progress, recharter or close. --Apple-Mail-42-562924577-- --===============2125510145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============2125510145==-- From isis-wg-bounces@ietf.org Wed Jan 12 18:54:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00607 for ; Wed, 12 Jan 2005 18:54:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosAC-0000oz-D5; Wed, 12 Jan 2005 18:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cos0q-0007QA-Il; Wed, 12 Jan 2005 18:34:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29191; Wed, 12 Jan 2005 18:34:49 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosEw-0003JT-TM; Wed, 12 Jan 2005 18:49:27 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA01785; Wed, 12 Jan 2005 15:34:17 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0CNYGhZ014560; Wed, 12 Jan 2005 15:34:16 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0CNY4pP014483; Wed, 12 Jan 2005 15:34:06 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorkZ-0002kV-0R; Wed, 12 Jan 2005 18:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorhR-0000jP-DL; Wed, 12 Jan 2005 18:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27578; Wed, 12 Jan 2005 18:14:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CorvX-0002wr-Th; Wed, 12 Jan 2005 18:29:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:14:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNE6l2006174; Wed, 12 Jan 2005 15:14:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-181.cisco.com [10.86.240.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09242; Wed, 12 Jan 2005 15:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) To: Mailing List , mpls@ietf.org, idr@ietf.org, ccamp@ops.ietf.org, isis-wg@ietf.org Message-Id: From: JP Vasseur Date: Wed, 12 Jan 2005 18:14:19 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Content-Type: multipart/mixed; boundary="===============0288458767==" X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mgate1.riverstonenet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Subject: [Isis-wg] [mpls] Fwd: WG Action: Path Computation Element (pce) X-BeenThere: isis-wg@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 --===============0288458767== Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577 --Apple-Mail-42-562924577 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: > From: The IESG > Date: January 12, 2005 3:39:31 PM EST > To: IETF-Announce@ietf.org > Cc: pce@ietf.org, Adrian Farrel , JP Vasseur > > Subject: WG Action: Path Computation Element (pce) > > A new IETF working group has been formed in the Routing Area. For > additional > information, please contact the Area Directors or the WG Chairs. > > Path Computation Element (pce) > ================================ > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > JP Vasseur > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: pce@ietf.org > To Subscribe: pce-request@ietf.org > In Body: subscribe pce > Archive: http://www.ietf.org/mail-archive/web/pce/ > > Description of Working Group: > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) > based architecture for the computation of paths for MPLS and GMPLS > Traffic > Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) > LSR, but on some other path computation entity that may physically not > be > located on the head-end LSR. > > The PCE WG will work on application of this model within a single > domain > or within a small group of domains (where a domain is a layer, IGP area > or Autonomous System with limited visibility from the head-end LSR). > At this time, applying this model to large groups of domains such as > the > Internet is not thought to be possible, and the PCE WG will not spend > energy on that topic. > > The WG will specify a protocol for communication between LSRs (termed > Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. > This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and > will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing > and > signaling protocols in support of PCE discovery and signaling of > inter-domain > paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, > ISIS-TE and > BGP. Any necessary extensions will be produced in collaboration with > the > Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to > evaluate path quality, scalability, responsiveness and robustness of > path computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path > computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) > reoptimization and load balancing. The WG will address the inter-area > (single IGP domain) scenario first. WG progress will be evaluated > before > inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving > PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in > conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > > Goals and Milestones: > > Feb 05: Submit first draft of PCE architecture document > > Feb 05: Submit first draft of PCE discovery requirements and protocol > extensions documents > > Apr 05: Submit first draft of the PCE communication protocol > requirements > > May 05: Submit first draft of the definition of objective metrics > > Jul 05: Submit first draft of the PCE communication protocol > specification > > Aug 05: Submit PCE architecture specification to the IESG to be > considered as Informational RFC > > Nov 05: Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols > and protocol extensions for inter-area MPLS and GMPLS Traffic > Engineering) > > Nov 05: Submit first draft of the MIB module for the PCE protocol > > Dec 05: Submit PCE communication protocol requirements to the IESG to > be > considered as an Informational RFC > > Dec 05: Submit PCE discovery protocol extensions specifications to the > IESG to be considered as a Proposed Standard > > Dec 05: Submit PCE communication protocol specification to the IESG to > be considered as a Proposed Standard > > Feb 06: Submit the applicability and metrics documents to the IESG to > be > considered as Informational RFC > > Feb 06: Evaluate WG progress, recharter or close. > --Apple-Mail-42-562924577 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: Helvetica0000,0000,0000From: HelveticaThe IESG < 0000,0000,0000Date: January 12, 2005 3:39:31 PM EST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: pce@ietf.org, Adrian Farrel <, JP Vasseur < 0000,0000,0000Subject: WG Action: Path Computation Element (pce) A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel < JP Vasseur < Routing Area Director(s): Bill Fenner < Alex Zinin < Routing Area Advisor: Alex Zinin < Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05: Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06: Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06: Evaluate WG progress, recharter or close. --Apple-Mail-42-562924577-- --===============0288458767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0288458767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0288458767==-- From isis-wg-bounces@ietf.org Wed Jan 12 19:05:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01442 for ; Wed, 12 Jan 2005 19:05:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosIL-0002K8-15; Wed, 12 Jan 2005 18:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cos1T-0007cB-Rw; Wed, 12 Jan 2005 18:35:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29258; Wed, 12 Jan 2005 18:35:29 -0500 (EST) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosFa-0003KV-G2; Wed, 12 Jan 2005 18:50:07 -0500 Received: from mgate1.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA01872; Wed, 12 Jan 2005 15:34:58 -0800 (PST) Received: (from daemon@localhost) by mgate1.riverstonenet.com (8.13.1/8.13.1) id j0CNYwEl014667; Wed, 12 Jan 2005 15:34:58 -0800 (PST) X-Authentication-Warning: mgate1.riverstonenet.com: Processed by daemon with -C /etc/mail/sendmail-simple.cf Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by mgate1.riverstonenet.com (8.13.1/8.13.1) with ESMTP id j0CNYiqM014630; Wed, 12 Jan 2005 15:34:53 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorkZ-0002kV-9H; Wed, 12 Jan 2005 18:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CorhR-0000jP-DL; Wed, 12 Jan 2005 18:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27578; Wed, 12 Jan 2005 18:14:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CorvX-0002wr-Th; Wed, 12 Jan 2005 18:29:24 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2005 15:14:15 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0CNE6l2006174; Wed, 12 Jan 2005 15:14:07 -0800 (PST) Received: from [192.168.1.101] (che-vpn-cluster-1-181.cisco.com [10.86.240.181]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA09242; Wed, 12 Jan 2005 15:14:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) To: Mailing List , mpls@ietf.org, idr@ietf.org, ccamp@ops.ietf.org, isis-wg@ietf.org Message-Id: From: JP Vasseur Date: Wed, 12 Jan 2005 18:14:19 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 94902b99ee6852833c9a2b680a1de4d3 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Content-Type: multipart/mixed; boundary="===============0288458767==" X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mgate1.riverstonenet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Subject: [Isis-wg] [mpls] Fwd: WG Action: Path Computation Element (pce) X-BeenThere: isis-wg@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 --===============0288458767== Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577 --Apple-Mail-42-562924577 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: > From: The IESG > Date: January 12, 2005 3:39:31 PM EST > To: IETF-Announce@ietf.org > Cc: pce@ietf.org, Adrian Farrel , JP Vasseur > > Subject: WG Action: Path Computation Element (pce) > > A new IETF working group has been formed in the Routing Area. For > additional > information, please contact the Area Directors or the WG Chairs. > > Path Computation Element (pce) > ================================ > > Current Status: Active Working Group > > Chair(s): > Adrian Farrel > JP Vasseur > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > Alex Zinin > > Mailing Lists: > General Discussion: pce@ietf.org > To Subscribe: pce-request@ietf.org > In Body: subscribe pce > Archive: http://www.ietf.org/mail-archive/web/pce/ > > Description of Working Group: > > The PCE Working Group is chartered to specify a Path Computation > Element (PCE) > based architecture for the computation of paths for MPLS and GMPLS > Traffic > Engineering LSPs. > > In this architecture path computation does not occur on the head-end > (ingress) > LSR, but on some other path computation entity that may physically not > be > located on the head-end LSR. > > The PCE WG will work on application of this model within a single > domain > or within a small group of domains (where a domain is a layer, IGP area > or Autonomous System with limited visibility from the head-end LSR). > At this time, applying this model to large groups of domains such as > the > Internet is not thought to be possible, and the PCE WG will not spend > energy on that topic. > > The WG will specify a protocol for communication between LSRs (termed > Path > Computation Clients - PCCs) and PCEs, and between cooperating PCEs. > This > protocol will be capable of representing requests for path computation > including a full set of constraints, will be able to return multiple > paths, and > will include security mechanisms such as authentication and > confidentiality. > > The WG will determine requirements for extensions to existing routing > and > signaling protocols in support of PCE discovery and signaling of > inter-domain > paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, > ISIS-TE and > BGP. Any necessary extensions will be produced in collaboration with > the > Working Groups responsible for the protocols. > > The Working Group will also work on the definition of metrics to > evaluate path quality, scalability, responsiveness and robustness of > path computation models. > > Work Items: > > - Functional specification of MPLS and GMPLS Traffic Engineered LSP > path > computation models involving Path Computation Element(s). This > includes the case of computing the paths of intra and inter-domain > TE LSPs. Such path computation includes the generation of primary, > protection and recovery paths, as well as computations for > (local/global) > reoptimization and load balancing. The WG will address the inter-area > (single IGP domain) scenario first. WG progress will be evaluated > before > inter-AS related work is started. > > - Specification of the PCE-based architecture. > > - Specification of requirements and protocol extensions related to > the policy, and security aspects of PCE-based path computation > involving > PCEs of multiple administrative entities. > > - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models. > > - Specification of techniques in support of PCE discovery within and > across domains. Where such techniques result in the extensions of > existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in > conjunction with the appropriate WGs. > > - Specification of a new communication protocol for use between a PCC > and a PCE, and between PCEs. A single protocol will be selected from > among candidates that include the existing protocols defined in other > WGs. > > - Definition of objective metrics to evaluate various criteria such as > the measurement of path quality, response time, robustness and > scalability of path computation models. > > Review of the document "Requirements for path computation element in > GMPLS inter-domain networks" produced by the CCAMP WG. > > > Goals and Milestones: > > Feb 05: Submit first draft of PCE architecture document > > Feb 05: Submit first draft of PCE discovery requirements and protocol > extensions documents > > Apr 05: Submit first draft of the PCE communication protocol > requirements > > May 05: Submit first draft of the definition of objective metrics > > Jul 05: Submit first draft of the PCE communication protocol > specification > > Aug 05: Submit PCE architecture specification to the IESG to be > considered as Informational RFC > > Nov 05: Submit first draft of applicability statement (describing the > processes > and procedures for the use of the PCE architecture, protocols > and protocol extensions for inter-area MPLS and GMPLS Traffic > Engineering) > > Nov 05: Submit first draft of the MIB module for the PCE protocol > > Dec 05: Submit PCE communication protocol requirements to the IESG to > be > considered as an Informational RFC > > Dec 05: Submit PCE discovery protocol extensions specifications to the > IESG to be considered as a Proposed Standard > > Dec 05: Submit PCE communication protocol specification to the IESG to > be considered as a Proposed Standard > > Feb 06: Submit the applicability and metrics documents to the IESG to > be > considered as Informational RFC > > Feb 06: Evaluate WG progress, recharter or close. > --Apple-Mail-42-562924577 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit FYI, JP. Begin forwarded message: Helvetica0000,0000,0000From: HelveticaThe IESG < 0000,0000,0000Date: January 12, 2005 3:39:31 PM EST 0000,0000,0000To: IETF-Announce@ietf.org 0000,0000,0000Cc: pce@ietf.org, Adrian Farrel <, JP Vasseur < 0000,0000,0000Subject: WG Action: Path Computation Element (pce) A new IETF working group has been formed in the Routing Area. For additional information, please contact the Area Directors or the WG Chairs. Path Computation Element (pce) ================================ Current Status: Active Working Group Chair(s): Adrian Farrel < JP Vasseur < Routing Area Director(s): Bill Fenner < Alex Zinin < Routing Area Advisor: Alex Zinin < Mailing Lists: General Discussion: pce@ietf.org To Subscribe: pce-request@ietf.org In Body: subscribe pce Archive: http://www.ietf.org/mail-archive/web/pce/ Description of Working Group: The PCE Working Group is chartered to specify a Path Computation Element (PCE) based architecture for the computation of paths for MPLS and GMPLS Traffic Engineering LSPs. In this architecture path computation does not occur on the head-end (ingress) LSR, but on some other path computation entity that may physically not be located on the head-end LSR. The PCE WG will work on application of this model within a single domain or within a small group of domains (where a domain is a layer, IGP area or Autonomous System with limited visibility from the head-end LSR). At this time, applying this model to large groups of domains such as the Internet is not thought to be possible, and the PCE WG will not spend energy on that topic. The WG will specify a protocol for communication between LSRs (termed Path Computation Clients - PCCs) and PCEs, and between cooperating PCEs. This protocol will be capable of representing requests for path computation including a full set of constraints, will be able to return multiple paths, and will include security mechanisms such as authentication and confidentiality. The WG will determine requirements for extensions to existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, ISIS-TE and BGP. Any necessary extensions will be produced in collaboration with the Working Groups responsible for the protocols. The Working Group will also work on the definition of metrics to evaluate path quality, scalability, responsiveness and robustness of path computation models. Work Items: - Functional specification of MPLS and GMPLS Traffic Engineered LSP path computation models involving Path Computation Element(s). This includes the case of computing the paths of intra and inter-domain TE LSPs. Such path computation includes the generation of primary, protection and recovery paths, as well as computations for (local/global) reoptimization and load balancing. The WG will address the inter-area (single IGP domain) scenario first. WG progress will be evaluated before inter-AS related work is started. - Specification of the PCE-based architecture. - Specification of requirements and protocol extensions related to the policy, and security aspects of PCE-based path computation involving PCEs of multiple administrative entities. - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models. - Specification of techniques in support of PCE discovery within and across domains. Where such techniques result in the extensions of existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in conjunction with the appropriate WGs. - Specification of a new communication protocol for use between a PCC and a PCE, and between PCEs. A single protocol will be selected from among candidates that include the existing protocols defined in other WGs. - Definition of objective metrics to evaluate various criteria such as the measurement of path quality, response time, robustness and scalability of path computation models. Review of the document "Requirements for path computation element in GMPLS inter-domain networks" produced by the CCAMP WG. Goals and Milestones: Feb 05: Submit first draft of PCE architecture document Feb 05: Submit first draft of PCE discovery requirements and protocol extensions documents Apr 05: Submit first draft of the PCE communication protocol requirements May 05: Submit first draft of the definition of objective metrics Jul 05: Submit first draft of the PCE communication protocol specification Aug 05: Submit PCE architecture specification to the IESG to be considered as Informational RFC Nov 05: Submit first draft of applicability statement (describing the processes and procedures for the use of the PCE architecture, protocols and protocol extensions for inter-area MPLS and GMPLS Traffic Engineering) Nov 05: Submit first draft of the MIB module for the PCE protocol Dec 05: Submit PCE communication protocol requirements to the IESG to be considered as an Informational RFC Dec 05: Submit PCE discovery protocol extensions specifications to the IESG to be considered as a Proposed Standard Dec 05: Submit PCE communication protocol specification to the IESG to be considered as a Proposed Standard Feb 06: Submit the applicability and metrics documents to the IESG to be considered as Informational RFC Feb 06: Evaluate WG progress, recharter or close. --Apple-Mail-42-562924577-- --===============0288458767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============0288458767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============0288458767==-- From isis-wg-bounces@ietf.org Fri Jan 14 16:12:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19758 for ; Fri, 14 Jan 2005 16:12:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpYGA-0002Iz-Em; Fri, 14 Jan 2005 15:41:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpY8C-0003u9-HD; Fri, 14 Jan 2005 15:33:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14373; Fri, 14 Jan 2005 15:33:14 -0500 (EST) Message-Id: <200501142033.PAA14373@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 14 Jan 2005 15:33:14 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-link-attr-00.txt 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 --NextPart X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA14373 Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the IS-IS for IP Internets Working Group of = the IETF. Title : Definition of an IS-IS Link Attribute sub-TLV Author(s) : J. Vasseur, S. Previdi Filename : draft-ietf-isis-link-attr-00.txt Pages : 6 Date : 2005-1-14 =09 This document defines a sub-TLV called =F4Link-attributes=F6 carried=20 within the TLV 22 and used to flood some link characteristics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-link-attr-00.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of th= e message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usern= ame "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-link-attr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-link-attr-00.txt". =09 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. =09 =09 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: <2005-1-14153311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-link-attr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-link-attr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-14153311.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Mon Jan 17 16:56:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24369 for ; Mon, 17 Jan 2005 16:56:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqeA2-0003X4-ON; Mon, 17 Jan 2005 16:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqe5L-0001K2-HJ; Mon, 17 Jan 2005 16:06:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14823; Mon, 17 Jan 2005 16:06:49 -0500 (EST) Message-Id: <200501172106.QAA14823@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 17 Jan 2005 16:06:49 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-ipv6-te-00.txt 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 --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 : IPv6 Traffic Engineering in IS-IS Author(s) : J. Harrison, et al. Filename : draft-ietf-isis-ipv6-te-00.txt Pages : 10 Date : 2005-1-17 This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-te-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-ipv6-te-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-ipv6-te-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-17154020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-ipv6-te-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-ipv6-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-17154020.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Tue Jan 18 16:13:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05523 for ; Tue, 18 Jan 2005 16:13:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr08i-0004U2-AF; Tue, 18 Jan 2005 15:39:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr06R-0003Vy-Ui; Tue, 18 Jan 2005 15:37:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29356; Tue, 18 Jan 2005 15:37:25 -0500 (EST) Message-Id: <200501182037.PAA29356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 18 Jan 2005 15:37:25 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-experimental-tlv-04.txt 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 --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 : TLV for Experimental Use Author(s) : P. Christian Filename : draft-ietf-isis-experimental-tlv-04.txt Pages : 6 Date : 2005-1-18 This document defines a TLV that may be used by any individual, company or other organisation for experimental extensions to the IS-IS routing protocol, and defines the format of the TLV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-experimental-tlv-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-experimental-tlv-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-18160604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-experimental-tlv-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-experimental-tlv-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-18160604.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From okelele03@zmail.pt Tue Jan 25 09:07:26 2005 Received: from multiplexer1.zmail.pt ([81.92.212.80]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05364 for ; Tue, 25 Jan 2005 09:07:25 -0500 (EST) Received: (from WorldClient [81.92.212.3]) by multiplexer1.zmail.pt (SMSSMTP 4.0.0.59) with SMTP id M2005012511180506909 ; Tue, 25 Jan 2005 11:18:05 GMT Received: from [81.92.212.2] via WorldClient with HTTP; Tue, 25 Jan 2005 11:12:27 +0000 Date: Tue, 25 Jan 2005 11:12:27 +0000 From: "okelele john" Subject: VERY URGENT. MIME-Version: 1.0 Content-Type: text/plain Message-ID: X-Mailer: WorldClient 7.2.0 5, Meridian East Leicester LE3 2WZ Leicester City, United Kingdom E-mail: captain_okelele@yahoo.com okelele03@netscape.net captain_okelele@freezone.co.uk FROM: CAPT JOHN OKELELE I got your contact address through internet browsing in my search for a reliable and trustworthy person who will assist me in a business investment venture in your country, I am Captain JOHN OKELE the former Commander of the Security Guards of the late Laurent Kabila (former President, Democratic Republic of Congo (Africa), I am presently in self-exile with my wife and one child in remote Leicester City Britain, due to threat of the present Government headed by the son of Late Laurent Kabila after my life and my family to kill, saying that I know about the death of his father. I assisted Late President Laurent Kabila to keep US $19M(Nineteen Millions Dollar) in a Security company in Europe during the War in My Country. Although the security company does not know the content in the boxes deposited as we deposit it as personal effects of Mr. Laurent Kabila. It is in this respect that I seek your help to assist me in the investment of these funds before the present Government headed by the son will have knowledge of this money to avoid being take away. On conclusion of this business, I shall compensate you with 45%of the fund, while 5% is mapped out for any expense we should encounter during the cause of transaction, and the remaining amount should be used to open account for my family for investment over there with your assistance. I need a profitable long term investment plan with your company or you. Your terms, suggestions and idea are required urgently. Expecting your prompt response. Also furnish me with your current E-mail address,Tel/Fax Numbers (Private) for a personal contact with you. Yours Faithfully, Capt JOHN OKELE. Email:captain_okelele@yahoo.coM Nb, Please response to my private email addresses, Email:captain_okelele@yahoo.com okelele03@netscape.net captain_okelele@freezone.co.uk From isis-wg-bounces@ietf.org Wed Jan 26 16:07:46 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18687 for ; Wed, 26 Jan 2005 16:07:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtttG-0005Ve-U8; Wed, 26 Jan 2005 15:35:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cttpb-0003Jt-GH; Wed, 26 Jan 2005 15:32:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12266; Wed, 26 Jan 2005 15:32:01 -0500 (EST) Message-Id: <200501262032.PAA12266@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 26 Jan 2005 15:32:00 -0500 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-caps-00.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS extensions for advertising router information Author(s) : J. Vasseur, et al. Filename : draft-ietf-isis-caps-00.txt Pages : 8 Date : 2005-1-26 This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-caps-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-caps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-caps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-1-26155604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-caps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-caps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-1-26155604.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --NextPart-- From isis-wg-bounces@ietf.org Fri Jan 28 10:09:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06356 for ; Fri, 28 Jan 2005 10:09:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuXiQ-0005gL-RL; Fri, 28 Jan 2005 10:07:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuXa3-00031h-Ve for isis-wg@megatron.ietf.org; Fri, 28 Jan 2005 09:58:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05687 for ; Fri, 28 Jan 2005 09:58:37 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuXrN-0006rW-NX for isis-wg@ietf.org; Fri, 28 Jan 2005 10:16:35 -0500 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id CC18AE000461 for ; Fri, 28 Jan 2005 14:58:03 +0000 (GMT) Received: from Puppy ([212.43.203.226] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Jan 2005 14:57:21 +0000 Message-ID: <030a01c50549$ef215de0$cacb2bd4@Puppy> From: "Adrian Farrel" To: Date: Fri, 28 Jan 2005 12:38:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 28 Jan 2005 14:57:22.0293 (UTC) FILETIME=[ABCBAA50:01C50549] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] TE Router ID in draft-ietf-isis-ipv6-te-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel 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 Content-Transfer-Encoding: 7bit Hi, It has been brought to my attention that this draft includes some ambiguous text... 3.2.1 TE Router ID TLV The TE Router ID TLV is a stable IPv4 address that is routable, regardless of the state of each interface. Similarly, for IPv6, it is useful to have a stable IPv6 address identifying a TE node. The IPv6 TE Router ID TLV is defined in section 4.1. I assume that the intention of this text is not to change the definition of "TE Router ID" from a 32 bit value, but rather to introduce a new concept, the "IPv6 TE Router ID" that is 128 bits. Is this correct? If so, I assume that the principal uses for this value are: 1. To allow the identification of a router in the path of a TE tunnel using an IPv6 address. In particular to allow MPLS-TE LSPs to be signalled using a node address rather than interface addresses. 2. To allow the use of an IPv6 control plane distinct from the addressing scheme used in the data plane. In particular to allow signaling messages for GMPLS data switches to be routed to the appropriate protocol controllers using IPv6. It is worth noting that certain concepts, such as unnumbered links do not currently support the use of 128 bit identifiers for routers in the principle TE signaling protocol, RSVP-TE (see RFC3477). If the intention of the ISIS WG is to extend the use of TE Router ID into the context of RFC3477, then it would be worth raising this with the MPLS and CCAMP WGs. Cheers, Adrian PS. The TE Router ID TLV is a stable IPv4 address that is routable, regardless of the state of each interface. No it isn't. It *contains* an address. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From johnokelele@noavar.com Sat Jan 29 23:28:32 2005 Received: from noavar.com (www.noavar.com [81.29.193.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13179 for ; Sat, 29 Jan 2005 23:28:32 -0500 (EST) Received: from 195.234.250.84 by www.noavar.com (81.29.193.130); Sun, 30 Jan 2005 07:43:51 Message-ID: <471275592@www.noavar.com> From: "john okelele" X-Mailer: Noavar MIME-Version: 1.0 Subject: [no subject] Date: Sun, 30 Jan 2005 07:43:51 Content-Type: multipart/alternative; boundary="----IMB--73E75C22BB7E6A1" To view this message, you need a reader capable of working with MIME ------IMB--73E75C22BB7E6A1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 NSwgTWVyaWRpYW4gRWFzdApMZWljZXN0ZXIgTEUzIDJXWiAKTGVpY2VzdGVyIENpdHksIFVuaXRl ZCBLaW5nZG9tCkUtbWFpbDogY2FwdGFpbl9va2VsZWxlQHlhaG9vLmNvbQpva2VsZWxlMDNAbmV0 c2NhcGUubmV0CmNhcHRhaW5fb2tlbGVsZUBmcmVlem9uZS5jby51awpGUk9NOiBDQVBUIEpPSE4g T0tFTEVMRQoKSSBnb3QgeW91ciBjb250YWN0IGFkZHJlc3MgdGhyb3VnaCBpbnRlcm5ldCBicm93 c2luZwppbiBteSBzZWFyY2ggZm9yIGEgcmVsaWFibGUgYW5kIHRydXN0d29ydGh5IHBlcnNvbiB3 aG8Kd2lsbCBhc3Npc3QgbWUgaW4gYSAgYnVzaW5lc3MgaW52ZXN0bWVudCB2ZW50dXJlIGluCnlv dXIgY291bnRyeSwgIEkgYW0gQ2FwdGFpbiBKT0hOIE9LRUxFIHRoZQpmb3JtZXIgQ29tbWFuZGVy IG9mIHRoZSBTZWN1cml0eSAgR3VhcmRzIG9mIHRoZSBsYXRlCkxhdXJlbnQgS2FiaWxhIChmb3Jt ZXIgUHJlc2lkZW50LCBEZW1vY3JhdGljIFJlcHVibGljCm9mIENvbmdvIChBZnJpY2EpLCBJIGFt IHByZXNlbnRseSBpbiBzZWxmLWV4aWxlIHdpdGggbXkKd2lmZSBhbmQgb25lIGNoaWxkIGluIHJl bW90ZSBMZWljZXN0ZXIgQ2l0eSBCcml0YWluLApkdWUgdG8gdGhyZWF0IG9mIHRoZSBwcmVzZW50 IEdvdmVybm1lbnQgaGVhZGVkIGJ5IHRoZQpzb24gb2YgTGF0ZSBMYXVyZW50IEthYmlsYSBhZnRl ciBteSBsaWZlIGFuZCBteSBmYW1pbHkKdG8ga2lsbCwgc2F5aW5nIHRoYXQgSSBrbm93IGFib3V0 IHRoZSBkZWF0aCBvZiBoaXMKZmF0aGVyLgogIApJIGFzc2lzdGVkIExhdGUgUHJlc2lkZW50IExh dXJlbnQgS2FiaWxhIHRvIGtlZXAKVVMgJDE5TShOaW5ldGVlbiBNaWxsaW9ucyBEb2xsYXIpIGlu IGEgU2VjdXJpdHkgY29tcGFueSBpbiAKRXVyb3BlIApkdXJpbmcgdGhlIFdhciBpbiBNeSBDb3Vu dHJ5LgpBbHRob3VnaCB0aGUgc2VjdXJpdHkgY29tcGFueSBkb2VzIG5vdCBrbm93IHRoZQpjb250 ZW50IGluIHRoZSBib3hlcyBkZXBvc2l0ZWQgYXMgd2UgZGVwb3NpdCBpdCBhcwpwZXJzb25hbCBl ZmZlY3RzIG9mIE1yLiBMYXVyZW50IEthYmlsYS4gSXQgaXMgaW4gdGhpcwpyZXNwZWN0IHRoYXQg SSAgc2VlayB5b3VyIGhlbHAgdG8gYXNzaXN0IG1lIGluIHRoZQppbnZlc3RtZW50IG9mIHRoZXNl IGZ1bmRzIGJlZm9yZSB0aGUgcHJlc2VudApHb3Zlcm5tZW50IGhlYWRlZCBieSB0aGUgc29uIHdp bGwgaGF2ZSBrbm93bGVkZ2Ugb2YKdGhpcyBtb25leSB0byBhdm9pZCBiZWluZyB0YWtlIGF3YXku CiAKT24gY29uY2x1c2lvbiBvZiB0aGlzIGJ1c2luZXNzLCBJIHNoYWxsIGNvbXBlbnNhdGUgeW91 CndpdGggNDUlb2YgdGhlIGZ1bmQsIHdoaWxlIDUlIGlzIG1hcHBlZCBvdXQgZm9yIGFueQpleHBl bnNlIHdlIHNob3VsZCBlbmNvdW50ZXIgZHVyaW5nIHRoZSBjYXVzZSBvZgp0cmFuc2FjdGlvbiwg YW5kIHRoZSByZW1haW5pbmcgYW1vdW50IHNob3VsZCBiZSB1c2VkCnRvIG9wZW4gIGFjY291bnQg Zm9yIG15IGZhbWlseSBmb3IgaW52ZXN0bWVudCBvdmVyCnRoZXJlIHdpdGggeW91ciBhc3Npc3Rh bmNlLgpJIG5lZWQgYSBwcm9maXRhYmxlIGxvbmcgdGVybSBpbnZlc3RtZW50IHBsYW4gd2l0aAp5 b3VyICBjb21wYW55IG9yIHlvdS4gWW91ciB0ZXJtcywgc3VnZ2VzdGlvbnMKYW5kIGlkZWEgYXJl IHJlcXVpcmVkIHVyZ2VudGx5LgpFeHBlY3RpbmcgeW91ciBwcm9tcHQgcmVzcG9uc2UuIEFsc28g ZnVybmlzaCBtZSB3aXRoCnlvdXIgY3VycmVudCBFLW1haWwgYWRkcmVzcyxUZWwvRmF4IE51bWJl cnMgKFByaXZhdGUpCmZvciBhIHBlcnNvbmFsICBjb250YWN0IHdpdGggeW91LgpZb3VycyBGYWl0 aGZ1bGx5LApDYXB0IEpPSE4gT0tFTEUuCkVtYWlsOmNhcHRhaW5fb2tlbGVsZUB5YWhvby5jby51 awpOYiwKUGxlYXNlIHJlc3BvbnNlIHRvIG15IHByaXZhdGUgZW1haWwgYWRkcmVzc2VzLApFbWFp bDpjYXB0YWluX29rZWxlbGVAeWFob28uY29tCm9rZWxlbGUwM0BuZXRzY2FwZS5uZXQKY2FwdGFp bl9va2VsZWxlQGZyZWV6b25lLmNvLnVrDQoNCg0KR2V0IFlvdXIgT3duIEZyZWUgUGVyc2lhbiBF LU1haWwgQWNjb3VudCBhdCBodHRwOi8vd3d3Lk5vYXZhci5jb20gIQ0KDQo= ------IMB--73E75C22BB7E6A1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
=35, Meridian East
Leicester LE=33 =32WZ
Leicester City, United Ki= ngdom
E=2dmail=3a captain=5fokelele=40yahoo.com
okelele=30=33=40net= scape.net
captain=5fokelele=40freezone.co.uk
FROM=3a CAPT JOHN OKEL= ELE

I got your contact address through internet browsing
in m= y search for a reliable and trustworthy person who
will assist me in a = business investment venture in
your country, I am Captain JOHN OKELE th= e
former Commander of the Security Guards of the late
Laurent Kabi= la =28former President, Democratic Republic
of Congo =28Africa=29, I am = presently in self=2dexile with my
wife and one child in remote Leicester= City Britain,
due to threat of the present Government headed by the
= son of Late Laurent Kabila after my life and my family
to kill, saying= that I know about the death of his
father.

I assisted Late= President Laurent Kabila to keep
US =24=31=39M=28Nineteen Millions Doll= ar=29 in a Security company in
Europe
during the War in My Countr= y.
Although the security company does not know the
content in the b= oxes deposited as we deposit it as
personal effects of Mr. Laurent Kabil= a. It is in this
respect that I seek your help to assist me in the
i= nvestment of these funds before the present
Government headed by the s= on will have knowledge of
this money to avoid being take away.
On conclusion of this business, I shall compensate you
with =34=35=25= of the fund, while =35=25 is mapped out for any
expense we should encoun= ter during the cause of
transaction, and the remaining amount should be = used
to open account for my family for investment over
there with = your assistance.
I need a profitable long term investment plan with
y= our company or you. Your terms, suggestions
and idea are required urg= ently.
Expecting your prompt response. Also furnish me with
your cu= rrent E=2dmail address,Tel=2fFax Numbers =28Private=29
for a personal c= ontact with you.
Yours Faithfully,
Capt JOHN OKELE.
Email=3aca= ptain=5fokelele=40yahoo.co.uk
Nb,
Please response to my private ema= il addresses,
Email=3acaptain=5fokelele=40yahoo.com
okelele=30=33=40= netscape.net
captain=5fokelele=40freezone.co.uk


Get= Your Own Free Persian E=2dMail Account at http=3a=2f=2fwww.Noavar.com =21
------IMB--73E75C22BB7E6A1-- From isis-wg-bounces@ietf.org Sun Jan 30 13:16:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21330 for ; Sun, 30 Jan 2005 13:16:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvJY8-0000f6-Se; Sun, 30 Jan 2005 13:11:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtNiq-0001nd-1o for isis-wg@megatron.ietf.org; Tue, 25 Jan 2005 05:14:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19377 for ; Tue, 25 Jan 2005 05:14:53 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtNzV-0002O4-BR for isis-wg@ietf.org; Tue, 25 Jan 2005 05:32:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Jan 2005 12:14:14 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A528E54368@wombat.seabridge.co.il> Thread-Topic: Wide Metric Thread-Index: AcUCxp9qBLr1ziTZTDSQukkM4Z0vYg== From: "Nurit Sprecher" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-Mailman-Approved-At: Sun, 30 Jan 2005 13:11:50 -0500 Cc: Nurit Sprecher Subject: [Isis-wg] Wide Metric 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: , Content-Type: multipart/mixed; boundary="===============1260569171==" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org This is a multi-part message in MIME format. --===============1260569171== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C502C6.9EEAF78A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C502C6.9EEAF78A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I wonder if the wide metric defined in the TE extension for the integrated IS-IS is widely supported in real networks. What about the IS-IS default metric? I guess the default metric is widely supported. Is that correct? Is the wide metric in use especially when leaking routes from L2 to L1? Or maybe there is there another case/use? Why is the wide metric combined with the TE extension? Is it supposed to be considered by the CSPF calculations? My understanding is that it used by the SPF calculations. Is that correct? Thanks in advance, Nurit. ------_=_NextPart_001_01C502C6.9EEAF78A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I wonder if the wide metric defined in the TE = extension for the integrated IS-IS is widely supported in real networks. What about the = IS-IS default metric? I guess the default metric is widely supported. Is that correct?

Is the wide metric in use especially when leaking = routes from L2 to L1? Or maybe there is there another = case/use?

Why is the wide metric combined with the TE = extension? Is it supposed to be considered by the CSPF calculations? My understanding is = that it used by the SPF calculations. Is that = correct?

Thanks in advance,

Nurit.

------_=_NextPart_001_01C502C6.9EEAF78A-- --===============1260569171== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg --===============1260569171==-- From isis-wg-bounces@ietf.org Mon Jan 31 00:06:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03744 for ; Mon, 31 Jan 2005 00:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvTiX-0004sg-33; Mon, 31 Jan 2005 00:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvThj-0004mz-I9 for isis-wg@megatron.ietf.org; Mon, 31 Jan 2005 00:02:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03539 for ; Mon, 31 Jan 2005 00:02:24 -0500 (EST) Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvTzb-0001Dw-4Y for isis-wg@ietf.org; Mon, 31 Jan 2005 00:20:56 -0500 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id j0V51oi25761; Sun, 30 Jan 2005 21:01:52 -0800 (PST) Date: Sun, 30 Jan 2005 21:01:50 -0800 (PST) From: Shankar Vemulapalli To: Nurit Sprecher Subject: Re: [Isis-wg] Wide Metric In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A528E54368@wombat.seabridge.co.il> Message-ID: References: <6FAB860EC6AE3C4EB327204DEC33A528E54368@wombat.seabridge.co.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Nurit - At 12:14pm 01/25/05 +0200, Nurit Sprecher wrote: > Hi all, > > I wonder if the wide metric defined in the TE extension for the > integrated IS-IS is widely supported in real networks. What about the > IS-IS default metric? I guess the default metric is widely supported. Is > that correct? Wide-metric is embraced by more & more customers. It gives them the flexibility which is not there with the narrow (default) metric. ( for ex.: suuport of TE, increasing the range of is-is metric & also improving the encoding of IP prefixes) > Is the wide metric in use especially when leaking routes from L2 to L1? > Or maybe there is there another case/use? is also used in carrying the TE extensions. > Why is the wide metric combined with the TE extension? Is it supposed to > be considered by the CSPF calculations? My understanding is that it used > by the SPF calculations. Is that correct? Take a look at RFC3784 - which should help answer your questions. Thanks, /Shankar > Thanks in advance, > > Nurit. > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Jan 31 00:59:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06970 for ; Mon, 31 Jan 2005 00:59:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvUYq-0004S8-1L; Mon, 31 Jan 2005 00:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvUXy-0004LI-9H for isis-wg@megatron.ietf.org; Mon, 31 Jan 2005 00:56:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06685 for ; Mon, 31 Jan 2005 00:56:21 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvUpm-00029P-46 for isis-wg@ietf.org; Mon, 31 Jan 2005 01:14:54 -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 <0IB600I7K2XWEQ@szxga02-in.huawei.com> for isis-wg@ietf.org; Mon, 31 Jan 2005 13:51:32 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB6002JU2XW9B@szxga02-in.huawei.com> for isis-wg@ietf.org; Mon, 31 Jan 2005 13:51:32 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB600DV2329EW@szxml01-in.huawei.com>; Mon, 31 Jan 2005 13:54:10 +0800 (CST) Date: Mon, 31 Jan 2005 11:19:45 +0530 From: hemanthbs Subject: RE: [Isis-wg] Wide Metric In-reply-to: To: "'Nurit Sprecher'" Message-id: <000e01c50758$ab982ac0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7BIT Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@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 Content-Transfer-Encoding: 7BIT Hi Nurit, Another important role of wide metric is in policy based routing. For eg: AdminTag feature requires wide metrics. Bye. Hemanth. S.Hemanth Balaji. Software Engineer. Huawei Technologies India Pvt Ltd. Bangalore, India. -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] On Behalf Of Shankar Vemulapalli Sent: Monday, January 31, 2005 10:32 AM To: Nurit Sprecher Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric Hi Nurit - At 12:14pm 01/25/05 +0200, Nurit Sprecher wrote: > Hi all, > > I wonder if the wide metric defined in the TE extension for the > integrated IS-IS is widely supported in real networks. What about the > IS-IS default metric? I guess the default metric is widely supported. Is > that correct? Wide-metric is embraced by more & more customers. It gives them the flexibility which is not there with the narrow (default) metric. ( for ex.: suuport of TE, increasing the range of is-is metric & also improving the encoding of IP prefixes) > Is the wide metric in use especially when leaking routes from L2 to L1? > Or maybe there is there another case/use? is also used in carrying the TE extensions. > Why is the wide metric combined with the TE extension? Is it supposed to > be considered by the CSPF calculations? My understanding is that it used > by the SPF calculations. Is that correct? Take a look at RFC3784 - which should help answer your questions. Thanks, /Shankar > Thanks in advance, > > Nurit. > > _______________________________________________ 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 Mon Jan 31 08:42:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00580 for ; Mon, 31 Jan 2005 08:42:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbgS-0002uJ-Nu; Mon, 31 Jan 2005 08:33:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvbbu-00028q-DI for isis-wg@megatron.ietf.org; Mon, 31 Jan 2005 08:28:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29093 for ; Mon, 31 Jan 2005 08:28:56 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvbtd-0003Hi-E2 for isis-wg@ietf.org; Mon, 31 Jan 2005 08:47:30 -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 <0IB6007ZTNZB0O@szxga02-in.huawei.com> for isis-wg@ietf.org; Mon, 31 Jan 2005 21:25:59 +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 <0IB6007QSNZBEU@szxga02-in.huawei.com> for isis-wg@ietf.org; Mon, 31 Jan 2005 21:25:59 +0800 (CST) Received: from hemanthbs ([10.18.4.114]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB6001FENZ869@szxml02-in.huawei.com>; Mon, 31 Jan 2005 21:25:57 +0800 (CST) Date: Mon, 31 Jan 2005 18:54:10 +0530 From: hemanthbs Subject: RE: [Isis-wg] Wide Metric In-reply-to: <6FAB860EC6AE3C4EB327204DEC33A5280109141E@wombat.seabridge.co.il> To: "'Nurit Sprecher'" Message-id: <000001c50798$271729a0$7204120a@in.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.4024 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: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7BIT Cc: isis-wg@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hemanthbs@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 Content-Transfer-Encoding: 7BIT Hi Nurit, Hi Shankar and Hemanth, Thank you for your response. I understand the benefits of using the Wide metric. My doubt was why it is combined together with TE. The main urge for development of wide metrics was TE. Though we had the problems of smaller metric range. If for example I would like to use the Wide metric over a non-TE network, then I have to use the 'Extended IS Reachability' TLV, without the TE sub-TLVs. For any implementation, wide metrics and TE can be independent. Not necessarily combined. For eg: if enable only wide metrics, then we need not Generate the TE sub-tlvs.We generate only the extended reachability tlvs. However, if TE is enabled(for which wide metrics is a pre-requiste) then We generate the TE sub-tlvs along with the extended reachability tlvs. In addition, it is written in the RFC that "If a link is advertised without this sub-TLV, traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV". This mandatory requirement does not allow advertising a non-TE link. If for example, an IS supports TE on some links but non-TE only on other links, this mandatory requirement causes that even the Non-TE links will be considered in the CSPF calculation. For a TE only link we have a support in the RFC, using the maximum value in the default metric field. However, we cannot support a non-TE only link, because the default metric appear in the sub-TLV will be considered for the CSPF calculations. The above concern may be answered as below, I guess. In an implementation where in the TE links are considered based on the following condition. "TE should be enabled for the ISIS process and MPLS TE should be enabled on the interface" i.e for TE computation only those links be will be considered, for which MPLS TE is enabled on the interface and TE is enabled for that ISIS process running on that interface. I hope I answered your question. Hemanth. I'll appreciate your response. Thanks and best regards, Nurit. -----Original Message----- From: Shankar Vemulapalli [mailto:svemulap@cisco.com] Sent: Monday, January 31, 2005 7:02 AM To: Nurit Sprecher Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric Hi Nurit - At 12:14pm 01/25/05 +0200, Nurit Sprecher wrote: > Hi all, > > I wonder if the wide metric defined in the TE extension for the > integrated IS-IS is widely supported in real networks. What about the > IS-IS default metric? I guess the default metric is widely supported. Is > that correct? Wide-metric is embraced by more & more customers. It gives them the flexibility which is not there with the narrow (default) metric. ( for ex.: suuport of TE, increasing the range of is-is metric & also improving the encoding of IP prefixes) > Is the wide metric in use especially when leaking routes from L2 to L1? > Or maybe there is there another case/use? is also used in carrying the TE extensions. > Why is the wide metric combined with the TE extension? Is it supposed to > be considered by the CSPF calculations? My understanding is that it used > by the SPF calculations. Is that correct? Take a look at RFC3784 - which should help answer your questions. Thanks, /Shankar > Thanks in advance, > > Nurit. > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Jan 31 12:19:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25529 for ; Mon, 31 Jan 2005 12:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvf6H-0004cv-Lu; Mon, 31 Jan 2005 12:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvZ5L-0008Bx-CT for isis-wg@megatron.ietf.org; Mon, 31 Jan 2005 05:47:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12651 for ; Mon, 31 Jan 2005 05:47:05 -0500 (EST) Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvZNA-0007u6-NP for isis-wg@ietf.org; Mon, 31 Jan 2005 06:05:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Wide Metric Date: Mon, 31 Jan 2005 12:46:12 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A5280109141E@wombat.seabridge.co.il> Thread-Topic: [Isis-wg] Wide Metric Thread-Index: AcUHUfMM5Ocuy5wfQTGx1je+0fORbQALnRLg From: "Nurit Sprecher" To: "Shankar Vemulapalli" , "hemanthbs" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 31 Jan 2005 12:12:32 -0500 Cc: isis-wg@ietf.org, Nurit Sprecher 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 Content-Transfer-Encoding: quoted-printable Hi Shankar and Hemanth, Thank you for your response. I understand the benefits of using the Wide metric. My doubt was why it is combined together with TE. If for example I would like to use the Wide metric over a non-TE network, then I have to use the 'Extended IS Reachability' TLV, without the TE sub-TLVs.=20 In addition, it is written in the RFC that "If a link is advertised without this sub-TLV, traffic engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV". This mandatory requirement does not allow advertising a non-TE link. If for example, an IS supports TE on some links but non-TE only on other links, this mandatory requirement causes that even the Non-TE links will be considered in the CSPF calculation. For a TE only link we have a support in the RFC, using the maximum value in the default metric field. However, we cannot support a non-TE only link, because the default metric appear in the sub-TLV will be considered for the CSPF calculations. I'll appreciate your response. Thanks and best regards, Nurit. -----Original Message----- From: Shankar Vemulapalli [mailto:svemulap@cisco.com]=20 Sent: Monday, January 31, 2005 7:02 AM To: Nurit Sprecher Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Wide Metric Hi Nurit - At 12:14pm 01/25/05 +0200, Nurit Sprecher wrote: > Hi all, > > I wonder if the wide metric defined in the TE extension for the > integrated IS-IS is widely supported in real networks. What about the > IS-IS default metric? I guess the default metric is widely supported. Is > that correct? Wide-metric is embraced by more & more customers. It gives them the flexibility which is not there with the narrow (default) metric. ( for ex.: suuport of TE, increasing the range of is-is metric & also improving the encoding of IP prefixes) > Is the wide metric in use especially when leaking routes from L2 to L1? > Or maybe there is there another case/use? is also used in carrying the TE extensions. > Why is the wide metric combined with the TE extension? Is it supposed to > be considered by the CSPF calculations? My understanding is that it used > by the SPF calculations. Is that correct? Take a look at RFC3784 - which should help answer your questions. Thanks, /Shankar > Thanks in advance, > > Nurit. > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-bounces@ietf.org Mon Jan 31 13:00:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00545 for ; Mon, 31 Jan 2005 13:00:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfdP-0003Cx-3E; Mon, 31 Jan 2005 12:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfUc-0001tC-7d for isis-wg@megatron.ietf.org; Mon, 31 Jan 2005 12:37:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27310 for ; Mon, 31 Jan 2005 12:37:39 -0500 (EST) Received: from smtp2.dataconnection.com ([192.91.191.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvfmb-0001BX-Lr for isis-wg@ietf.org; Mon, 31 Jan 2005 12:56:18 -0500 Received: from enfismtp2.datcon.co.uk ([172.19.16.2]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Jan 2005 17:37:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isis-wg] TE Router ID in draft-ietf-isis-ipv6-te-00.txt Date: Mon, 31 Jan 2005 17:37:07 -0000 Message-ID: <37701240971DD31193970000F6CCB9F7069BC6E1@duke.datcon.co.uk> Thread-Topic: [Isis-wg] TE Router ID in draft-ietf-isis-ipv6-te-00.txt Thread-Index: AcUFS1nUl6AX39nyTlegERwtBboZsQCUe2HA From: "Jonathan Harrison" To: "Adrian Farrel" , X-OriginalArrivalTime: 31 Jan 2005 17:37:09.0716 (UTC) FILETIME=[7D959140:01C507BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable 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 Content-Transfer-Encoding: quoted-printable Adrian, You are correct. The IPv6 TE Router ID is not intended to change the = definition of the TE Router ID, and may be used as per your description. = =20 This definition of the IPv6 TE Router ID does not necessarily require an = extension of RFC 3477. However, I believe that in an IPv6 only network = it would be useful to allow the identification of an unnumbered link = using an IPv6 TE router ID together with an interface ID. This is = something we are planning to bring up with the MPLS/CCAMP WGs. =20 Thanks for the comments, Jon (P.S. Thanks also for pointing out the "is"/"contains" bug - I'll fix = that in the next revision.)=20 -----Original Message----- From: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org]On Behalf Of Adrian Farrel Posted At: 28 January 2005 12:39 Posted To: ISIS WG Conversation: [Isis-wg] TE Router ID in draft-ietf-isis-ipv6-te-00.txt Subject: [Isis-wg] TE Router ID in draft-ietf-isis-ipv6-te-00.txt Hi, It has been brought to my attention that this draft includes some ambiguous text... 3.2.1 TE Router ID TLV The TE Router ID TLV is a stable IPv4 address that is routable, regardless of the state of each interface. Similarly, for IPv6, it is useful to have a stable IPv6 address identifying a TE node. The IPv6 TE Router ID TLV is defined in section 4.1. I assume that the intention of this text is not to change the definition of "TE Router ID" from a 32 bit value, but rather to introduce a new concept, the "IPv6 TE Router ID" that is 128 bits. Is this correct? If so, I assume that the principal uses for this value are: 1. To allow the identification of a router in the path of a TE tunnel using an IPv6 address. In particular to allow MPLS-TE LSPs to be = signalled using a node address rather than interface addresses. 2. To allow the use of an IPv6 control plane distinct from the = addressing scheme used in the data plane. In particular to allow signaling messages for GMPLS data switches to be routed to the appropriate protocol controllers using IPv6. It is worth noting that certain concepts, such as unnumbered links do = not currently support the use of 128 bit identifiers for routers in the principle TE signaling protocol, RSVP-TE (see RFC3477). If the intention of the ISIS WG is to extend the use of TE Router ID = into the context of RFC3477, then it would be worth raising this with the = MPLS and CCAMP WGs. Cheers, Adrian PS. The TE Router ID TLV is a stable IPv4 address that is routable, regardless of the state of each interface. No it isn't. It *contains* an address. _______________________________________________ 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 Mon Jan 31 17:24:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12557 for ; Mon, 31 Jan 2005 17:24:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjIb-0002R0-Fp; Mon, 31 Jan 2005 16:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CviY1-0007d9-DZ for isis-wg@megatron.ietf.org; Mon, 31 Jan 2005 15:53:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19555 for ; Mon, 31 Jan 2005 15:53:23 -0500 (EST) Received: from door.sniff.de ([82.212.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cviq1-000689-Au for isis-wg@ietf.org; Mon, 31 Jan 2005 16:12:02 -0500 Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id DF04C2AA0F; Mon, 31 Jan 2005 20:53:15 +0000 (GMT) In-Reply-To: <000001c50798$271729a0$7204120a@in.huawei.com> References: <000001c50798$271729a0$7204120a@in.huawei.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0BF32C4D-73CA-11D9-9301-0003934A79C2@sniff.de> Content-Transfer-Encoding: 7bit From: Marc Binderberger Subject: Re: [Isis-wg] Wide Metric Date: Mon, 31 Jan 2005 21:52:40 +0100 To: hemanthbs@huawei.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: isis-wg@ietf.org, "'Nurit Sprecher'" 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 Content-Transfer-Encoding: 7bit Hello, >> My doubt was why it is combined together with TE. > The main urge for development of wide metrics was TE. Though we had the > problems of smaller metric range. Maybe Nurit is asking why the TE extensions have been "integrated" into extended IS reachability TLV type 22 instead of using a separate TLV. Nurit? (in this case: at the beginning of RFC3784 the authors are counting octets, so I assume they tried to avoid the additional 7 octets for system Id and pseudonode number in a separate TLV. Beside that integrating it seems logical, all new per-link information are in one place/TLV) >> [...] This mandatory requirement does not >> allow advertising a non-TE link. If for example, an IS supports TE on >> some links but non-TE only on other links, this mandatory requirement >> causes that even the Non-TE links will be considered in the CSPF >> calculation. [...] > > The above concern may be answered as below, I guess. > In an implementation where in the TE links are considered based on the > following condition. "TE should be enabled for the ISIS process and > MPLS > TE should be enabled on the interface" > i.e for TE computation only those links be will be considered, for > which MPLS TE is enabled on the interface and TE is enabled for that > ISIS process running on that interface. Hemanth, but how does a distance router _know_ what interfaces are enabled if not IS-IS is signaling this? How does the IS-IS process running on A know that B's interface to C allows TE while the interface to D doesn't ? A--(te)--B--(te)--C | | | (te) | | D--------E (please switch on your fixed font ;-) Or is there the implicit condition that all routers must be "TE-aware" and you simply put a very high TE metric on the links you don't want? Or trial & error? (wasn't it named "cut back"? The RSVP will tell finally that a link is not TE/RSVP enabled). What am I missing? :-) Regards, Marc -- Marc Binderberger _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg