From isis-wg-admin@external.juniper.net Thu Jun 1 00:16:28 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03951 for ; Thu, 1 Jun 2000 00:16:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA16703; Wed, 31 May 2000 21:21:58 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA16672 for ; Wed, 31 May 2000 21:21:56 -0700 (PDT) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by ertpg14e1.nortelnetworks.com; Wed, 31 May 2000 23:50:16 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LXBNT5TW; Wed, 31 May 2000 20:50:11 -0700 Received: from nortelnetworks.com (CC775382-A [132.245.139.162]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS52HNCA; Wed, 31 May 2000 23:50:09 -0400 Message-ID: <3935DD51.1FCD794A@nortelnetworks.com> Date: Wed, 31 May 2000 23:49:38 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rajesh Saluja" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-AtHome0402 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Les Ginsberg CC: "Rajesh Saluja" , Micah Bartell , Jeff Parker , Jeff Learman , rhan@ibnets.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] question on MTU References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Les Ginsberg wrote: > > (At the risk of belaboring a point...) > > dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of > sending a padded IIH which is the maximum of the bunch is precisely to > detect those misconfigurations where this is not the case. So if > dataLinkBlockSize is NOT large enough, the adjacency presumably will never > come up. Therefore stating that > > "So IMHO IIH size is nothing but dataLinkBlocksize - 1." > > is denying the possibility of a misconfiguration. Yes, I should say that if you impose the requirement ( dataLinkBlocksize >= Buffersize ), then IIH size = dataLinkBlocksize - 1. The reason why it is not possible to enforce this requirement in explained in ISO 10589 section 8.2.3c. But I was wondering if this mechanism on P2P link could result in one way adjacency if you do not implement three way handshake mechanism. Consider IS A and IS B connected by P2P link. Suppose P2P link MTU size = X A - Buffersize = Y B - Buffersize = Z ( misconfiguration ) where Y < X < Z A will send padded Hello with size max(X,Y) i.e. X - 1. When B receives, it is going to accept this packet. Right? ( I do not see any check on the padded hello size at the receive end ). So B will make adjacency A UP ( if you do not implement three way handshake ) B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be delivered becuase DataLinkBlockSize is less. A will never receive Hello packet from B. So you end up with one-way adjacency. ( an example of link failing in one direction ? ) Please correct me if I am missing anything. Thanks, Rajesh _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Jun 1 10:22:25 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24119 for ; Thu, 1 Jun 2000 10:22:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA17432; Thu, 1 Jun 2000 07:25:36 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA17401 for ; Thu, 1 Jun 2000 07:25:34 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e51ECpZ18320; Thu, 1 Jun 2000 10:12:52 -0400 (EDT) Message-Id: <3.0.1.32.20000601101005.012f24e0@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 01 Jun 2000 10:10:05 -0400 To: "Rajesh Saluja" From: Jeff Learman Subject: Re: [Isis-wg] question on MTU Cc: Les Ginsberg , "Rajesh Saluja" , Micah Bartell , Jeff Parker , rhan@ibnets.com, isis-wg@external.juniper.net In-Reply-To: <3935DD51.1FCD794A@nortelnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Rajesh, You are correct -- you can get a persistent one-way adjacency. At the risk of sounding like a broken record, let me note that this wouldn't happen when operating IS-IS as it was designed to operate, over reliable p2p links. Fortunately, thanks to the "robustness check" for two-way connectivity, this isn't a problem unless there are multiple links between systems. In this case, if you were so unlucky as to have the same problem in different directions on two links, you would have a black hole. Of course, the 3-way handshake solves the problem. Thanks to Les, Jeff, and Dave for detecting my mistake about a 4K link not causing the "inconsistent LSP buffer size" problem. I also agree with Micah Bartell -- the IIH should be AT LEAST maxsize - 1. It's better to make it maxsize unless you simply can't because of the size of your IIH ending at maxsize - 1. (That's assuming you think the check is worthwhile at all.) Concerning what Dave Katz says about the unfortunate choice of SONET using a 512-byte MTU size, I completely agree that this was a particularly bad choice by Bellcore. Actually, this is not a media limitation, simply a poor choice of the default for a LAPD parameter. However, the IS-IS spec does not prohibit the use of smaller MTU sizes; it is certainly possible to use a consistently small LSP buffer size in a subdomain. IS-IS is flawed in that it does not properly address what should be done when the LSP buffer size is inconsistent. The good news is that, as Dave and Les point out, it isn't a problem unless you use an MTU size smaller than 1492. And Rajesh is correct that a link-by-link check is not sufficient to guarantee the end-to-end requirement for passing LSPs. The fact that maxsize is limited by LSP buffer size indicates that it's a check for passing LSPs and not a true MTU size check (which is better to do using LCP's MRU configuration option, and has nothing to do with routes anyway). This means that the IIH padding doesn't really serve any purpose, as Dave points out. I still agree with Les and Jeff that, if you're going to send padded IIHs, it's best to continue doing it until the adjacency goes into the UP state. But sending padded IIHs could be made optional if the MTU size is negotiated. And I take back my suggestion about checking the size on received IIHs! Bad idea! Regards, Jeff At 11:49 PM 5/31/00 -0400, Rajesh Saluja wrote: > > >Les Ginsberg wrote: >> >> (At the risk of belaboring a point...) >> >> dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of >> sending a padded IIH which is the maximum of the bunch is precisely to >> detect those misconfigurations where this is not the case. So if >> dataLinkBlockSize is NOT large enough, the adjacency presumably will never >> come up. Therefore stating that >> >> "So IMHO IIH size is nothing but dataLinkBlocksize - 1." >> >> is denying the possibility of a misconfiguration. > >Yes, I should say that if you impose the requirement ( dataLinkBlocksize >>= Buffersize ), then IIH size = dataLinkBlocksize - 1. >The reason why it is not possible to enforce this requirement in >explained in ISO 10589 section 8.2.3c. > >But I was wondering if this mechanism on P2P link could result in one >way adjacency if you do not implement three way handshake mechanism. > >Consider IS A and IS B connected by P2P link. >Suppose P2P link MTU size = X >A - Buffersize = Y >B - Buffersize = Z ( misconfiguration ) >where Y < X < Z > >A will send padded Hello with size max(X,Y) i.e. X - 1. >When B receives, it is going to accept this packet. Right? ( I do not >see any check on the padded hello size at the receive end ). >So B will make adjacency A UP ( if you do not implement three way >handshake ) > >B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be >delivered becuase DataLinkBlockSize is less. A will never receive Hello >packet from B. >So you end up with one-way adjacency. ( an example of link failing in >one direction ? ) > >Please correct me if I am missing anything. > >Thanks, >Rajesh > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Jun 1 22:39:10 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10809 for ; Thu, 1 Jun 2000 22:39:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA18107; Thu, 1 Jun 2000 19:46:18 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA18081 for ; Thu, 1 Jun 2000 19:46:13 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 02 Jun 2000 08:16:58 +0530 Received: from saver.future ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id HAA02190 for ; Fri, 2 Jun 2000 07:55:11 +0530 Received: by localhost with Microsoft MAPI; Fri, 2 Jun 2000 08:00:33 +0530 Message-Id: <01BFCC68.A0F159A0.selvarajr@future.futsoft.com> From: SelvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'ISIS-WG'" Date: Fri, 2 Jun 2000 08:00:32 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFCC68.A123B440" Subject: [Isis-wg] Doubt regarding LSP IP Address TLV Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01BFCC68.A123B440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit LSP includes one or more IP Addresses of the interfaces. (for encapsulation or transmission of n/w Mgmt pkts). I suppose it need not include all the IP addresses of the interfaces. How these IP Address(s) chosen? What may be selection criteria ? SELVA ------ =_NextPart_000_01BFCC68.A123B440 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiICAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAqAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAbgAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUf kqBkiAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAASVNJUy1XRwBTTVRQAGlzaXMtd2dAZXh0ZXJu YWwuanVuaXBlci5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAHQAAAGlzaXMtd2dA ZXh0ZXJuYWwuanVuaXBlci5uZXQAAAAAAwAVDAEAAAADAP4PBgAAAB4AATABAAAACgAAACdJU0lT LVdHJwAAAAIBCzABAAAAIgAAAFNNVFA6SVNJUy1XR0BFWFRFUk5BTC5KVU5JUEVSLk5FVAAAAAMA ADkAAAAACwBAOgEAAAAeAPZfAQAAAAgAAABJU0lTLVdHAAIB918BAAAALAAAAL8AAAC1O8LALHcQ GqG8CAArKlbCFQAAABPeZmteYdMRqFgAIDUfkqBkiAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAA BAAAAAAAAALsVAEEgAEAJAAAAERvdWJ0IHJlZ2FyZGluZyBMU1AgSVAgQWRkcmVzcyBUTFYgALUL AQWAAwAOAAAA0AcGAAIACAAAACAABQAMAQEggAMADgAAANAHBgACAAcANwA3AAUAWQEBCYABACEA AABERThCMjJFNzVBMzhENDExQTg1ODAwMjAzNTFGOTJBMAABBwEDkAYAsAQAACAAAAALAAIAAQAA AAsAIwAAAAAAAwAmAAAAAAALACkAAAAAAAMANgAAAAAAQAA5AGCLZoY6zL8BHgBwAAEAAAAkAAAA RG91YnQgcmVnYXJkaW5nIExTUCBJUCBBZGRyZXNzIFRMViAAAgFxAAEAAAAWAAAAAb/MOoZV5yKL 4zhaEdSoWAAgNR+SoAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAAB0AAABzZWx2YXJhanJA ZnV0dXJlLmZ1dHNvZnQuY29tAAAAAAMABhDMh61rAwAHEM4AAAAeAAgQAQAAAGUAAABMU1BJTkNM VURFU09ORU9STU9SRUlQQUREUkVTU0VTT0ZUSEVJTlRFUkZBQ0VTKEZPUkVOQ0FQU1VMQVRJT05P UlRSQU5TTUlTU0lPTk9GTi9XTUdNVFBLVFMpSVNVUFBPU0VJAAAAAAIBCRABAAAAhwEAAIMBAABJ AgAATFpGdSlvLukDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM50B9yACpAPjAgBjaArA4HNldDAgBxMC gwBQ8RB2cHJxDlAQ7wHxEvFDA2MTCUJvb2sDgk+EbGQGAHR5bGUCg8YzAuMTCVRhaANxAoDyfQqB dWMAUAsDC7YKsTMKhAswbGkBwRIBIEzoU1AgC4BjCkABAAQgPQIgZRvABcAEYAlwIElxGyBBZGQJ cAQQG6JmWCB0aBvwC4B0BJBm4wDQB5AuICgCEAXACfAgY2Fwc3ULYHRp0wIgHAJ0cgBxbQQBH4MS Zhm0bi8H4E1nbUEFQHBrdHMpHnBJ4iAfMHBwbxEwGzAFQLcb4AmAIwBvBUAbRSAHQPcDIB2SHJFh HN8d6Bm4GfbiZhqCIEhvB+AdkSKxNRyYKCIAIBMgIqFuPxwgVxMwBUAAwHkgYvcb8BEwFnBjH3MF AR3xBzD8ID8ZuicKGasAoBRABgBwRUxWQQxAAtEW4XNcMTYszRl4GHEAMYAAAwAQEAAAAAADABEQ AAAAAAMAgBD/////QAAHMMCnK+E5zL8BQAAIMMCnK+E5zL8BCwAAgAggBgAAAAAAwAAAAAAAAEYA AAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAA AAAAAABGAAAAAFKFAADzFQAAAwAHgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAAeAAiACCAG AAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAA4LjA0AAAAAAsACYAIIAYAAAAAAMAAAAAAAABG AAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAAuACCAGAAAAAADA AAAAAAAARgAAAAAYhQAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAA AAAeAA2ACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAOgAggBgAAAAAAwAAA AAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAB4APQABAAAAAQAAAAAAAAADAA00/TcAAGrs ------ =_NextPart_000_01BFCC68.A123B440-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 5 02:00:23 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20211 for ; Mon, 5 Jun 2000 02:00:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA24470; Sun, 4 Jun 2000 23:07:43 -0700 (PDT) Received: from scotch.djinesys.com ([198.108.6.130]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA24444 for ; Sun, 4 Jun 2000 23:07:41 -0700 (PDT) Received: by scotch.djinesys.com (Postfix, from userid 9140) id E562310692; Mon, 5 Jun 2000 01:56:50 -0400 (EDT) Date: Mon, 5 Jun 2000 01:56:50 -0400 From: "Christian E. Hopps" To: isis-wg@external.juniper.net Message-ID: <20000605015650.E23948@djinesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Subject: [Isis-wg] attached bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I was looking at ``Technical Corrigendum 1'' to 10589.. and I noticed that it changes when an IS should consider itself attached. It adds the condition that if the IS has at least one active reachable address prefix it should consider itself attached. What is the intention of the change to 10589? My initial thought is since the reachability won't be advertised into level 1 the level 1-2 router sets ATT to attract traffic to itself. I suspect I may be missing something though since this change would seem to blackhole things. In any case what is the analogous situation in IP? Would it be: if the IS is announcing any external IP reachability. ? If so thats easy enough but things get more interesting in light of the domain wide draft. For example, domainwide mentions how people have allowed external reachability to be announced into level 1, in which case I think that you would not set the ATT bit. Also, if you are leaking level 2 reachability into level 1 there too I don't think setting ATT would be appropriate. I would appreciate any clarification people can offer. Thanks, Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 5 10:36:25 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03369 for ; Mon, 5 Jun 2000 10:36:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA25042; Mon, 5 Jun 2000 06:43:40 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA25011 for ; Mon, 5 Jun 2000 06:43:39 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id GAA20684; Mon, 5 Jun 2000 06:32:43 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id PAA05628; Mon, 5 Jun 2000 15:34:05 +0200 Message-Id: <200006051334.PAA05628@kraak.procket.com> Subject: Re: [Isis-wg] attached bit To: chopps@djinesys.com (Christian E. Hopps) Date: Mon, 5 Jun 2000 15:34:05 +0200 (MEST) Cc: isis-wg@external.juniper.net In-Reply-To: <20000605015650.E23948@djinesys.com> from "Christian E. Hopps" at Jun 05, 2000 01:56:50 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi Chris, > I was looking at ``Technical Corrigendum 1'' to 10589.. and I noticed > that it changes when an IS should consider itself attached. > > It adds the condition that if the IS has at least one active > reachable address prefix it should consider itself attached. > > What is the intention of the change to 10589? My initial thought > is since the reachability won't be advertised into level 1 > the level 1-2 router sets ATT to attract traffic to itself. As usual, attracting traffic is the reason to set the ATT bit. > I suspect I may be missing something though since this change > would seem to blackhole things. The paragraph in the corrigendum seems to explain it. The old rule was: set ATT if you see other areas in your domain. The problem is, what do you do if your area is the only area in your domain ? If there is only one area in the domain, the routers in that area will never see other areas, and thus were never allowed to set the ATT bit. If your domain is connected to other domains, at least one L1L2 router should forward traffic from L1-only routers to the other domain. With the old spec that wouldn't happen, because the L1L2 router wasn't allowed to set the ATT bit. The corrigendum adds explanation that a L1L2 router is allowed to set ATT if it sees either: 1) other areas in its own domain, or 2) sees other domains. > In any case what is the analogous situation in IP? > Would it be: > > if the IS is announcing any external IP reachability. > > ? I think the rule is the same: set ATT if you are connected to either 1) other areas, or 2) other domains. How to determine if you are connected to another area or domain is kinda implementation specific, I am afraid. Esp for IP, as IP addressing is not strictly hierarchical. > If so thats easy enough but things get more interesting in light of > the domain wide draft. For example, domainwide mentions how people > have allowed external reachability to be announced into level 1, > in which case I think that you would not set the ATT bit. Agreed. If you leak specific prefixes into L1, you attact traffic for for those destinations. IMHO there is no need to also set the ATT bit. Unless you leak only a few external prefixes, and don't leak all external prefixes. > Also, if > you are leaking level 2 reachability into level 1 there too I don't > think setting ATT would be appropriate. Agreed again. > I would appreciate any clarification people can offer. I think a L1L2 router should set the ATT bit if it can forward traffic to destinations outside of the L1 area, and those destinations are not explicitely known by L1-only routers. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 5 16:22:06 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09821 for ; Mon, 5 Jun 2000 16:22:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25416; Mon, 5 Jun 2000 13:29:33 -0700 (PDT) Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA25389 for ; Mon, 5 Jun 2000 13:29:31 -0700 (PDT) Received: from [129.250.38.56] (helo=dfw-mx2.email.verio.net) by dfw-smtpout4.email.verio.net with esmtp (Exim 3.12 #7) id 12z3KW-0004Rc-00; Mon, 05 Jun 2000 20:18:36 +0000 Received: from [206.176.136.115] (helo=cwk) by dfw-mx2.email.verio.net with smtp (Exim 3.12 #7) id 12z3KV-0000ai-00; Mon, 05 Jun 2000 20:18:35 +0000 From: "Carl W. Kalbfleisch" To: "Tony Przygienda" , Subject: RE: [Isis-wg] Agenda for Pittsburgh ... Date: Mon, 5 Jun 2000 15:23:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200005310403.GAA03050@net4u.net4u.ch> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Will there be any discussion of the MIB for ISIS? Carl > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Tony Przygienda > Sent: Tuesday, May 30, 2000 11:03 PM > To: isis-wg@external.juniper.net > Subject: [Isis-wg] Agenda for Pittsburgh ... > > > it's time to start to gather the agenda (beside the last calls > and new draft versions) for Pittsburgh. Requests for slots pls > to me or Tony Li > > -- tony > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun Jun 11 11:55:45 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08019 for ; Sun, 11 Jun 2000 11:55:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA01254; Sun, 11 Jun 2000 09:01:03 -0700 (PDT) Received: from scotch.djinesys.com ([198.108.6.131]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA01184 for ; Sun, 11 Jun 2000 09:00:58 -0700 (PDT) Received: by scotch.djinesys.com (Postfix, from userid 9140) id 5645110698; Sun, 11 Jun 2000 11:51:03 -0400 (EDT) Date: Sun, 11 Jun 2000 11:51:03 -0400 From: "Christian E. Hopps" To: isis-wg@external.juniper.net Message-ID: <20000611115103.N23544@djinesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Subject: [Isis-wg] too many segments Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I'm curious what the standard way to deal with overflowing 255 LSP segments for an IS is. At first I was tempted to use the overload state, but this doesn't strike me as fitting well in its definition. (e.g., how do you report which LSP caused the overload when there is no LSP). Also overflowing 255 segments is a gross misconfiguration error which the overload state doesn't appear to be directly intended for (given that it waits some time and then switches back to normal). Its pretty easy to overflow the LSP by redistributing e.g., BGP into ISIS. Even if it doesn't overflow the IS LSPs itself you can then get into trouble at the level 1/level 2 boundary when summarization occurs. I'm curious what other implementations do in this situation. Thanks for any help, Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun Jun 11 13:27:49 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08491 for ; Sun, 11 Jun 2000 13:27:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA01401; Sun, 11 Jun 2000 10:34:35 -0700 (PDT) Received: from redd235.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA01371 for ; Sun, 11 Jun 2000 10:34:33 -0700 (PDT) Received: (from tli@localhost) by redd235.procket.com (8.9.3/8.9.3) id KAA02795; Sun, 11 Jun 2000 10:24:12 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14659.52028.745648.629678@redd235.procket.com> Date: Sun, 11 Jun 2000 10:24:12 -0700 (PDT) To: "Christian E. Hopps" Cc: isis-wg@external.juniper.net Subject: [Isis-wg] too many segments In-Reply-To: <20000611115103.N23544@djinesys.com> References: <20000611115103.N23544@djinesys.com> X-Mailer: VM 6.75 under Emacs 20.4.1 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit | I'm curious what the standard way to deal with overflowing 255 LSP | segments for an IS is. At first I was tempted to use the overload | state, but this doesn't strike me as fitting well in its definition. | (e.g., how do you report which LSP caused the overload when there | is no LSP). Also overflowing 255 segments is a gross misconfiguration | error which the overload state doesn't appear to be directly intended | for (given that it waits some time and then switches back to normal). | | Its pretty easy to overflow the LSP by redistributing e.g., BGP | into ISIS. Even if it doesn't overflow the IS LSPs itself you can | then get into trouble at the level 1/level 2 boundary when summarization | occurs. | | I'm curious what other implementations do in this situation. Chris, There is no "standard" way of dealing with this problem. The most commonly suggested local hack for dealing with this, if one intentionally wants to generate more segments, is to have the administrator manually allocate another system ID. You then establish a zero cost adjacency between your primary system ID and your secondary. We discussed this at length back when we were discussing more than 255 adjacencies, tho the driver there was the ability to have more pseudo-node numbers. The same mechanism gives you more space to play in as well... As to the accidental overflow, the simplest mechanism is: don't. ;-) Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun Jun 11 21:40:48 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10800 for ; Sun, 11 Jun 2000 21:40:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA01901; Sun, 11 Jun 2000 18:46:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA01870 for ; Sun, 11 Jun 2000 18:46:00 -0700 (PDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03992; Sun, 11 Jun 2000 19:35:54 -0600 (MDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA24074; Sun, 11 Jun 2000 21:35:54 -0400 (EDT) Received: from bcn (bcn [129.148.75.4]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id VAA19561; Sun, 11 Jun 2000 21:35:54 -0400 (EDT) Message-Id: <200006120135.VAA19561@bcn.East.Sun.COM> Date: Sun, 11 Jun 2000 21:35:54 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] too many segments To: chopps@djinesys.com, tli@Procket.com Cc: isis-wg@external.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /nP/pdbFPuyGBR3SD2uh9A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net The 1 byte fragment number is a field that in retrospect should have been larger. As Toni Li pointed out, it should be possible to get around it with the hack of pretending to be two (or more) nodes with zero cost between them, and have part of the information reported by each one. Do people actually do this? Do all implementations calculate correctly when they see this? Does the Dijkstra calculation do anything weird with 0-cost adjacencies? (It should work, but I wouldn't be surprised if some implementations got very confused.) Certainly it has nothing to do with overflow state if a router has more information to report than fits into 255 fragments. If this really is a big problem, it would probably be possible to change the size of the field, but it's tricky to do it in a way without flag days, or in a way that would work if someone accidentally plugs in a router that doesn't know about it. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 01:15:21 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15674 for ; Mon, 12 Jun 2000 01:15:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA02149; Sun, 11 Jun 2000 22:21:16 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA02121 for ; Sun, 11 Jun 2000 22:21:14 -0700 (PDT) Received: (from tli@localhost) by miata.procket.com (8.9.3/8.9.3) id WAA09321; Sun, 11 Jun 2000 22:11:14 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: miata.procket.com: tli set sender to tli@miata.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14660.28914.433592.773100@miata.procket.com> Date: Sun, 11 Jun 2000 22:11:14 -0700 (PDT) To: Radia Perlman - Boston Center for Networking Cc: chopps@djinesys.com, tli@Procket.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] too many segments In-Reply-To: <200006120135.VAA19561@bcn.East.Sun.COM> References: <200006120135.VAA19561@bcn.East.Sun.COM> X-Mailer: VM 6.75 under Emacs 20.4.1 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit | The 1 byte fragment number is a field that in retrospect should have | been larger. As Toni Li pointed out, it should be possible to get around | it with the hack of pretending to be two (or more) nodes with zero cost | between them, and have part of the information reported by each one. | Do people actually do this? Do all implementations calculate correctly | when they see this? Does the Dijkstra calculation do anything weird | with 0-cost adjacencies? (It should work, but I wouldn't be surprised | if some implementations got very confused.) As a pseudo-node adjacency is already at zero cost, there's a fairly high chance that this will work in all implementations. And given that the predominant implementations have a fairly restricted set of authors, who are reasonably general, there's an excellent chance that it Just Works. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 06:15:15 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27397 for ; Mon, 12 Jun 2000 06:15:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA02674; Mon, 12 Jun 2000 03:20:58 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA02643 for ; Mon, 12 Jun 2000 03:20:55 -0700 (PDT) Received: from mshand-8kcdt ([10.49.188.188]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA14737; Mon, 12 Jun 2000 11:10:10 +0100 (BST) Message-Id: <4.2.2.20000612104733.00aba3d0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 12 Jun 2000 11:10:32 +0100 To: Tony Li , Radia Perlman - Boston Center for Networking From: Mike Shand Subject: Re: [Isis-wg] too many segments Cc: chopps@djinesys.com, tli@Procket.com, isis-wg@external.juniper.net In-Reply-To: <14660.28914.433592.773100@miata.procket.com> References: <200006120135.VAA19561@bcn.East.Sun.COM> <200006120135.VAA19561@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 22:11 11/06/2000 -0700, Tony Li wrote: >As a pseudo-node adjacency is already at zero cost, there's a fairly high >chance that this will work in all implementations. And given that the >predominant implementations have a fairly restricted set of authors, who >are reasonably general, there's an excellent chance that it Just Works. Yes, the thing about the pseudonode is that it is carefully crafted such that the zero cost is only in one direction. Dijkstra's algorithm can get upset if the set of LSPs contains a loop who's cost sum is zero. This is avoided in the pseudonode case, but here we would want to have zero cost in BOTH directions (not least, to satisfy the two way check). Its not clear that all implementations would necessarily take kindly to that. The other thing about the zero cost links in pseudonodes, is that you are supposed to give priority to selecting pseudonode LSPs from TENT where there are non-pseudonode LSPs present at equal cost. If we didn't do this and there were equal cost paths one of which was a direct link and the other through the pseudonode, we could fail to detect the path through the pseudonode, because the destination node would already have been added to PATHs and we can't (don't) increment the adjacency set of node already on PATHS. At least I think that was the rationale. So if we have zero cost links which aren't in pseudonodes we might upset an implementation which was doing this (as it is supposed to) on the basis of the LSP being a pseudonode rather than the more general property that it carried zero cost links. Mike Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 11:27:05 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04236 for ; Mon, 12 Jun 2000 11:27:04 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03042; Mon, 12 Jun 2000 08:32:56 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03015 for ; Mon, 12 Jun 2000 08:32:54 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03703 for ; Mon, 12 Jun 2000 08:22:51 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA13890 for ; Mon, 12 Jun 2000 11:22:51 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA25872 for ; Mon, 12 Jun 2000 11:22:50 -0400 (EDT) Message-Id: <200006121522.LAA25872@bcn.East.Sun.COM> Date: Mon, 12 Jun 2000 11:22:49 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] too many segments To: isis-wg@external.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ++fvIJMupMrw+2mfrjDu6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Mike, I didn't quite understand your paragraph >>>we could fail to detect the path through the >>>pseudonode, because the destination node would already have been added to >>>PATHs and we can't (don't) increment the adjacency set of node already on >>>PATHS. But as for your worry about having zero cost loops, I'd think you wouldn't need to have the cost be zero in both directions. For instance, suppose the node that has too much LSP information to fit into 255 fragments is named "A". So A invents new nodes A', A'', A'''. A adds neighbors A', A'', and A''' to its LSP as neighbors with zero cost. A also creates LSPs from A', A'', and A''' with the excess LSP info that didn't fit into the LSP for A, and also each with neighbor A with reasonably large, but finite cost. Would that work, and then eliminate any possible implementation confusion with zero cost loops? Radya ;-) _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 11:42:01 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04674 for ; Mon, 12 Jun 2000 11:42:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03127; Mon, 12 Jun 2000 08:48:00 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA03099 for ; Mon, 12 Jun 2000 08:47:58 -0700 (PDT) Received: from mshand-8kcdt ([10.49.188.188]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA28432; Mon, 12 Jun 2000 16:37:43 +0100 (BST) Message-Id: <4.2.2.20000612163242.00abe2e0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 12 Jun 2000 16:38:21 +0100 To: Radia Perlman - Boston Center for Networking , isis-wg@external.juniper.net From: Mike Shand Subject: Re: [Isis-wg] too many segments In-Reply-To: <200006121522.LAA25872@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 11:22 12/06/2000 -0400, Radia Perlman - Boston Center for Networking wrote: >But as for your worry about having zero cost loops, I'd think you wouldn't >need to have the cost be zero in both directions. For instance, suppose >the node that has too much LSP information to fit into 255 >fragments is named "A". So A invents new nodes A', >A'', A'''. A adds neighbors A', A'', and A''' to its LSP as neighbors with >zero cost. A also creates LSPs from A', A'', and A''' with the excess LSP >info that didn't fit into the LSP for A, and also each with neighbor A with >reasonably large, but finite cost. > >Would that work, and then eliminate any possible implementation confusion >with zero cost loops? I don't think that works in all cases. If the information in A', A'' etc's LSPs are just leaf information, then its fine, but if you had lots of genuine router adjacencies, then I think the two way connectivity check gets you. A' has links to B,C etc. These are real costs. But if we have links from B to A', C to A', then you end up needing to use the A' to A link to compute a route through A. You can't do the obvious thing of making B link directly to A, since then the two way check would get you since there was no link from A to B. Am I making any sense? I admit that the most likely reason for LSP size explosion is lots of imported routes, for which your solution would work fine. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 12:15:01 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05636 for ; Mon, 12 Jun 2000 12:15:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA03225; Mon, 12 Jun 2000 09:20:50 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA03199 for ; Mon, 12 Jun 2000 09:20:48 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27357 for ; Mon, 12 Jun 2000 09:10:44 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23330 for ; Mon, 12 Jun 2000 12:10:43 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id MAA26351 for ; Mon, 12 Jun 2000 12:10:43 -0400 (EDT) Message-Id: <200006121610.MAA26351@bcn.East.Sun.COM> Date: Mon, 12 Jun 2000 12:10:42 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] too many segments To: isis-wg@external.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: H1nb2QfJZlv++woDsIXlaA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Mike, Your point about the genuine router links is correct...but as you also point out, there is no problem with the assymetric costs (nonzero cost when fake nodes point to the real node) when it's for lots of imported routes. So the rule should be explicit about what information is allowed to hang off fake nodes (only leaf information). Would anyone ever need more than 255 fragments' worth of router neighbor information? (for instance, a really humongous "LAN" with thousands of attached routers). Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 12:26:50 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05960 for ; Mon, 12 Jun 2000 12:26:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA03345; Mon, 12 Jun 2000 09:33:13 -0700 (PDT) Received: from web3305.mail.yahoo.com (web3305.mail.yahoo.com [204.71.201.147]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA03318 for ; Mon, 12 Jun 2000 09:33:11 -0700 (PDT) Message-ID: <20000612162307.2126.qmail@web3305.mail.yahoo.com> Received: from [204.71.43.27] by web3305.mail.yahoo.com; Mon, 12 Jun 2000 09:23:07 PDT Date: Mon, 12 Jun 2000 09:23:07 -0700 (PDT) From: newbie To: isis-wg@external.juniper.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] RFC 1195 post script version Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi: Could anyone here tell me where I acn find the post script version of RFC 1195? TIA _ming __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 13:17:42 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07209 for ; Mon, 12 Jun 2000 13:17:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA03521; Mon, 12 Jun 2000 10:25:06 -0700 (PDT) Received: from redd235.procket.com (flowpoint.procket.com [205.253.146.41]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA03490 for ; Mon, 12 Jun 2000 10:25:05 -0700 (PDT) Received: (from tli@localhost) by redd235.procket.com (8.9.3/8.9.3) id KAA03832; Mon, 12 Jun 2000 10:15:01 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14661.6805.95973.61581@redd235.procket.com> Date: Mon, 12 Jun 2000 10:15:01 -0700 (PDT) To: Radia Perlman - Boston Center for Networking Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] too many segments In-Reply-To: <200006121610.MAA26351@bcn.East.Sun.COM> References: <200006121610.MAA26351@bcn.East.Sun.COM> X-Mailer: VM 6.75 under Emacs 20.4.1 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit | Would anyone ever need more than 255 fragments' worth of router neighbor | information? (for instance, a really humongous "LAN" with thousands of | attached routers). Possibly. But the aforementioned solution for creation of additional sysids would apply. The question then degenerates into: do you ever need more than 255 fragments to describe the adjacencies for a single interface? At current technology levels, I bet one can't support the IIH traffic necessary to do this. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 17:03:39 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11243 for ; Mon, 12 Jun 2000 17:03:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA03780; Mon, 12 Jun 2000 14:09:59 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA03754 for ; Mon, 12 Jun 2000 14:09:57 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA07361 for ; Mon, 12 Jun 2000 13:59:53 -0700 (PDT) Received: from web3304.mail.yahoo.com (web3304.mail.yahoo.com [204.71.201.146]) by rojo.juniper.net (8.9.3/8.9.3) with SMTP id OAA21979 for ; Mon, 12 Jun 2000 14:23:28 -0700 (PDT) (envelope-from m1lu@yahoo.com) Message-ID: <20000612205950.13096.qmail@web3304.mail.yahoo.com> Received: from [204.71.43.27] by web3304.mail.yahoo.com; Mon, 12 Jun 2000 13:59:50 PDT Date: Mon, 12 Jun 2000 13:59:50 -0700 (PDT) From: newbie To: IS-IS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isis-wg] router ID for IS-IS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi: What does IS-IS use for router ID? NSAP's systme ID? most of vendor uses MAC address for NSAP system ID, but what about there is no ethernet card in the router? what is the role of loopback address in the IS-IS? thanks __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 18:03:27 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11988 for ; Mon, 12 Jun 2000 18:03:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA03939; Mon, 12 Jun 2000 15:10:52 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA03910 for ; Mon, 12 Jun 2000 15:10:50 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA12352 for ; Mon, 12 Jun 2000 15:00:46 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id PAA23869 for ; Mon, 12 Jun 2000 15:24:21 -0700 (PDT) (envelope-from rsaluja@nortelnetworks.com) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Mon, 12 Jun 2000 17:45:56 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MZW7LX7F; Mon, 12 Jun 2000 17:45:55 -0400 Received: from nortelnetworks.com (CC775382-A [132.245.139.135]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS522C5X; Mon, 12 Jun 2000 17:45:53 -0400 Message-ID: <394559F5.22202F56@nortelnetworks.com> Date: Mon, 12 Jun 2000 17:45:25 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rajesh Saluja" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-AtHome0402 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: newbie CC: IS-IS Subject: Re: [Isis-wg] router ID for IS-IS References: <20000612205950.13096.qmail@web3304.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit newbie wrote: > > Hi: > > What does IS-IS use for router ID? NSAP's systme ID? > most of vendor uses MAC address for NSAP system ID, > but what about there is no ethernet card in the > router? what is the role of loopback address in the > IS-IS? It need not be MAC address. It is basically 1 to 8 octets long value ( almost all implementations use 6 octets ) which should be unique in a routing domain. People use loopback address so as to have reachability to a router till there is at least one physical interface to reach the router. ( eg : in BGP next hop ). IS-IS treats loopback address as just another reachability information. Hope it helps. Regards, Rajesh _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 18:37:14 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12523 for ; Mon, 12 Jun 2000 18:37:13 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA04053; Mon, 12 Jun 2000 15:44:49 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA04023 for ; Mon, 12 Jun 2000 15:44:47 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id PAA15056 for ; Mon, 12 Jun 2000 15:34:44 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id PAA24971 for ; Mon, 12 Jun 2000 15:58:18 -0700 (PDT) (envelope-from jparker@nexabit.com) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id SAA15916; Mon, 12 Jun 2000 18:34:39 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Mon, 12 Jun 2000 18:34:39 -0400 Message-ID: From: Jeff Parker To: newbie , IS-IS Subject: RE: [Isis-wg] router ID for IS-IS Date: Mon, 12 Jun 2000 18:34:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > What does IS-IS use for router ID? If you use the same router ID that BGP and OSPF use, then you may be able to share some information between the protocols. This doesn't really answer your question, but does suggest that you define some answer common to all protocols you support. - jeff parker - Lucent _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 21:49:46 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15146 for ; Mon, 12 Jun 2000 21:49:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA04323; Mon, 12 Jun 2000 18:56:54 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA04293 for ; Mon, 12 Jun 2000 18:56:53 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA00467 for ; Mon, 12 Jun 2000 18:46:47 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id TAA29463 for ; Mon, 12 Jun 2000 19:10:24 -0700 (PDT) (envelope-from rsaluja@nortelnetworks.com) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by ertpg14e1.nortelnetworks.com; Mon, 12 Jun 2000 21:41:57 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M2YMZVV6; Mon, 12 Jun 2000 18:41:55 -0700 Received: from nortelnetworks.com (CC775382-A [132.245.139.135]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS522C82; Mon, 12 Jun 2000 21:41:54 -0400 Message-ID: <39459147.15E87227@nortelnetworks.com> Date: Mon, 12 Jun 2000 21:41:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rajesh Saluja" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-AtHome0402 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: IS-IS Subject: Re: [Isis-wg] router ID for IS-IS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Jeff Parker wrote: > If you use the same router ID that BGP and OSPF > use, then you may be able to share some information > between the protocols. > > This doesn't really answer your question, but > does suggest that you define some answer > common to all protocols you support. Jeff, I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes long ) same as BGP router ID ( which is 4 bytes long )? The same router ID for BGP and OSPF is very helpful when you import routes from BGP into OSPF routing domain. I am not sure if anybody distributes BGP routes into IISIS domain in the field? Regards, Rajesh _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 22:24:10 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15437 for ; Mon, 12 Jun 2000 22:24:09 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA04420; Mon, 12 Jun 2000 19:31:58 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA04392 for ; Mon, 12 Jun 2000 19:31:56 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA02477 for ; Mon, 12 Jun 2000 19:21:51 -0700 (PDT) Received: from redd235.procket.com (flowpoint.procket.com [205.253.146.41]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id TAA30001 for ; Mon, 12 Jun 2000 19:45:28 -0700 (PDT) (envelope-from tli@Procket.com) Received: (from tli@localhost) by redd235.procket.com (8.9.3/8.9.3) id TAA04739; Mon, 12 Jun 2000 19:21:46 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: redd235.procket.com: tli set sender to tli@redd235.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14661.39610.752849.569242@redd235.procket.com> Date: Mon, 12 Jun 2000 19:21:46 -0700 (PDT) To: "Rajesh Saluja" Cc: Jeff Parker , IS-IS Subject: Re: [Isis-wg] router ID for IS-IS In-Reply-To: <39459147.15E87227@nortelnetworks.com> References: <39459147.15E87227@nortelnetworks.com> X-Mailer: VM 6.75 under Emacs 20.4.1 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit | I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes | long ) same as BGP router ID ( which is 4 bytes long )? The same router | ID for BGP and OSPF is very helpful when you import routes from BGP into | OSPF routing domain. Many people do this, but not in the obvious way. They take the IP router ID and convert it into Binary Coded Decimal, concatenate it and then use those resulting 6 bytes as the system id. For example: router id 1.2.3.4 => 001.002.003.004 | V 0x001002003004 | V 0x00 0x10 0x02 0x00 0x30 0x04 Ugly, eh? | I am not sure if anybody distributes BGP routes into IISIS domain in the | field? This turns out to be a very bad idea, in so very many ways. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 12 22:41:08 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16530 for ; Mon, 12 Jun 2000 22:41:07 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA04500; Mon, 12 Jun 2000 19:48:39 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA04473 for ; Mon, 12 Jun 2000 19:48:37 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA03814 for ; Mon, 12 Jun 2000 19:38:32 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id UAA30261 for ; Mon, 12 Jun 2000 20:02:09 -0700 (PDT) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id UAA32417 for ; Mon, 12 Jun 2000 20:39:42 -0600 Message-Id: <200006130239.UAA32417@tcb.net> X-Mailer: exmh version 2.0.3 To: IS-IS From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] router ID for IS-IS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jun 2000 20:39:42 -0600 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > I was wondering if anybody uses ISIS router ID ( which is 1 to 8 bytes > long ) same as BGP router ID ( which is 4 bytes long )? While it could be 1-8 octets in length, nobody ever uses anything other than 6 octets for sysid. > The same router > ID for BGP and OSPF is very helpful when you import routes from BGP into > OSPF routing domain. I am not sure if anybody distributes BGP routes > into IISIS domain in the field? Usually not intentionally, and even if unintentionally, not for very long ;-) A common practice is for service providers to map the loopback IP address of the router to the sysid (4 octets -> 6 octets, padded), this eases management overhead, especially when using automated tools. For example, a router with a IP loopback address of 192.168.56.1 would have a sysid value of 1921.6805.6001. Though this is a bit more intuitive, it's little more. -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 13 09:27:02 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07235 for ; Tue, 13 Jun 2000 09:27:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA05264; Tue, 13 Jun 2000 06:31:23 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA05234 for ; Tue, 13 Jun 2000 06:31:21 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA20143 for ; Tue, 13 Jun 2000 06:21:12 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id GAA38090 for ; Tue, 13 Jun 2000 06:44:52 -0700 (PDT) (envelope-from jparker@nexabit.com) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id JAA18624; Tue, 13 Jun 2000 09:20:12 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Jun 2000 09:20:13 -0400 Message-ID: From: Jeff Parker To: Tony Li , Rajesh Saluja Cc: Jeff Parker , IS-IS Subject: RE: [Isis-wg] router ID for IS-IS Date: Tue, 13 Jun 2000 09:20:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > I was wondering if anybody uses ISIS router ID ( which is > 1 to 8 bytes long ) same as BGP router ID ( which is 4 bytes > long )? Sorry that I continued this confussion. There are two IDs at issue here: the 6 byte System ID, and the 4 byte Router ID used, for example, in Traffic Engineering. I think mostt of the posts on this thread were really about the System ID: I confused things by talking reading the words, rather than the intent of the posting. - jeff parker - Lucent Technology _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 13 11:04:32 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10782 for ; Tue, 13 Jun 2000 11:04:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05427; Tue, 13 Jun 2000 08:11:11 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05399 for ; Tue, 13 Jun 2000 08:11:09 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA29278 for ; Tue, 13 Jun 2000 08:01:00 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id IAA40744 for ; Tue, 13 Jun 2000 08:24:42 -0700 (PDT) (envelope-from Radia.Perlman@East.Sun.COM) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11098 for ; Tue, 13 Jun 2000 08:00:51 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA03088 for ; Tue, 13 Jun 2000 11:00:48 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA04924 for ; Tue, 13 Jun 2000 11:00:46 -0400 (EDT) Message-Id: <200006131500.LAA04924@bcn.East.Sun.COM> Date: Tue, 13 Jun 2000 11:00:46 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] router ID for IS-IS To: isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3p5xlSek47EvSspuvrncdA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I never thought the variable length system ID was a good idea. Just one of these design by committee things added trying to be fancy, at the expense of ugliness and little or no functionality. Especially since it's the kind of thing that can cause serious problems if anyone really did try to make routers use different sizes. It might be nice someday to rewrite the spec and take out things like that. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 13 11:57:29 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12816 for ; Tue, 13 Jun 2000 11:57:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA05540; Tue, 13 Jun 2000 09:05:25 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA05514 for ; Tue, 13 Jun 2000 09:05:23 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA05125 for ; Tue, 13 Jun 2000 08:55:13 -0700 (PDT) Received: from web3306.mail.yahoo.com (web3306.mail.yahoo.com [204.71.201.155]) by rojo.juniper.net (8.9.3/8.9.3) with SMTP id JAA42045 for ; Tue, 13 Jun 2000 09:18:55 -0700 (PDT) (envelope-from m1lu@yahoo.com) Message-ID: <20000613155510.10437.qmail@web3306.mail.yahoo.com> Received: from [204.71.43.27] by web3306.mail.yahoo.com; Tue, 13 Jun 2000 08:55:10 PDT Date: Tue, 13 Jun 2000 08:55:10 -0700 (PDT) From: newbie Subject: Re: [Isis-wg] router ID for IS-IS To: Rajesh Saluja , Jeff Parker Cc: IS-IS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net The role of IS-IS is the same as OSPF. If someone wants to redistribute BGP routes into OSPF, then there will be some cases one wants to redistribute BGP into IS-IS. -newbie --- Rajesh Saluja wrote: > > Jeff Parker wrote: > > > If you use the same router ID that BGP and OSPF > > use, then you may be able to share some > information > > between the protocols. > > > > This doesn't really answer your question, but > > does suggest that you define some answer > > common to all protocols you support. > > Jeff, > I was wondering if anybody uses ISIS router ID ( > which is 1 to 8 bytes > long ) same as BGP router ID ( which is 4 bytes long > )? The same router > ID for BGP and OSPF is very helpful when you import > routes from BGP into > OSPF routing domain. I am not sure if anybody > distributes BGP routes > into IISIS domain in the field? > > Regards, > Rajesh > > _______________________________________________ > Isis-wg mailing list - > Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:06:33 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05670 for ; Wed, 14 Jun 2000 19:06:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07830; Wed, 14 Jun 2000 16:13:16 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA07038 for ; Wed, 14 Jun 2000 10:35:32 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA25368 for ; Wed, 14 Jun 2000 10:25:15 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id KAA72112 for ; Wed, 14 Jun 2000 10:49:06 -0700 (PDT) (envelope-from pkoning@xedia.com) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiton25831; Wed, 14 Jun 2000 17:25:10 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02942; Wed, 14 Jun 00 13:21:32 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA15070; Wed, 14 Jun 2000 13:25:09 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.49140.785124.646034@xedia.com> Date: Wed, 14 Jun 2000 13:25:08 -0400 (EDT) To: mat@cisco.com Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: What keeps nagging at me is the overhead Michael> of both AH and ESP, not to mention the added complexity. >> Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? >> That's no help, because that is exactly the difference that makes >> AH so much harder than ESP. (Well, there's details like having >> the MAC in the header rather than the trailer. Then again, ESP >> puts the NextHeader value in the wrong place, so they're even...) >> >> The reason I like ESP authentication is precisely the fact that it >> doesn't contain all the hair needed to protect a subset of IP >> header fields. Michael> Maybe you're misunderstanding me: if ESP had a bit which Michael> said "I'm protecting the outside headers too", it could be Michael> either signaled or potentially even done on an as-needed Michael> basis by the IPsec stack for IP headers which would Michael> otherwise require AH. I'm all for not protecting things that Michael> don't need protection otherwise. I think I understood. The issue is that the bit you're describing is actually the only essential difference between AH and ESP. In other words, you can think of it as the "do AH" bit. You can't just "protect the outside headers too". You have to be selective about it, protecting only immutable ones, skipping fields and headers that change in transit, mumble mumble mumble. That's the "hair" of AH I'm referring to. It doesn't matter what you call it or how you encode it. The hypothetical "ESP with the bit" you describe has to do the same thing so it has to contain the same amount of hair. paul _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:06:44 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05681 for ; Wed, 14 Jun 2000 19:06:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07578; Wed, 14 Jun 2000 16:12:53 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA07122 for ; Wed, 14 Jun 2000 11:29:43 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA29907 for ; Wed, 14 Jun 2000 11:19:25 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id LAA73725 for ; Wed, 14 Jun 2000 11:43:16 -0700 (PDT) (envelope-from pkoning@xedia.com) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitor15103; Wed, 14 Jun 2000 18:19:21 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA03726; Wed, 14 Jun 00 14:15:43 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA15369; Wed, 14 Jun 2000 14:19:20 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.52391.764650.742840@xedia.com> Date: Wed, 14 Jun 2000 14:19:19 -0400 (EDT) To: bmccann@indusriver.com Cc: mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> <3947C9D3.15B959C7@indusriver.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit >>>>> "Ben" == Ben McCann writes: Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? Ben> Aren't your goals met by using ESP _tunnel_ mode? Just tunnel Ben> the OSPF, RIP, etc, packet from one box to the other. The Ben> tunneled packet has an inner IP header is completely secured by Ben> ESP. This is the header seen by OSPF, RIP, etc, once ESP Ben> completes the authentication of the packet. That certainly does the job. The trouble appears if someone wants to use transport mode (perhaps to save a few bytes) and then decides that for some reason there are IP headers worthy of protection. That's where the messy hybrid (AH) appears. paul _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:06:48 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05692 for ; Wed, 14 Jun 2000 19:06:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07520; Wed, 14 Jun 2000 16:12:49 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA06768 for ; Wed, 14 Jun 2000 06:43:28 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA07952 for ; Wed, 14 Jun 2000 06:33:12 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id GAA65797 for ; Wed, 14 Jun 2000 06:57:01 -0700 (PDT) (envelope-from pkoning@xedia.com) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitny04739; Wed, 14 Jun 2000 13:33:08 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA28969; Wed, 14 Jun 00 09:29:31 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA14693; Wed, 14 Jun 2000 09:33:07 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.35217.793569.559881@xedia.com> Date: Wed, 14 Jun 2000 09:33:05 -0400 (EDT) To: Stephen.Waters@cabletron.com Cc: ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit >>>>> "Waters," == Waters, Stephen writes: Waters,> There has been some discussion recently on the possible Waters,> deprecation of the Authentication Header defined for Waters,> 'whole-packet' authentication. Waters,> I 'think' the decision was to leave it alone, and allow AH Waters,> to wait for its day. >> From reading the various, associated methods of securing ISIS, >> OSPF and Waters,> RIPV2 messages, it seems to me that AH is perfect for the Waters,> protection of these protocols. Waters,> The current HMAC-MD5 options have the following exposures Waters,> that are solved with AH: Waters,> 1) no source address authentication (IP header Waters,> authentication in general) 2) poor/no replay protection 3) Waters,> manual keys - which restricts key length and complexity to Waters,> human-manageable keys, and makes for difficult key change Waters,> procedures. Waters,> IPSEC+AH would seem to be a good choice for all control Waters,> traffic exchange between routers. If this exchange is Waters,> confidential, the ESP could be used as well. Yes, but if it's not confidential (which is the likely case) then ESP in authentication only mode will serve just as well. It's never been the point of any of this discussion to deprecate the notion that authentication is useful -- the issue is whether it makes sense to retain AH when ESP does the job with significantly less hassle. paul _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:06:53 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05703 for ; Wed, 14 Jun 2000 19:06:52 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07796; Wed, 14 Jun 2000 16:13:11 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA06971 for ; Wed, 14 Jun 2000 10:14:07 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA23742 for ; Wed, 14 Jun 2000 10:03:49 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id KAA71438 for ; Wed, 14 Jun 2000 10:27:40 -0700 (PDT) (envelope-from pkoning@xedia.com) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitom06745; Wed, 14 Jun 2000 17:03:45 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02597; Wed, 14 Jun 00 13:00:07 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA14999; Wed, 14 Jun 2000 13:03:43 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14663.47855.662864.377087@xedia.com> Date: Wed, 14 Jun 2000 13:03:43 -0400 (EDT) To: mat@cisco.com Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate >> the notion that authentication is useful -- the issue is whether >> it makes sense to retain AH when ESP does the job with >> significantly less hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, Michael> not to mention the added complexity. Michael> This might be water well under the bridge, but has the Michael> thought of having a mode to ESP which protects the outer Michael> headers? That's no help, because that is exactly the difference that makes AH so much harder than ESP. (Well, there's details like having the MAC in the header rather than the trailer. Then again, ESP puts the NextHeader value in the wrong place, so they're even...) The reason I like ESP authentication is precisely the fact that it doesn't contain all the hair needed to protect a subset of IP header fields. paul _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:07:18 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05715 for ; Wed, 14 Jun 2000 19:07:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07728; Wed, 14 Jun 2000 16:13:06 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA06878 for ; Wed, 14 Jun 2000 08:41:03 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA16400 for ; Wed, 14 Jun 2000 08:30:47 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id IAA68697 for ; Wed, 14 Jun 2000 08:54:37 -0700 (PDT) (envelope-from thomasm@cisco.com) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA07678; Wed, 14 Jun 2000 08:29:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03702; Wed, 14 Jun 2000 08:29:41 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.42213.816377.583137@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 08:29:41 -0700 (PDT) To: Paul Koning Cc: Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <14663.35217.793569.559881@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Paul Koning writes: > It's never been the point of any of this discussion to deprecate the > notion that authentication is useful -- the issue is whether it makes > sense to retain AH when ESP does the job with significantly less > hassle. What keeps nagging at me is the overhead of both AH and ESP, not to mention the added complexity. This might be water well under the bridge, but has the thought of having a mode to ESP which protects the outer headers? I know that's contrary to the "encapsulating" part, but if we want to converge on one crypto header, it seems to me that placing an artificial restriction that outside headers can never be protected is pretty arbitrary and wrongheaded (even though I'm persuaded by Steve Bellovin's arguments about v4 headers). Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:07:19 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05716 for ; Wed, 14 Jun 2000 19:07:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07553; Wed, 14 Jun 2000 16:12:51 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA07312 for ; Wed, 14 Jun 2000 13:34:14 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA09772 for ; Wed, 14 Jun 2000 13:23:56 -0700 (PDT) Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id NAA77222 for ; Wed, 14 Jun 2000 13:47:47 -0700 (PDT) (envelope-from mcr@solidum.com) Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id QAA15540; Wed, 14 Jun 2000 16:22:37 -0400 Message-Id: <200006142022.QAA15540@solidum.com> To: mat@cisco.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: Your message of "Wed, 14 Jun 2000 10:20:06 PDT." <14663.48838.383043.113376@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 16:22:37 -0400 From: Michael Richardson Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net >>>>> "Michael" == Michael Thomas writes: Michael> Maybe you're misunderstanding me: if ESP had a bit which said Michael> "I'm protecting the outside headers too", it could be either Michael> signaled or potentially even done on an as-needed basis by the Michael> IPsec stack for IP headers which would otherwise require AH. I'm Michael> all for not protecting things that don't need protection Michael> otherwise. The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of authentication that ESP does not (at least for IPv4). The outer headers are all either irrelevant, or can be derived from the SPD, so you don't have to trust them. I believe that there are other things that AH provides (like the guarantee that the contents are not encrypted and therefore can be audited), and things that will be defined in IPv6-extension land that will make AH a useful thing to keep in the spec, just not MUST it. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:07:26 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05736 for ; Wed, 14 Jun 2000 19:07:24 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07491; Wed, 14 Jun 2000 16:12:47 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA07232 for ; Wed, 14 Jun 2000 12:15:34 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA04124 for ; Wed, 14 Jun 2000 12:05:16 -0700 (PDT) Received: from solidum.com (wirespeed.solidum.com [216.13.130.242]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id MAA75185 for ; Wed, 14 Jun 2000 12:29:07 -0700 (PDT) (envelope-from mcr@solidum.com) Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id PAA11044; Wed, 14 Jun 2000 15:02:50 -0400 Message-Id: <200006141902.PAA11044@solidum.com> To: Michael Thomas , Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: Your message of "Wed, 14 Jun 2000 08:29:41 PDT." <14663.42213.816377.583137@thomasm-u1.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jun 2000 15:02:50 -0400 From: Michael Richardson Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net >>>>> "Michael" == Michael Thomas writes: Michael> Paul Koning writes: >> It's never been the point of any of this discussion to deprecate the >> notion that authentication is useful -- the issue is whether it makes >> sense to retain AH when ESP does the job with significantly less >> hassle. Michael> What keeps nagging at me is the overhead of both AH and ESP, not Michael> to mention the added complexity. If two routers need privacy and authenticity, they can use end-to-end ESP, as they can get strong origin authentication by virtue of the integrity check succeeding in the ESP. Don't trust the source IP, rather take the appropriate source IP from the SA to look up the appropriate PCB for the TCP/UDP session you are protecting. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:07:30 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05747 for ; Wed, 14 Jun 2000 19:07:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07719; Wed, 14 Jun 2000 16:13:03 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA07009 for ; Wed, 14 Jun 2000 10:31:29 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA25027 for ; Wed, 14 Jun 2000 10:21:12 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id KAA72011 for ; Wed, 14 Jun 2000 10:45:03 -0700 (PDT) (envelope-from thomasm@cisco.com) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA08897; Wed, 14 Jun 2000 10:20:17 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA03710; Wed, 14 Jun 2000 10:20:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.48838.383043.113376@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 10:20:06 -0700 (PDT) To: Paul Koning Cc: mat@cisco.com, Stephen.Waters@cabletron.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <14663.47855.662864.377087@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Paul Koning writes: > Michael> What keeps nagging at me is the overhead of both AH and ESP, > Michael> not to mention the added complexity. > > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? > > That's no help, because that is exactly the difference that makes AH > so much harder than ESP. (Well, there's details like having the MAC > in the header rather than the trailer. Then again, ESP puts the > NextHeader value in the wrong place, so they're even...) > > The reason I like ESP authentication is precisely the fact that it > doesn't contain all the hair needed to protect a subset of IP header > fields. Maybe you're misunderstanding me: if ESP had a bit which said "I'm protecting the outside headers too", it could be either signaled or potentially even done on an as-needed basis by the IPsec stack for IP headers which would otherwise require AH. I'm all for not protecting things that don't need protection otherwise. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:07:49 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05760 for ; Wed, 14 Jun 2000 19:07:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07938; Wed, 14 Jun 2000 16:13:26 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA07198 for ; Wed, 14 Jun 2000 12:04:59 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA03106 for ; Wed, 14 Jun 2000 11:54:41 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id MAA74859 for ; Wed, 14 Jun 2000 12:18:33 -0700 (PDT) (envelope-from thomasm@cisco.com) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA14693; Wed, 14 Jun 2000 11:54:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03723; Wed, 14 Jun 2000 11:54:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.54477.878441.566118@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 11:54:05 -0700 (PDT) To: Ben McCann Cc: Paul Koning , mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <3947C9D3.15B959C7@indusriver.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> <3947C9D3.15B959C7@indusriver.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Ben McCann writes: > > Michael> This might be water well under the bridge, but has the > > Michael> thought of having a mode to ESP which protects the outer > > Michael> headers? > > Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, > RIP, etc, packet from one box to the other. The tunneled packet has an > inner IP header is completely secured by ESP. This is the header seen > by OSPF, RIP, etc, once ESP completes the authentication of the packet. > See my previous post. Throwing bytes at the problem is certainly one way to solve it, but it may not be practical in many, many cases. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:07:58 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05770 for ; Wed, 14 Jun 2000 19:07:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07906; Wed, 14 Jun 2000 16:13:22 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA06555 for ; Wed, 14 Jun 2000 02:49:25 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id CAA25686 for ; Wed, 14 Jun 2000 02:39:10 -0700 (PDT) Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id DAA62816 for ; Wed, 14 Jun 2000 03:02:58 -0700 (PDT) (envelope-from Stephen.Waters@cabletron.com) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id FAA14004; Wed, 14 Jun 2000 05:43:31 -0400 (EDT) Received: from roc-mail2.cabletron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma014000; Wed, 14 Jun 00 05:43:29 -0400 Received: from new-exc1.ctron.com (new-exc1.ctron.com [134.141.200.123]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id FAA26304; Wed, 14 Jun 2000 05:39:04 -0400 (EDT) Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jun 2000 10:39:04 +0100 Message-ID: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> From: "Waters, Stephen" To: ipsec@lists.tislabs.com Cc: isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com Date: Wed, 14 Jun 2000 10:38:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net There has been some discussion recently on the possible deprecation of the Authentication Header defined for 'whole-packet' authentication. I 'think' the decision was to leave it alone, and allow AH to wait for its day. From reading the various, associated methods of securing ISIS, OSPF and RIPV2 messages, it seems to me that AH is perfect for the protection of these protocols. The current HMAC-MD5 options have the following exposures that are solved with AH: 1) no source address authentication (IP header authentication in general) 2) poor/no replay protection 3) manual keys - which restricts key length and complexity to human-manageable keys, and makes for difficult key change procedures. IPSEC+AH would seem to be a good choice for all control traffic exchange between routers. If this exchange is confidential, the ESP could be used as well. Regards, Steve. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:08:02 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05780 for ; Wed, 14 Jun 2000 19:08:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07950; Wed, 14 Jun 2000 16:13:27 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA07166 for ; Wed, 14 Jun 2000 11:59:11 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA02607 for ; Wed, 14 Jun 2000 11:48:53 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id MAA74689 for ; Wed, 14 Jun 2000 12:12:45 -0700 (PDT) (envelope-from thomasm@cisco.com) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA02111; Wed, 14 Jun 2000 11:48:31 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03717; Wed, 14 Jun 2000 11:48:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14663.54131.519220.652837@thomasm-u1.cisco.com> Date: Wed, 14 Jun 2000 11:48:19 -0700 (PDT) To: Paul Koning Cc: mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com In-Reply-To: <14663.49140.785124.646034@xedia.com> References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Paul Koning writes: > The issue is that the bit you're describing is actually the only > essential difference between AH and ESP. In other words, you can > think of it as the "do AH" bit. > > You can't just "protect the outside headers too". You have to be > selective about it, protecting only immutable ones, skipping fields > and headers that change in transit, mumble mumble mumble. That's the > "hair" of AH I'm referring to. It doesn't matter what you call it or > how you encode it. The hypothetical "ESP with the bit" you describe > has to do the same thing so it has to contain the same amount of hair. Sure. Doing AH-like functionality is a pain; if you have to do it, you have to do it -- that's just a given. What I don't like is having a completely separate header with its associated complexity and (especially) overhead. Right now though, if I had a flow which for some reason need privacy and outer header protection (ie, AH functionality), you'd have to put on an AH and ESP header. This means that the SPI and the Sequence are completely redundant, as well as having to burn another longword for the redundant header, thus I'm having to add yet another 12 bytes per packet. If we're talking about something like RTP audio, that's probably significant. Then of course there's the issue of, say, CRTP. I don't think that a profile for crypto for CRTP has been done to compress the predictable parts of the crypto headers, (ie, SPI, SEQ, next header), but having to contend with *both* AH and ESP would make crypto-aware CRTP an even uglier proposition. The same, incidentally, goes for normal header compression, and the coming IP enabled cellular stuff is going to absolutely demand both compression as well as security. Whether it is wise to open up this debate yet again is questionable, but life is only going to get more complicated if AH stays around. Pick your poison. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 14 19:08:14 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05790 for ; Wed, 14 Jun 2000 19:08:12 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA07720; Wed, 14 Jun 2000 16:13:03 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA07094 for ; Wed, 14 Jun 2000 11:23:20 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA29246 for ; Wed, 14 Jun 2000 11:13:02 -0700 (PDT) Received: from post.indusriver.com (indus-bh.indusriver.com [63.81.64.2]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id LAA73561 for ; Wed, 14 Jun 2000 11:36:53 -0700 (PDT) (envelope-from bmccann@indusriver.com) Received: from indusriver.com (172.16.4.141) by post.indusriver.com (Worldmail 1.3.167); 14 Jun 2000 14:11:12 -0400 Message-ID: <3947C9D3.15B959C7@indusriver.com> Date: Wed, 14 Jun 2000 14:07:16 -0400 From: Ben McCann X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: mat@cisco.com, ipsec@lists.tislabs.com, isis-wg@juniper.net, ospf@discuss.microsoft.com, ietf-rip@baynetworks.com References: <29752A74B6C5D211A4920090273CA3DC01D282D3@new-exc1.ctron.com> <14663.35217.793569.559881@xedia.com> <14663.42213.816377.583137@thomasm-u1.cisco.com> <14663.47855.662864.377087@xedia.com> <14663.48838.383043.113376@thomasm-u1.cisco.com> <14663.49140.785124.646034@xedia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Michael> This might be water well under the bridge, but has the > Michael> thought of having a mode to ESP which protects the outer > Michael> headers? Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF, RIP, etc, packet from one box to the other. The tunneled packet has an inner IP header is completely secured by ESP. This is the header seen by OSPF, RIP, etc, once ESP completes the authentication of the packet. -Ben McCann -- Ben McCann Indus River Networks 31 Nagog Park Acton, MA, 01720 email: bmccann@indusriver.com web: www.indusriver.com phone: (978) 266-8140 fax: (978) 266-8111 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu Jun 15 15:21:43 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12448 for ; Thu, 15 Jun 2000 15:21:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA00332; Thu, 15 Jun 2000 12:28:41 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA00258 for ; Thu, 15 Jun 2000 12:28:37 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA18786 for ; Thu, 15 Jun 2000 06:56:42 -0700 (PDT) Received: from c000.snv.cp.net (c000-h007.c000.snv.cp.net [209.228.32.71]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with SMTP id GAA04017 for ; Thu, 15 Jun 2000 06:56:06 -0700 (PDT) (envelope-from ben.abarbanel@ipoptical.com) Received: (cpmta 18249 invoked from network); 15 Jun 2000 06:56:37 -0700 Received: from dhcp182.altasoft.com (HELO lap) (204.242.142.182) by smtp.ipoptical.com with SMTP; 15 Jun 2000 06:56:37 -0700 X-Sent: 15 Jun 2000 13:56:37 GMT Message-ID: <001801bfd6ea$fa391700$b68ef2cc@ipoptical.com> From: "ben abarbanel" To: Date: Thu, 15 Jun 2000 09:58:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BFD6B0.4CCDB100" Subject: [Isis-wg] Maximum number of adjacencies Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the absolute maximum number of adjacencies per router various = vendors have defined in their software? I know we have a circuit ID maximum of 255, but assuming we can solve = that with IS-IS 3 way handshake. Thanks in advance for your input. Ben ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the absolute maximum number of = adjacencies=20 per router various vendors have defined in their software?
I know we have a circuit ID maximum of = 255, but=20 assuming we can solve that with IS-IS 3 way handshake.
 
Thanks in advance for your = input.
 
Ben
 
 
------=_NextPart_000_0015_01BFD6B0.4CCDB100-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 16 01:37:03 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29198 for ; Fri, 16 Jun 2000 01:37:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA00908; Thu, 15 Jun 2000 22:42:52 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA00882 for ; Thu, 15 Jun 2000 22:42:47 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id WAA15280 for ; Thu, 15 Jun 2000 22:32:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.sun.com [192.18.98.31]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id WAA21657 for ; Thu, 15 Jun 2000 22:32:07 -0700 (PDT) (envelope-from Radia.Perlman@East.Sun.COM) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA02283; Thu, 15 Jun 2000 23:32:39 -0600 (MDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA17743; Fri, 16 Jun 2000 01:32:38 -0400 (EDT) Received: from albuquerque (albuquerque.Eng.Sun.COM [129.144.250.132]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id BAA08121; Fri, 16 Jun 2000 01:32:38 -0400 (EDT) Message-Id: <200006160532.BAA08121@bcn.East.Sun.COM> Date: Thu, 15 Jun 2000 22:32:53 -0700 (PDT) From: Radia Perlman Reply-To: Radia Perlman To: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tY47jNmd547KooeJYN/iYw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Ran said: >> A counter-example is the Source Routing header, which can >> be authenticated hop-by-hop with AH ... How do you authenticate something hop-by-hop when the key is only known end-to-end? Are you maybe assuming hop-by-hop IPSec tunnels between the routers listed in the source route header? Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 00:18:21 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14634 for ; Mon, 19 Jun 2000 00:18:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA04854; Sun, 18 Jun 2000 21:14:19 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA04822 for ; Sun, 18 Jun 2000 21:14:17 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id VAA23251; Sun, 18 Jun 2000 21:04:01 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id VAA00522; Sun, 18 Jun 2000 21:03:59 -0700 (PDT) Date: Sun, 18 Jun 2000 21:03:59 -0700 (PDT) Message-Id: <200006190403.VAA00522@cirrus.juniper.net> From: Dave Katz To: ben.abarbanel@ipoptical.com CC: isis-wg@juniper.net In-reply-to: <001801bfd6ea$fa391700$b68ef2cc@ipoptical.com> (ben.abarbanel@ipoptical.com) Subject: Re: [Isis-wg] Maximum number of adjacencies Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net There should be no need for an absolute maximum number. The dominant implementations have demonstrated hundreds of adjacencies. There will be a point, of course, where things will no longer work, but there is nothing in the protocol precluding arbitrary numbers of neighbors. X-Sent: 15 Jun 2000 13:56:37 GMT From: "ben abarbanel" Date: Thu, 15 Jun 2000 09:58:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01BFD6B0.4CCDB100" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What is the absolute maximum number of adjacencies per router various = vendors have defined in their software? I know we have a circuit ID maximum of 255, but assuming we can solve = that with IS-IS 3 way handshake. Thanks in advance for your input. Ben ------=_NextPart_000_0015_01BFD6B0.4CCDB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What is the absolute maximum number of = adjacencies=20 per router various vendors have defined in their software?
I know we have a circuit ID maximum of = 255, but=20 assuming we can solve that with IS-IS 3 way handshake.
 
Thanks in advance for your = input.
 
Ben
 
 
------=_NextPart_000_0015_01BFD6B0.4CCDB100-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 06:14:56 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28378 for ; Mon, 19 Jun 2000 06:14:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA05335; Mon, 19 Jun 2000 03:06:55 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA05306 for ; Mon, 19 Jun 2000 03:06:53 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id CAA08845 for ; Mon, 19 Jun 2000 02:56:35 -0700 (PDT) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with SMTP id CAA56626 for ; Mon, 19 Jun 2000 02:55:46 -0700 (PDT) (envelope-from emmanuel.dauvergne@rd.francetelecom.fr) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Jun 2000 11:56:15 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B4C3@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS To: "'isis-wg@juniper.net'" Date: Mon, 19 Jun 2000 11:56:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] reservation and preemption Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hello, In RFC2702, it's planned to use the preemptive (preemptor and/or preemptable) characteristics of reservations to choose one path or another. To provide this, shouldn't we distinguish the "unreserved bandwidth" from the 'bandwidth already reserved but preemptable", and therefore introduce a new sub-TLV in TLV 22 ? Or is this the aim of the three additional TE-metrics defined in draft-fedyk-isis-ospf-te-metrics-00.txt ? Thanks for clarification Manu _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 09:58:38 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05920 for ; Mon, 19 Jun 2000 09:58:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA05599; Mon, 19 Jun 2000 06:51:23 -0700 (PDT) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA05569 for ; Mon, 19 Jun 2000 06:51:20 -0700 (PDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JQSJAEG97600054J@research.kpn.com> for isis-wg@external.juniper.net; Mon, 19 Jun 2000 15:40:58 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 15:40:57 +0100 Content-return: allowed Date: Mon, 19 Jun 2000 15:40:56 +0100 From: "Metz, E.T." To: isis-wg@external.juniper.net Message-id: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Areas in ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi all, is it possible to have an ISIS network with different areas, but without an explicit backbone area? I thought it could be done because the L1/L2 routers in each of the areas will form (L2) adjacencies and exchange routing info. So even without a real backbone area, traffic will still flow between differents areas. Is the above correct? Does it make any sense? cheers, Eduard _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 10:30:46 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07323 for ; Mon, 19 Jun 2000 10:30:45 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA05725; Mon, 19 Jun 2000 07:25:51 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA05698 for ; Mon, 19 Jun 2000 07:25:49 -0700 (PDT) Received: from mshand-8kcdt ([10.49.188.186]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA09847; Mon, 19 Jun 2000 14:55:48 +0100 (BST) Message-Id: <4.2.2.20000619145434.00a864b0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Jun 2000 14:56:44 +0100 To: "Metz, E.T." , isis-wg@external.juniper.net From: Mike Shand Subject: Re: [Isis-wg] Areas in ISIS In-Reply-To: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 15:40 19/06/2000 +0100, Metz, E.T. wrote: >Hi all, > >is it possible to have an ISIS network with different areas, but without an >explicit backbone area? > >I thought it could be done because the L1/L2 routers in each of the areas >will form (L2) adjacencies and exchange routing info. So even without a real >backbone area, traffic will still flow between differents areas. > >Is the above correct? Does it make any sense? Yes, no problem. All that is required is that there is a connected L2 path linking all the areas. In paritcular if areas A and C are connected through area B, there must be a connected path of L2 routers through B. Mike >cheers, > Eduard > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 12:58:00 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14883 for ; Mon, 19 Jun 2000 12:57:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA05964; Mon, 19 Jun 2000 09:54:16 -0700 (PDT) Received: from last-call-3.cisco.com (last-call-3.cisco.com [171.68.200.143]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA05933 for ; Mon, 19 Jun 2000 09:54:14 -0700 (PDT) Received: (from amartey@localhost) by last-call-3.cisco.com (8.8.5/CA/950118) id JAA14568; Mon, 19 Jun 2000 09:43:36 -0700 (PDT) Date: Mon, 19 Jun 2000 09:43:36 -0700 From: Abe Martey To: "Metz, E.T." Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS Message-ID: <20000619094336.E13085@cisco.com> References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com>; from E.T.Metz@kpn.com on Mon, Jun 19, 2000 at 03:40:56PM +0100 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 14:11:40 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19234 for ; Mon, 19 Jun 2000 14:11:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA06114; Mon, 19 Jun 2000 11:05:11 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA06082 for ; Mon, 19 Jun 2000 11:05:09 -0700 (PDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24270; Mon, 19 Jun 2000 10:54:44 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA04946; Mon, 19 Jun 2000 13:54:42 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id NAA01248; Mon, 19 Jun 2000 13:54:41 -0400 (EDT) Message-Id: <200006191754.NAA01248@bcn.East.Sun.COM> Date: Mon, 19 Jun 2000 13:54:40 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Areas in ISIS To: E.T.Metz@kpn.com, amartey@cisco.com Cc: isis-wg@external.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7/A2CNOJ3GD/BUSiwCFYzw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Years ago (like 10) Chris Gunner and I did an internet-draft explaining how a router capable of running multiple instances of IS-IS could be configured to interconnect two areas. It just has to be configured with which ports are in which areas, and which addresses to pass along from one area to another. NLSP did this, and extended the idea with something called "area-hops" which said how many areas you were allowed to learn the address range and pass it along. This allowed interconnecting two areas but not allowing through traffic from other areas (set area-hops to 1), and cut down on the count-to-infinity behavior that could be caused by complex interconnections of areas without a level 2 backbone. This isn't a protocol issue, if you don't add "area-hops". It's solely an implementation issue at the multi-area router. If someone wants to build a router that can do multiple instances of IS-IS and be configured with what to pass between the areas, none of the other routers need to know that this is going on. Radia From: Abe Martey To: "Metz, E.T." Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS Mime-Version: 1.0 X-Mailman-Version: 1.0rc3 List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 16:36:30 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22985 for ; Mon, 19 Jun 2000 16:36:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA06391; Mon, 19 Jun 2000 13:30:55 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA06365 for ; Mon, 19 Jun 2000 13:30:53 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA09065; Mon, 19 Jun 2000 13:19:50 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id NAA02101; Mon, 19 Jun 2000 13:19:50 -0700 (PDT) Date: Mon, 19 Jun 2000 13:19:50 -0700 (PDT) Message-Id: <200006192019.NAA02101@cirrus.juniper.net> From: Dave Katz To: amartey@cisco.com CC: E.T.Metz@kpn.com, isis-wg@external.juniper.net In-reply-to: <20000619094336.E13085@cisco.com> (message from Abe Martey on Mon, 19 Jun 2000 09:43:36 -0700) Subject: Re: [Isis-wg] Areas in ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I fail to see the distinction between what is described and a "physically distinct backbone area." In particular, if there are going to be distinct L1 areas, there must be a contiguous L2 backbone (which could be as small as a single link) to connect the L2 routers. An L1/L2 router is essentially the same thing as an OSPF router with at least one interface in the backbone area and at least one interface in another area. --Dave Date: Mon, 19 Jun 2000 09:43:36 -0700 From: Abe Martey Cc: isis-wg@external.juniper.net References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > Hi all, > > is it possible to have an ISIS network with different areas, but without an > explicit backbone area? Sure! Each router belongs to one area and there is no need for a physically distinct backbone area. The backbone refers to the level-2 routing domain which is a logical area....the group of routers involved in level-2 routing (as you describe below) form the isis backbone...the backbone stretch just has to be contiguous... Cheers. - abe > > I thought it could be done because the L1/L2 routers in each of the areas > will form (L2) adjacencies and exchange routing info. So even without a real > backbone area, traffic will still flow between differents areas. > > Is the above correct? Does it make any sense? > > cheers, > Eduard > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 16:43:38 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23108 for ; Mon, 19 Jun 2000 16:43:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA06482; Mon, 19 Jun 2000 13:37:35 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA06412 for ; Mon, 19 Jun 2000 13:37:31 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA09443; Mon, 19 Jun 2000 13:26:28 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id NAA02110; Mon, 19 Jun 2000 13:26:29 -0700 (PDT) Date: Mon, 19 Jun 2000 13:26:29 -0700 (PDT) Message-Id: <200006192026.NAA02110@cirrus.juniper.net> From: Dave Katz To: mshand@cisco.com CC: E.T.Metz@kpn.com, isis-wg@external.juniper.net In-reply-to: <4.2.2.20000619145434.00a864b0@jaws.cisco.com> (message from Mike Shand on Mon, 19 Jun 2000 14:56:44 +0100) Subject: Re: [Isis-wg] Areas in ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This isn't "physically distinct" in the sense that L1 traffic can traverse some of the same links that make up the L2 topology, but it is important to think of the L2 topology as distinct when you design your network, or you can end up in a world of hurt. In particular, if areas A, B, and C are connected through a loop, and there are parts of area B that depend on those L1L2 links for L1 connectivity, a break of the path through area B could not be healed via A and C. In the topology you describe, I would visualize the L2 path as being on the edge of area B, as it (at least to me) presents the weaknesses of the topology more clearly. --Dave X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Jun 2000 14:56:44 +0100 From: Mike Shand Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 15:40 19/06/2000 +0100, Metz, E.T. wrote: >Hi all, > >is it possible to have an ISIS network with different areas, but without an >explicit backbone area? > >I thought it could be done because the L1/L2 routers in each of the areas >will form (L2) adjacencies and exchange routing info. So even without a real >backbone area, traffic will still flow between differents areas. > >Is the above correct? Does it make any sense? Yes, no problem. All that is required is that there is a connected L2 path linking all the areas. In paritcular if areas A and C are connected through area B, there must be a connected path of L2 routers through B. Mike >cheers, > Eduard > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 18:45:31 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24998 for ; Mon, 19 Jun 2000 18:45:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA06665; Mon, 19 Jun 2000 15:41:23 -0700 (PDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA06633 for ; Mon, 19 Jun 2000 15:41:21 -0700 (PDT) Received: from cisco.com (dhcp-171-71-222-223.cisco.com [171.71.222.223]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA27980; Mon, 19 Jun 2000 15:30:49 -0700 (PDT) Message-ID: <394E9ECD.7838F90A@cisco.com> Date: Mon, 19 Jun 2000 15:29:33 -0700 From: Abe Martey Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz CC: E.T.Metz@kpn.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS References: <200006192019.NAA02101@cirrus.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Dave Katz wrote: > > I fail to see the distinction between what is described and a "physically > distinct backbone area." In particular, if there are going to be distinct > L1 areas, there must be a contiguous L2 backbone (which could be as small > as a single link) to connect the L2 routers. An L1/L2 router is > essentially the same thing as an OSPF router with at least one >interface in the backbone area and at least one interface in another >area. Technically yes...but IS-IS would allow a linear layout of multiple areas whereas OSPF needs all areas touching a _common_ centrally located area 0...unless you wanted to play with virtual links. The IS-IS backbone is not as clearly carved out as the OSPF area 0...a difference probably rooted in ISO node-based addressing vs IP link-based addressing. I'll agree however that in a real network, the IS-IS backbone should be as distinctly carved out as an OSPF backbone.... > > --Dave > > Date: Mon, 19 Jun 2000 09:43:36 -0700 > From: Abe Martey > Cc: isis-wg@external.juniper.net > References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Mailer: Mutt 1.0i > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > > Hi all, > > > > is it possible to have an ISIS network with different areas, but without an > > explicit backbone area? > > Sure! Each router belongs to one area and there is no need for a > physically distinct backbone area. The backbone refers to the level-2 > routing domain which is a logical area....the group of routers involved > in level-2 routing (as you describe below) form the isis backbone...the > backbone stretch just has to be contiguous... > > Cheers. > > - abe > > > > > I thought it could be done because the L1/L2 routers in each of the areas > > will form (L2) adjacencies and exchange routing info. So even without a real > > backbone area, traffic will still flow between differents areas. > > > > Is the above correct? Does it make any sense? > > > > cheers, > > Eduard > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 19:42:20 2000 Received: from external.juniper.net ([208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25655 for ; Mon, 19 Jun 2000 19:42:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA06803; Mon, 19 Jun 2000 16:37:34 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA06771 for ; Mon, 19 Jun 2000 16:37:32 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA25196 for ; Mon, 19 Jun 2000 16:27:06 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id QAA70072 for ; Mon, 19 Jun 2000 16:26:18 -0700 (PDT) (envelope-from Radia.Perlman@East.Sun.COM) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15899; Mon, 19 Jun 2000 16:26:41 -0700 (PDT) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA22896; Mon, 19 Jun 2000 19:26:39 -0400 (EDT) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id TAA03469; Mon, 19 Jun 2000 19:26:39 -0400 (EDT) Message-Id: <200006192326.TAA03469@bcn.East.Sun.COM> Date: Mon, 19 Jun 2000 19:26:38 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit To: rja@inet.org, pkoning@xedia.com Cc: OSPF@DISCUSS.MICROSOFT.COM, ipsec@lists.tislabs.com, isis-wg@juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1acJFXyVZXEgbb4YWyC0xA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Ran, another basic question... What's the threat solved by authenticating the source route header at intermediate points? What would be the problem if a packet showed up at the destination, not having traversed the route you wanted? I'm assuming you're not trying to solve the confidentiality problem by making sure that the packet stays in "friendly" parts of the net, and therefore doesn't need encryption, but if it took a different route it would need encryption. Radia _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 21:08:40 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26479 for ; Mon, 19 Jun 2000 21:08:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA06996; Mon, 19 Jun 2000 18:14:53 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA06966 for ; Mon, 19 Jun 2000 18:14:51 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id SAA13027; Mon, 19 Jun 2000 18:04:28 -0700 (PDT) From: Mike Truskowski Message-Id: <200006200104.SAA13027@diablo.cisco.com> Subject: Re: [Isis-wg] Areas in ISIS To: dkatz@juniper.net (Dave Katz) Date: Mon, 19 Jun 2000 18:04:28 PDT Cc: amartey@cisco.com, E.T.Metz@kpn.com, isis-wg@external.juniper.net In-Reply-To: <200006192019.NAA02101@cirrus.juniper.net>; from "Dave Katz" at Jun 19, 100 1:19 pm X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Sounds to me like you are saying the same things here only in different ways... The difference occurs at the logical layer... an area in OSI is dictated by the nsap while an area in ospf is a logical mapping... OSI backbones can have multiple osi areas while an ospf area 0 is one area with the backbone belonging to it... mike > > I fail to see the distinction between what is described and a "physically > distinct backbone area." In particular, if there are going to be distinct > L1 areas, there must be a contiguous L2 backbone (which could be as small > as a single link) to connect the L2 routers. An L1/L2 router is > essentially the same thing as an OSPF router with at least one interface > in the backbone area and at least one interface in another area. > > --Dave > > Date: Mon, 19 Jun 2000 09:43:36 -0700 > From: Abe Martey > Cc: isis-wg@external.juniper.net > References: <59063B5B4D98D311BC0D0001FA7E452201443790@l04.research.kpn.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Mailer: Mutt 1.0i > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > > On Mon, Jun 19, 2000 at 03:40:56PM +0100, Metz, E.T. wrote: > > Hi all, > > > > is it possible to have an ISIS network with different areas, but without an > > explicit backbone area? > > Sure! Each router belongs to one area and there is no need for a > physically distinct backbone area. The backbone refers to the level-2 > routing domain which is a logical area....the group of routers involved > in level-2 routing (as you describe below) form the isis backbone...the > backbone stretch just has to be contiguous... > > Cheers. > > - abe > > > > > I thought it could be done because the L1/L2 routers in each of the areas > > will form (L2) adjacencies and exchange routing info. So even without a real > > backbone area, traffic will still flow between differents areas. > > > > Is the above correct? Does it make any sense? > > > > cheers, > > Eduard > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 21:17:33 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26568 for ; Mon, 19 Jun 2000 21:17:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA07060; Mon, 19 Jun 2000 18:24:57 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA07031 for ; Mon, 19 Jun 2000 18:24:55 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id SAA21452; Mon, 19 Jun 2000 18:14:31 -0700 (PDT) From: Mike Truskowski Message-Id: <200006200114.SAA21452@diablo.cisco.com> Subject: Re: [Isis-wg] Areas in ISIS To: dkatz@juniper.net (Dave Katz) Date: Mon, 19 Jun 2000 18:14:31 PDT Cc: mshand@cisco.com, E.T.Metz@kpn.com, isis-wg@external.juniper.net In-Reply-To: <200006192026.NAA02110@cirrus.juniper.net>; from "Dave Katz" at Jun 19, 100 1:26 pm X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I think that you are saying that if you build heirarchically then OSPF and ISIS topologies are the same... AREA0 is equivalent to all those L2 adjacencies... And I agree...but the difference is shown by a little different topology... In ospf, if A is the area0 and B and C are cascading with a virtual link from C to A.. then all traffic from C to B goes thru A... But in ISIS with A being L2/L1 cascaded to B cascaded to C as in above... with L2 connectivity to from A thru B to C, then traffic from C to B merely goes directly to B and never is seen by A... As long as the "loop" is never completed then the topology is fine... The major weakness I see with ISIS in this sense is that a L1 instance must choose the "closest" L2 router which may not be the best L2. Mike > > This isn't "physically distinct" in the sense that L1 traffic can traverse > some of the same links that make up the L2 topology, but it is important > to think of the L2 topology as distinct when you design your network, or > you can end up in a world of hurt. In particular, if areas A, B, and C > are connected through a loop, and there are parts of area B that depend > on those L1L2 links for L1 connectivity, a break of the path through > area B could not be healed via A and C. > > In the topology you describe, I would visualize the L2 path as being > on the edge of area B, as it (at least to me) presents the weaknesses > of the topology more clearly. > > > --Dave > > X-Sender: mshand@jaws.cisco.com > X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 > Date: Mon, 19 Jun 2000 14:56:44 +0100 > From: Mike Shand > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > Sender: isis-wg-admin@external.juniper.net > Errors-To: isis-wg-admin@external.juniper.net > X-Mailman-Version: 1.0rc3 > Precedence: bulk > List-Id: IETF IS-IS working group > X-BeenThere: isis-wg@external.juniper.net > > At 15:40 19/06/2000 +0100, Metz, E.T. wrote: > >Hi all, > > > >is it possible to have an ISIS network with different areas, but without an > >explicit backbone area? > > > >I thought it could be done because the L1/L2 routers in each of the areas > >will form (L2) adjacencies and exchange routing info. So even without a real > >backbone area, traffic will still flow between differents areas. > > > >Is the above correct? Does it make any sense? > > Yes, no problem. All that is required is that there is a connected L2 path > linking all the areas. In paritcular if areas A and C are connected through > area B, there must be a connected path of L2 routers through B. > > Mike > > > > >cheers, > > Eduard > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 19 22:34:56 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29089 for ; Mon, 19 Jun 2000 22:34:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA07206; Mon, 19 Jun 2000 19:42:36 -0700 (PDT) Received: from MailGate.Adtech-Inc.COM (smtp.adtech-inc.com [192.216.50.164]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA07179 for ; Mon, 19 Jun 2000 19:42:29 -0700 (PDT) Received: from mgmgrand.adtech-inc.com (Trans_Exchange.Adtech-Inc.COM [192.216.50.163]) by MailGate.Adtech-Inc.COM (8.10.0/8.10.0) with ESMTP id e5K2ZT229896 for ; Mon, 19 Jun 2000 16:35:30 -1000 (HST) Received: by mgmgrand.adtech-inc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Jun 2000 16:31:58 -1000 Message-ID: From: "Nava.Zvaig" To: isis-wg@external.juniper.net Date: Mon, 19 Jun 2000 16:31:57 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDA5F.B4BB817E" Subject: [Isis-wg] ISIS code Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDA5F.B4BB817E Content-Type: text/plain; charset="iso-8859-1" Is there any software/shareware/freeware available for ISIS and ISIS-TE? TIA, Nava ------_=_NextPart_001_01BFDA5F.B4BB817E Content-Type: text/html; charset="iso-8859-1" ISIS code

Is there any software/shareware/freeware available for ISIS and ISIS-TE?

TIA,
Nava

------_=_NextPart_001_01BFDA5F.B4BB817E-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 20 03:13:39 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14623 for ; Tue, 20 Jun 2000 03:13:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA07514; Tue, 20 Jun 2000 00:20:59 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA07482 for ; Tue, 20 Jun 2000 00:20:57 -0700 (PDT) Received: from mshand-8kcdt ([10.49.188.186]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA08000; Tue, 20 Jun 2000 08:10:01 +0100 (BST) Message-Id: <4.2.2.20000620075103.00ae7950@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 20 Jun 2000 08:02:19 +0100 To: Dave Katz From: Mike Shand Subject: Re: [Isis-wg] Areas in ISIS Cc: E.T.Metz@kpn.com, isis-wg@external.juniper.net In-Reply-To: <200006192026.NAA02110@cirrus.juniper.net> References: <4.2.2.20000619145434.00a864b0@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 13:26 19/06/2000 -0700, Dave Katz wrote: >This isn't "physically distinct" in the sense that L1 traffic can traverse >some of the same links that make up the L2 topology, but it is important >to think of the L2 topology as distinct when you design your network, or >you can end up in a world of hurt. In particular, if areas A, B, and C >are connected through a loop, and there are parts of area B that depend >on those L1L2 links for L1 connectivity, a break of the path through >area B could not be healed via A and C. > >In the topology you describe, I would visualize the L2 path as being >on the edge of area B, as it (at least to me) presents the weaknesses >of the topology more clearly. Dave, I couldn't agree more. The difference between IS-IS and OSPF is not primarily one of network design, but one of nomenclature. i.e. in IS-IS you still need to design a 'backbone', but the backbone isn't named as a single area (0) as it is in OSPF. In fact it isn't named at all. Its just defined by the connected set of L2 routers. In some designs that will correspond to a single L1 area, but in others it may traverse (or as you rightly point out ,it is better to think of it as skirting around the edge of) multiple L1 areas. Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 20 14:17:00 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00926 for ; Tue, 20 Jun 2000 14:16:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA08315; Tue, 20 Jun 2000 11:24:45 -0700 (PDT) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA08287 for ; Tue, 20 Jun 2000 11:24:42 -0700 (PDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JQU74IDGS20004BO@research.kpn.com> for isis-wg@external.juniper.net; Tue, 20 Jun 2000 20:14:12 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 20:14:12 +0100 Content-return: allowed Date: Tue, 20 Jun 2000 20:14:11 +0100 From: "Metz, E.T." Subject: RE: [Isis-wg] Areas in ISIS To: Dave Katz , "'Mike Shand'" , "'truskows@cisco.com'" Cc: E.T.Metz@kpn.com, isis-wg@external.juniper.net Message-id: <59063B5B4D98D311BC0D0001FA7E45220144379F@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Thanks for the clarifications ... As for the situation I was thinking of, this was indeed the case where you have multiple areas and the backbone is formed of the "edges" of the areas and the links between the areas. I didn't really think of a "chain" of areas, the loop issue is although interesting. I like the concept of this "virtual backbone" is ISIS, although in (re)designing networks you'll probably have to clearly keep in mind to keep the backbone contiguos and avoid chains (loops) of areas. While in OSPF this is more or less forced upon th designer due to the explicit area 0 that has to present, and to which all other areas should connect. cheers, Eduard ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would it? It needs to be L2 or L1/L2 at least. > ---------- > From: Mike Shand[SMTP:mshand@cisco.com] > Sent: dinsdag 20 juni 2000 9:02 > To: Dave Katz > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > Subject: Re: [Isis-wg] Areas in ISIS > > At 13:26 19/06/2000 -0700, Dave Katz wrote: > >This isn't "physically distinct" in the sense that L1 traffic can > traverse > >some of the same links that make up the L2 topology, but it is important > >to think of the L2 topology as distinct when you design your network, or > >you can end up in a world of hurt. In particular, if areas A, B, and C > >are connected through a loop, and there are parts of area B that depend > >on those L1L2 links for L1 connectivity, a break of the path through > >area B could not be healed via A and C. > > > >In the topology you describe, I would visualize the L2 path as being > >on the edge of area B, as it (at least to me) presents the weaknesses > >of the topology more clearly. > > Dave, > I couldn't agree more. The difference between IS-IS and OSPF is > not primarily one of network design, but one of nomenclature. i.e. in > IS-IS > you still need to design a 'backbone', but the backbone isn't named as a > single area (0) as it is in OSPF. In fact it isn't named at all. Its just > defined by the connected set of L2 routers. In some designs that will > correspond to a single L1 area, but in others it may traverse (or as you > rightly point out ,it is better to think of it as skirting around the edge > > of) multiple L1 areas. > > Mike > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 20 14:37:39 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01312 for ; Tue, 20 Jun 2000 14:37:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA08395; Tue, 20 Jun 2000 11:45:01 -0700 (PDT) Received: from jaws.cisco.com (jaws.cisco.com [198.135.0.150]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA08361 for ; Tue, 20 Jun 2000 11:44:59 -0700 (PDT) Received: from mshand-8kcdt ([10.49.188.186]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA07125; Tue, 20 Jun 2000 19:34:15 +0100 (BST) Message-Id: <4.2.2.20000620193007.00c80ef0@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 20 Jun 2000 19:34:48 +0100 To: "Metz, E.T." , Dave Katz , "'truskows@cisco.com'" From: Mike Shand Subject: RE: [Isis-wg] Areas in ISIS Cc: E.T.Metz@kpn.com, isis-wg@external.juniper.net In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220144379F@l04.research.kpn. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net At 20:14 20/06/2000 +0100, Metz, E.T. wrote: >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would >it? It needs to be L2 or L1/L2 at least. Were running into terminological inexactitudes here :-) Yes it does need to be L2, but one way of designing an IS-IS network is to make an area of L1/L2 routers which constitutes the backbone and then hang all the other areas off this one. Of course you need at least one L1/L2 router in each of those areas, so the backbone (in the sense we were talking before, i.e. the set of connected L2 routers - or the distribution domain of L2 LSPs) spans multiple areas. But it does look rather like the OSPF case, where the backbone is a single area (0 in that case). Mike (S) _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 20 14:53:21 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01597 for ; Tue, 20 Jun 2000 14:53:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA08465; Tue, 20 Jun 2000 12:01:11 -0700 (PDT) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA08438 for ; Tue, 20 Jun 2000 12:01:09 -0700 (PDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JQU8EOVU940004BO@research.kpn.com> for isis-wg@external.juniper.net; Tue, 20 Jun 2000 20:50:39 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Jun 2000 20:50:39 +0100 Content-return: allowed Date: Tue, 20 Jun 2000 20:50:38 +0100 From: "Metz, E.T." Subject: RE: [Isis-wg] Areas in ISIS To: "Metz, E.T." , Dave Katz , "'truskows@cisco.com'" , "'Mike Shand'" Cc: E.T.Metz@kpn.com, isis-wg@external.juniper.net Message-id: <59063B5B4D98D311BC0D0001FA7E4522014437A3@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Small question (related to below), if you do create a separate backbone (physically, or at least similar to OSPF area 0), is it then needed or advantagous to have L1 routing in this area. Instead of just L2? cheers, Eduard > ---------- > From: Mike Shand[SMTP:mshand@cisco.com] > Sent: dinsdag 20 juni 2000 20:34 > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > Subject: RE: [Isis-wg] Areas in ISIS > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > would > >it? It needs to be L2 or L1/L2 at least. > > Were running into terminological inexactitudes here :-) > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > make an area of L1/L2 routers which constitutes the backbone and then hang > > all the other areas off this one. Of course you need at least one L1/L2 > router in each of those areas, so the backbone (in the sense we were > talking before, i.e. the set of connected L2 routers - or the distribution > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > OSPF case, where the backbone is a single area (0 in that case). > > Mike (S) > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 21 12:11:54 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06001 for ; Wed, 21 Jun 2000 12:11:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA09734; Wed, 21 Jun 2000 09:15:56 -0700 (PDT) Received: from last-call-5.cisco.com (last-call-5.cisco.com [171.68.200.84]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA09706 for ; Wed, 21 Jun 2000 09:15:54 -0700 (PDT) Received: (from amartey@localhost) by last-call-5.cisco.com (8.8.5/CA/950118) id JAA26579; Wed, 21 Jun 2000 09:05:14 -0700 (PDT) Date: Wed, 21 Jun 2000 09:05:14 -0700 From: Abe Martey To: "Metz, E.T." Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS Message-ID: <20000621090514.C25954@cisco.com> References: <59063B5B4D98D311BC0D0001FA7E4522014437A3@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522014437A3@l04.research.kpn.com>; from E.T.Metz@kpn.com on Tue, Jun 20, 2000 at 08:50:38PM +0100 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > Small question (related to below), if you do create a separate backbone > (physically, or at least similar to OSPF area 0), is it then needed or > advantagous to have L1 routing in this area. Instead of just L2? You could have a physical area x designated as the "core" of the backbone..and all routers in this area don't have to run L1. Actually they shouldn't since it'll be a resource waste....however your "true" isis backbone will extend to the L1L2 border routers of the various other areas. [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] |---area 1----| |--area x---| |----Area 2----| |----------isis backbone-----------| Cheers. - abe > > cheers, > Eduard > > > ---------- > > From: Mike Shand[SMTP:mshand@cisco.com] > > Sent: dinsdag 20 juni 2000 20:34 > > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > > Subject: RE: [Isis-wg] Areas in ISIS > > > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > > would > > >it? It needs to be L2 or L1/L2 at least. > > > > Were running into terminological inexactitudes here :-) > > > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > > > make an area of L1/L2 routers which constitutes the backbone and then hang > > > > all the other areas off this one. Of course you need at least one L1/L2 > > router in each of those areas, so the backbone (in the sense we were > > talking before, i.e. the set of connected L2 routers - or the distribution > > > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > > OSPF case, where the backbone is a single area (0 in that case). > > > > Mike (S) > > > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ==.==.==.==.== Abe Martey San Jose, CA 408 527 9149 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed Jun 21 12:48:55 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08091 for ; Wed, 21 Jun 2000 12:48:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA09823; Wed, 21 Jun 2000 09:54:53 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA09796 for ; Wed, 21 Jun 2000 09:54:51 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id JAA29066; Wed, 21 Jun 2000 09:44:15 -0700 (PDT) From: Mike Truskowski Message-Id: <200006211644.JAA29066@diablo.cisco.com> Subject: Re: [Isis-wg] Areas in ISIS To: amartey@cisco.com (Abe Martey) Date: Wed, 21 Jun 2000 9:44:15 PDT Cc: E.T.Metz@kpn.com, isis-wg@external.juniper.net In-Reply-To: <20000621090514.C25954@cisco.com>; from "Abe Martey" at Jun 21, 100 9:05 am X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Ugh... I think this might be a little confusing.... No doubt that this will work but ... Area X "must" have a contiguous space of L2 or L2/L1 connected to each Area N... In other words, Assuming that the Area N's are only connected thru Area X, then there must be a set of L2 instances w/i area X that connect Area N to Area M.... Hence, the L2(/L1) routers in area X and the L1/L2 routers in Area N form the backbone... The L1's are not part of the backbone. The L2's are analogus to ospf's area 0. Not the L1's. Personally, I try to stay far away from this. mike > > > > On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > > Small question (related to below), if you do create a separate backbone > > (physically, or at least similar to OSPF area 0), is it then needed or > > advantagous to have L1 routing in this area. Instead of just L2? > > You could have a physical area x designated as the "core" of the > backbone..and all routers in this area don't have to run L1. Actually > they shouldn't since it'll be a resource waste....however your > "true" isis backbone will extend to the L1L2 border routers of the > various other areas. > > [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > > |---area 1----| |--area x---| |----Area 2----| > |----------isis backbone-----------| > > > Cheers. > > - abe > > > > > cheers, > > Eduard > > > > > ---------- > > > From: Mike Shand[SMTP:mshand@cisco.com] > > > Sent: dinsdag 20 juni 2000 20:34 > > > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > > > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > > > Subject: RE: [Isis-wg] Areas in ISIS > > > > > > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > > > would > > > >it? It needs to be L2 or L1/L2 at least. > > > > > > Were running into terminological inexactitudes here :-) > > > > > > Yes it does need to be L2, but one way of designing an IS-IS network is to > > > > > > make an area of L1/L2 routers which constitutes the backbone and then hang > > > > > > all the other areas off this one. Of course you need at least one L1/L2 > > > router in each of those areas, so the backbone (in the sense we were > > > talking before, i.e. the set of connected L2 routers - or the distribution > > > > > > domain of L2 LSPs) spans multiple areas. But it does look rather like the > > > OSPF case, where the backbone is a single area (0 in that case). > > > > > > Mike (S) > > > > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > -- > > > ==.==.==.==.== > Abe Martey > San Jose, CA > 408 527 9149 > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 10:10:12 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11169 for ; Fri, 23 Jun 2000 10:10:10 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA13283; Fri, 23 Jun 2000 07:16:57 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA13256 for ; Fri, 23 Jun 2000 07:16:54 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id HAA18774 for ; Fri, 23 Jun 2000 07:06:05 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id HAA42614; Fri, 23 Jun 2000 07:05:05 -0700 (PDT) (envelope-from jparker@nexabit.com) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA17693; Fri, 23 Jun 2000 10:08:07 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Jun 2000 10:06:00 -0400 Message-ID: From: Jeff Parker To: Kireeti Kompella , swallow@cisco.com Cc: mpls@UU.NET, isis-wg@juniper.net Date: Fri, 23 Jun 2000 10:05:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > Folks, > > Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt > be accepted as a work group document. So far I've only seen support. > If there are no objects by 6/27, we'll declare it so. > > ...George I find this draft a useful addition to the discussion of TE, and would support it's adoption as an MPLS group document. However, I am a bit puzzled by the last paragraph before section 4.3 (bottom of page 5). "Route computation procedures should not perform two-way connectivity check on the links used by the procedures. That is, the two way check should not be performed on one-way pipes, as they will fail." I agree that relaxing this test for one-way links is a Good Thing. But looking at the aged out draft "IS-IS extensions for Traffic Engineering" I don't understand how we distinguish "forward adjacencies" that are unidirectional LSPs from point-to-point adjacencies, where we should retain the test. Perhaps this will be addressed in the next rev of the IS-IS TE doc. - jeff parker - Lucent Technologies _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 17:53:38 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20125 for ; Fri, 23 Jun 2000 17:53:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA13816; Fri, 23 Jun 2000 15:01:17 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA13752 for ; Fri, 23 Jun 2000 15:01:14 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA20181 for ; Fri, 23 Jun 2000 14:50:23 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id OAA52210; Fri, 23 Jun 2000 14:49:20 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id C29E72AA1D; Fri, 23 Jun 2000 14:50:16 -0700 (PDT) To: Tony Przygienda Cc: Jeff Parker , Kireeti Kompella , swallow@cisco.com, mpls@UU.NET, isis-wg@juniper.net Subject: Re: [Isis-wg] RE: LSP hierarchy with MPLS TE In-reply-to: Mail from Tony Przygienda dated Fri, 23 Jun 2000 11:07:19 PDT <3953A756.996F26F1@redback.com> Date: Fri, 23 Jun 2000 14:49:29 -0700 From: Naiming Shen Message-Id: <20000623215016.C29E72AA1D@postal.redback.com> Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net don't want to speak for the authors, but the difference from a disabled TE link is that this LSP link has a usable TE metric set. this hierarchy scheme is independent of LSP bundling, you can announce and set different metric on different LSPs the same source/dest pair. so i don't see why the Mux TLV should be required. an interesting question is how do you set the link metric to be max(1, (the TE metric of the FA-LSP path) - 1)? something like the one mentioned in an expired draft:-) thanks. ]Naiming Shen wrote: ] ]> I think you can use the cue which normal IS-IS ignores this type of ]> links, which is the links are having the default metric of (2^24 - 1). ] ]there is a chance to confuse that with a disabled TE link of course. ]Also (although that's minor) it's a disadvantage that if i choose not to ]support LSP bundling. I'd loose control about which of the forwarding ]adjacencies other LSRs prefer based on admin metric. ] ]It seems to me much wiser to use the presence of the Link Mux Capability sub- TLV ]as indication that only a one-way check is necessary. I assume that ]sub-TLV is mandatory on forwarding adjacencies, the draft is not 100% ]clear about that one. ] ] any clarification from the authors ? ] ] -- tony ] ] ]> ]> ]> ]> Folks, ]> ]> ]> ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.t xt ]> ]> be accepted as a work group document. So far I've only seen support. ]> ]> If there are no objects by 6/27, we'll declare it so. ]> ]> ]> ]> ...George ]> ] ]> ]I find this draft a useful addition to the discussion of TE, and would ]> ]support it's adoption as an MPLS group document. ]> ] ]> ]However, I am a bit puzzled by the last paragraph before ]> ]section 4.3 (bottom of page 5). ]> ] ]> ] "Route computation procedures should not perform two-way ]> ] connectivity check on the links used by the procedures. ]> ] That is, the two way check should not be performed on ]> ] one-way pipes, as they will fail." ]> ] ]> ]I agree that relaxing this test for one-way links is a Good Thing. But ]> ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" ]> ] I don't understand how we distinguish ]> ]"forward adjacencies" that are unidirectional LSPs from point-to-point ]> ]adjacencies, where we should retain the test. ]> ] ]> ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. ]> ] ] ] ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 19:57:54 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23025 for ; Fri, 23 Jun 2000 19:57:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA13980; Fri, 23 Jun 2000 17:03:42 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA13380 for ; Fri, 23 Jun 2000 08:39:29 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA22734 for ; Fri, 23 Jun 2000 08:28:40 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id IAA44133; Fri, 23 Jun 2000 08:27:38 -0700 (PDT) (envelope-from naiming@redback.com) Received: from redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 526552AA04; Fri, 23 Jun 2000 08:28:30 -0700 (PDT) To: Jeff Parker Cc: Kireeti Kompella , swallow@cisco.com, mpls@UU.NET, isis-wg@juniper.net Subject: Re: [Isis-wg] RE: LSP hierarchy with MPLS TE In-reply-to: Mail from Jeff Parker dated Fri, 23 Jun 2000 10:05:59 EDT Date: Fri, 23 Jun 2000 08:27:43 -0700 From: Naiming Shen Message-Id: <20000623152830.526552AA04@postal.redback.com> Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I think you can use the cue which normal IS-IS ignores this type of links, which is the links are having the default metric of (2^24 - 1). ]> Folks, ]> ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt ]> be accepted as a work group document. So far I've only seen support. ]> If there are no objects by 6/27, we'll declare it so. ]> ]> ...George ] ]I find this draft a useful addition to the discussion of TE, and would ]support it's adoption as an MPLS group document. ] ]However, I am a bit puzzled by the last paragraph before ]section 4.3 (bottom of page 5). ] ] "Route computation procedures should not perform two-way ] connectivity check on the links used by the procedures. ] That is, the two way check should not be performed on ] one-way pipes, as they will fail." ] ]I agree that relaxing this test for one-way links is a Good Thing. But ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" ] I don't understand how we distinguish ]"forward adjacencies" that are unidirectional LSPs from point-to-point ]adjacencies, where we should retain the test. ] ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. ] ]- jeff parker ]- Lucent Technologies ] ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 19:58:43 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23058 for ; Fri, 23 Jun 2000 19:58:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA14052; Fri, 23 Jun 2000 17:03:47 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13569 for ; Fri, 23 Jun 2000 11:11:28 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA04347 for ; Fri, 23 Jun 2000 11:00:38 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id KAA47704; Fri, 23 Jun 2000 10:59:35 -0700 (PDT) (envelope-from prz@redback.com) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by postal.redback.com (Postfix) with ESMTP id 1289E2AA2D; Fri, 23 Jun 2000 11:00:31 -0700 (PDT) Message-ID: <3953A756.996F26F1@redback.com> Date: Fri, 23 Jun 2000 11:07:19 -0700 From: Tony Przygienda Organization: Siara Systems X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Naiming Shen Cc: Jeff Parker , Kireeti Kompella , swallow@cisco.com, mpls@UU.NET, isis-wg@juniper.net Subject: Re: [Isis-wg] RE: LSP hierarchy with MPLS TE References: <20000623152830.526552AA04@postal.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Naiming Shen wrote: > I think you can use the cue which normal IS-IS ignores this type of > links, which is the links are having the default metric of (2^24 - 1). there is a chance to confuse that with a disabled TE link of course. Also (although that's minor) it's a disadvantage that if i choose not to support LSP bundling. I'd loose control about which of the forwarding adjacencies other LSRs prefer based on admin metric. It seems to me much wiser to use the presence of the Link Mux Capability sub-TLV as indication that only a one-way check is necessary. I assume that sub-TLV is mandatory on forwarding adjacencies, the draft is not 100% clear about that one. any clarification from the authors ? -- tony > > > ]> Folks, > ]> > ]> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt > ]> be accepted as a work group document. So far I've only seen support. > ]> If there are no objects by 6/27, we'll declare it so. > ]> > ]> ...George > ] > ]I find this draft a useful addition to the discussion of TE, and would > ]support it's adoption as an MPLS group document. > ] > ]However, I am a bit puzzled by the last paragraph before > ]section 4.3 (bottom of page 5). > ] > ] "Route computation procedures should not perform two-way > ] connectivity check on the links used by the procedures. > ] That is, the two way check should not be performed on > ] one-way pipes, as they will fail." > ] > ]I agree that relaxing this test for one-way links is a Good Thing. But > ]looking at the aged out draft "IS-IS extensions for Traffic Engineering" > ] I don't understand how we distinguish > ]"forward adjacencies" that are unidirectional LSPs from point-to-point > ]adjacencies, where we should retain the test. > ] > ]Perhaps this will be addressed in the next rev of the IS-IS TE doc. > ] _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 19:58:48 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23068 for ; Fri, 23 Jun 2000 19:58:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA14086; Fri, 23 Jun 2000 17:03:49 -0700 (PDT) Received: from red.juniper.net (ns1.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA03339 for ; Sat, 17 Jun 2000 14:14:26 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA20326 for ; Sat, 17 Jun 2000 14:04:19 -0700 (PDT) Received: from mailhost.metro-optix.com (mail.metro-optix.com [63.91.47.254]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id OAA45526 for ; Sat, 17 Jun 2000 14:03:36 -0700 (PDT) (envelope-from david.wang@metro-optix.com) Received: by MAILHOST.metro-optix.com with Internet Mail Service (5.5.2650.21) id ; Sat, 17 Jun 2000 16:04:27 -0500 Message-ID: From: David Wang To: "'isis-wg@juniper.net'" Date: Sat, 17 Jun 2000 16:04:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Basic Question about IS-IS Routing protocol Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Dear Friends, I need to learn some basics of IS-IS routing protocol and how it works in IP environment. I cannot find a book, a tutorial or a white paper. 1. Can somebody recommend me some book or tutorial or a white papers? 2. Who is running CLNP instead of IP in their network beside SONET network management software? Can I learn IS-IS with touch CLNP? 3. What is the major difference between IS-IS and OSPF? 4. When use IS-IS to route IP packets the Link State Advertisement packets are also IP packets. People don't have to worry about the OSI CLNP protocol in IP environment. Is this correct? 5. Any other comment and information about IS-IS protocol. Thanks for your help David _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 20:09:51 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23026 for ; Fri, 23 Jun 2000 19:57:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA14015; Fri, 23 Jun 2000 17:03:44 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA13508 for ; Fri, 23 Jun 2000 10:21:44 -0700 (PDT) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA00739; Fri, 23 Jun 2000 10:10:42 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA05765; Fri, 23 Jun 2000 10:10:36 -0700 (PDT) Date: Fri, 23 Jun 2000 10:10:36 -0700 (PDT) From: Kireeti Kompella Message-Id: <200006231710.KAA05765@kummer.juniper.net> To: jparker@nexabit.com, kireeti@juniper.net, swallow@cisco.com Cc: isis-wg@juniper.net, mpls@UU.NET Subject: [Isis-wg] RE: LSP hierarchy with MPLS TE Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi Jeff, > I find this draft a useful addition to the discussion of TE, and would > support it's adoption as an MPLS group document. Thanks! > However, I am a bit puzzled by the last paragraph before > section 4.3 (bottom of page 5). > "Route computation procedures should not perform two-way > connectivity check on the links used by the procedures. > That is, the two way check should not be performed on > one-way pipes, as they will fail." Here's the deal: if you have a unidirectional FA-LSP from A to B, but no LSP from B to A, and you want to compute a _TE_ path for another LSP to tunnel over the FA-LSP, the two-way check will not allow the FA-LSP to be used. Hence the above statement. > I agree that relaxing this test for one-way links is a Good Thing. Note that for CSPF (i.e., TE path) computation, discarding the two-way check will not cause routing loops. However, it's trivial to come up with an example where if a router doesn't do the two-way check for 'regular' SPF but other routers do, you will get permanent routing loops. Yes, it might be a Good Thing to eventually relax the two-way check for regular SPF as well, but that would take much more work. > looking at the aged out draft "IS-IS extensions for Traffic Engineering" > I don't understand how we distinguish > "forward adjacencies" that are unidirectional LSPs from point-to-point > adjacencies, where we should retain the test. Forwarding adjacencies are (almost) indistinguishable from point-to-point links. However, the distinction we're making is CSPF vs. regular SPF, not FAs vs. p2p links. For *all* CSPF computations, we recommend not doing the two-way check. For all SPF computations, we _highly_ recommend doing the two-way check (for fear of routing loops) until such time that there is means to achieve consensus among *all* the routers in an ISIS level/OSPF area not to do the two-way check. Kireeti. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jun 23 20:23:37 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23364 for ; Fri, 23 Jun 2000 20:23:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA14245; Fri, 23 Jun 2000 17:30:13 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [172.17.28.10]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA14218 for ; Fri, 23 Jun 2000 17:30:11 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns4.juniper.net [172.24.240.28]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA28699 for ; Fri, 23 Jun 2000 17:19:19 -0700 (PDT) Received: from tcb.net (tcb.net [205.168.100.1]) by colo-rojo.jnpr.net (8.9.3/8.9.3) with ESMTP id RAA54379 for ; Fri, 23 Jun 2000 17:18:18 -0700 (PDT) (envelope-from danny@sofos.tcb.net) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id SAA20745 for ; Fri, 23 Jun 2000 18:20:22 -0600 Message-Id: <200006240020.SAA20745@tcb.net> X-Mailer: exmh version 2.0.3 To: "'isis-wg@juniper.net'" From: Danny McPherson Reply-To: danny@tcb.net Subject: Re: [Isis-wg] Basic Question about IS-IS Routing protocol Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jun 2000 18:20:22 -0600 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > 1. Can somebody recommend me some book or tutorial or a white papers? Radia Perlman's "Interconnections, Second Edition" is the most useful book I'm aware of. > 2. Who is running CLNP instead of IP in their network beside SONET network > management software? Can I learn IS-IS with touch CLNP? Yes, as CLNS traffic forwarding isn't required (though OSI stack support is per IS-IS packet maintain their original format). IP-only IS-IS is actually the most common implementation of IS-IS today in IP routers (most don't support CLNS traffic forwarding). For IP-only IS-IS, the only OSIish thing you need is NSAP, which is used to determine the routers area and give it a system ID. > 3. What is the major difference between IS-IS and OSPF? The primary difference is that OSPF is an "open standard protocol", was designed expressly for IP, and runs on top of IP. IS-IS was initially designed to support CLNP, then extended to support IP as well. There are lots of other differences, though I'd rather not trigger yet another debate on them. Consulting the MPLS WG mailing list archives, and perhaps the NANOG archives (www.nanog.org) should yield some useful information. > 4. When use IS-IS to route IP packets the Link State Advertisement packets > are also IP packets. People don't have to worry about the OSI CLNP protocol > in IP environment. Is this correct? No. IS-IS LSPs (somewhat synonymous to OSPF LS Updates) contain TLVs that describe IP or CLNP. The encapsulation remains the same and OSI stack support is required. Though again, forwarding capability necessarily isn't. > 5. Any other comment and information about IS-IS protocol. ISO10589 & RFC 1195 may provide some useful information. The OSPF RFC(s) contain a nice "tutorial" on LS routing and the like. -danny _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 26 13:31:09 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11620 for ; Mon, 26 Jun 2000 13:31:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA19537; Mon, 26 Jun 2000 10:36:49 -0700 (PDT) Received: from one.com ([208.169.220.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA19508 for ; Mon, 26 Jun 2000 10:36:46 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e5QHPYw28842 for ; Mon, 26 Jun 2000 13:25:34 -0400 (EDT) Message-Id: <3.0.1.32.20000626121837.01319340@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 26 Jun 2000 12:18:37 -0400 To: isis-wg@external.juniper.net From: Jeff Learman Subject: RE: [Isis-wg] Areas in ISIS In-Reply-To: <59063B5B4D98D311BC0D0001FA7E45220144379F@l04.research.kpn. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net It's not important to avoid loops of areas. This does not contradict what Mike Shand said. Another way to think of it is that, for robustness, you want to make sure that your backbone is constructed in a way so that no single link or router failure could partition the backbone. Likewise, each area should be constructed so that no single link or router failure can partition the area. In Mike's example, the backbone wouldn't be partitioned, but the area would. As Mike says, you need to carefully plan the toplogy of your "Level 2 subdomain", as it's called in ISO 10589, just as you carefully plan the topology of each area. When showing a graphic of the whole topology, it's usually a good idea to render the L2 links in a special color, so that it jumps out even though it's not physically separate from the rest of the network. Of course, this highlighting is unnecessary if you always plan an "Area 0" containing most (but not all!) of your Level 2 backbone. The rest of the L2 backbone would be the one-hop links from the Area 0 routers to the L2 routers in the other areas. For robustness, you would want at least two L2 routers in each area, each with its own link to a different router in Area 0. But as soon as you depart from this plan (by chaining subtended areas, for example), then you need to look at your L2 backbone and make sure it is contiguous (even in the event of a link or router failure). Regards, Jeff At 08:14 PM 6/20/00 +0100, you wrote: > >Thanks for the clarifications ... > >As for the situation I was thinking of, this was indeed the case where you >have multiple areas and the backbone is formed of the "edges" of the areas >and the links between the areas. I didn't really think of a "chain" of >areas, the loop issue is although interesting. > >I like the concept of this "virtual backbone" is ISIS, although in >(re)designing networks you'll probably have to clearly keep in mind to keep >the backbone contiguos and avoid chains (loops) of areas. While in OSPF this >is more or less forced upon th designer due to the explicit area 0 that has >to present, and to which all other areas should connect. > >cheers, > Eduard > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would >it? It needs to be L2 or L1/L2 at least. > >> ---------- >> From: Mike Shand[SMTP:mshand@cisco.com] >> Sent: dinsdag 20 juni 2000 9:02 >> To: Dave Katz >> Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net >> Subject: Re: [Isis-wg] Areas in ISIS >> >> At 13:26 19/06/2000 -0700, Dave Katz wrote: >> >This isn't "physically distinct" in the sense that L1 traffic can >> traverse >> >some of the same links that make up the L2 topology, but it is important >> >to think of the L2 topology as distinct when you design your network, or >> >you can end up in a world of hurt. In particular, if areas A, B, and C >> >are connected through a loop, and there are parts of area B that depend >> >on those L1L2 links for L1 connectivity, a break of the path through >> >area B could not be healed via A and C. >> > >> >In the topology you describe, I would visualize the L2 path as being >> >on the edge of area B, as it (at least to me) presents the weaknesses >> >of the topology more clearly. >> >> Dave, >> I couldn't agree more. The difference between IS-IS and OSPF is >> not primarily one of network design, but one of nomenclature. i.e. in >> IS-IS >> you still need to design a 'backbone', but the backbone isn't named as a >> single area (0) as it is in OSPF. In fact it isn't named at all. Its just >> defined by the connected set of L2 routers. In some designs that will >> correspond to a single L1 area, but in others it may traverse (or as you >> rightly point out ,it is better to think of it as skirting around the edge >> >> of) multiple L1 areas. >> >> Mike >> >> >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg >> > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 26 13:31:22 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11630 for ; Mon, 26 Jun 2000 13:31:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA19567; Mon, 26 Jun 2000 10:37:07 -0700 (PDT) Received: from one.com ([208.169.220.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA19541 for ; Mon, 26 Jun 2000 10:37:05 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e5QHPZw28846; Mon, 26 Jun 2000 13:25:35 -0400 (EDT) Message-Id: <3.0.1.32.20000626122211.0132b100@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 26 Jun 2000 12:22:11 -0400 To: Abe Martey From: Jeff Learman Subject: Re: [Isis-wg] Areas in ISIS Cc: "Metz, E.T." , isis-wg@external.juniper.net In-Reply-To: <20000621090514.C25954@cisco.com> References: <59063B5B4D98D311BC0D0001FA7E4522014437A3@l04.research.kpn.com> <59063B5B4D98D311BC0D0001FA7E4522014437A3@l04.research.kpn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net For CLNP, you would need to run L1 as well as L2. Otherwise, you wouldn't be able to manage the routers in Area 0. When a packet arrives in Area 0, the L1 FDB would be consulted, but would be empty or missing, causing the packet to be dropped. I suspect the same might be true for IP traffic. At 09:05 AM 6/21/00 -0700, Abe Martey wrote: > > >On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: >> Small question (related to below), if you do create a separate backbone >> (physically, or at least similar to OSPF area 0), is it then needed or >> advantagous to have L1 routing in this area. Instead of just L2? > >You could have a physical area x designated as the "core" of the >backbone..and all routers in this area don't have to run L1. Actually >they shouldn't since it'll be a resource waste....however your >"true" isis backbone will extend to the L1L2 border routers of the >various other areas. > > [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > > |---area 1----| |--area x---| |----Area 2----| > |----------isis backbone-----------| > > >Cheers. > >- abe > >> >> cheers, >> Eduard >> >> > ---------- >> > From: Mike Shand[SMTP:mshand@cisco.com] >> > Sent: dinsdag 20 juni 2000 20:34 >> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' >> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net >> > Subject: RE: [Isis-wg] Areas in ISIS >> > >> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: >> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area >> > would >> > >it? It needs to be L2 or L1/L2 at least. >> > >> > Were running into terminological inexactitudes here :-) >> > >> > Yes it does need to be L2, but one way of designing an IS-IS network is to >> > >> > make an area of L1/L2 routers which constitutes the backbone and then hang >> > >> > all the other areas off this one. Of course you need at least one L1/L2 >> > router in each of those areas, so the backbone (in the sense we were >> > talking before, i.e. the set of connected L2 routers - or the distribution >> > >> > domain of L2 LSPs) spans multiple areas. But it does look rather like the >> > OSPF case, where the backbone is a single area (0 in that case). >> > >> > Mike (S) >> > >> > >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- > > >==.==.==.==.== >Abe Martey >San Jose, CA >408 527 9149 > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 26 14:16:54 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12682 for ; Mon, 26 Jun 2000 14:16:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA19715; Mon, 26 Jun 2000 11:24:07 -0700 (PDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA19685 for ; Mon, 26 Jun 2000 11:24:05 -0700 (PDT) Received: (truskows@localhost) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) id LAA18537; Mon, 26 Jun 2000 11:12:52 -0700 (PDT) From: Mike Truskowski Message-Id: <200006261812.LAA18537@diablo.cisco.com> Subject: RE: [Isis-wg] Areas in ISIS To: jjl@one.com (Jeff Learman) Date: Mon, 26 Jun 2000 11:12:52 PDT Cc: isis-wg@external.juniper.net In-Reply-To: <3.0.1.32.20000626121837.01319340@mail.one.com>; from "Jeff Learman" at Jun 26, 100 12:18 (noon) X-Mailer: Elm [revision: 212.4] Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Somehow I'm lost here... I thought we were talking about what is the backbone... Another way to look at this is to consider it from the L1 router view point...in ISIS. I have a hard time following the discussion when scalability and topologies get in the way... How does a L1 router choose an external path... By closest L2 router. How does a router in one area talk to another in a different area? By L2 path. Hence, the backbone must be the set of all L2 routers with external reachability.... irregardless of connectability Now if you want any2any reachability...then the set of L2 routers must be contiguous... so connect the L2 routers like connecting dots in a drawing. Now, do you want to talk topology? Avoiding loops are important. That is why heirarchical networks are easier to maintain and scale... Further, loops just cause more L2 paths to maintain. So avoid loops. And network reliability and robustness... well you can build a network with single L1/L2 paths between areas... when a L2 path goes down then part of the network goes down... you can help the reliability if there are redundant paths out of an area to the backbone.... miket > > It's not important to avoid loops of areas. This does not contradict > what Mike Shand said. > > Another way to think of it is that, for robustness, you want to make sure > that your backbone is constructed in a way so that no single link or > router failure could partition the backbone. Likewise, each area should > be constructed so that no single link or router failure can partition the > area. In Mike's example, the backbone wouldn't be partitioned, but the > area would. > > As Mike says, you need to carefully plan the toplogy of your "Level 2 > subdomain", as it's called in ISO 10589, just as you carefully plan > the topology of each area. When showing a graphic of the whole topology, > it's usually a good idea to render the L2 links in a special color, > so that it jumps out even though it's not physically separate from > the rest of the network. > > Of course, this highlighting is unnecessary if you always plan an > "Area 0" containing most (but not all!) of your Level 2 backbone. > The rest of the L2 backbone would be the one-hop links from the Area > 0 routers to the L2 routers in the other areas. For robustness, you > would want at least two L2 routers in each area, each with its own link > to a different router in Area 0. But as soon as you depart from this > plan (by chaining subtended areas, for example), then you need to > look at your L2 backbone and make sure it is contiguous (even in the > event of a link or router failure). > > Regards, > Jeff > > At 08:14 PM 6/20/00 +0100, you wrote: > > > >Thanks for the clarifications ... > > > >As for the situation I was thinking of, this was indeed the case where you > >have multiple areas and the backbone is formed of the "edges" of the areas > >and the links between the areas. I didn't really think of a "chain" of > >areas, the loop issue is although interesting. > > > >I like the concept of this "virtual backbone" is ISIS, although in > >(re)designing networks you'll probably have to clearly keep in mind to keep > >the backbone contiguos and avoid chains (loops) of areas. While in OSPF this > >is more or less forced upon th designer due to the explicit area 0 that has > >to present, and to which all other areas should connect. > > > >cheers, > > Eduard > > > > > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area would > >it? It needs to be L2 or L1/L2 at least. > > > >> ---------- > >> From: Mike Shand[SMTP:mshand@cisco.com] > >> Sent: dinsdag 20 juni 2000 9:02 > >> To: Dave Katz > >> Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > >> Subject: Re: [Isis-wg] Areas in ISIS > >> > >> At 13:26 19/06/2000 -0700, Dave Katz wrote: > >> >This isn't "physically distinct" in the sense that L1 traffic can > >> traverse > >> >some of the same links that make up the L2 topology, but it is important > >> >to think of the L2 topology as distinct when you design your network, or > >> >you can end up in a world of hurt. In particular, if areas A, B, and C > >> >are connected through a loop, and there are parts of area B that depend > >> >on those L1L2 links for L1 connectivity, a break of the path through > >> >area B could not be healed via A and C. > >> > > >> >In the topology you describe, I would visualize the L2 path as being > >> >on the edge of area B, as it (at least to me) presents the weaknesses > >> >of the topology more clearly. > >> > >> Dave, > >> I couldn't agree more. The difference between IS-IS and OSPF is > >> not primarily one of network design, but one of nomenclature. i.e. in > >> IS-IS > >> you still need to design a 'backbone', but the backbone isn't named as a > >> single area (0) as it is in OSPF. In fact it isn't named at all. Its just > >> defined by the connected set of L2 routers. In some designs that will > >> correspond to a single L1 area, but in others it may traverse (or as you > >> rightly point out ,it is better to think of it as skirting around the edge > >> > >> of) multiple L1 areas. > >> > >> Mike > >> > >> > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > >> > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 26 17:08:33 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15918 for ; Mon, 26 Jun 2000 17:08:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA19897; Mon, 26 Jun 2000 14:12:14 -0700 (PDT) Received: from MailGate.Adtech-Inc.COM (smtp.adtech-inc.com [192.216.50.164]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA19866 for ; Mon, 26 Jun 2000 14:12:11 -0700 (PDT) Received: from mgmgrand.adtech-inc.com (Trans_Exchange.Adtech-Inc.COM [192.216.50.163]) by MailGate.Adtech-Inc.COM (8.10.0/8.10.0) with ESMTP id e5QL4Q222399 for ; Mon, 26 Jun 2000 11:04:26 -1000 (HST) Received: by mgmgrand.adtech-inc.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Jun 2000 11:00:33 -1000 Message-ID: From: "Nava.Zvaig" To: isis-wg@external.juniper.net Date: Mon, 26 Jun 2000 11:00:23 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFDFB1.912A6686" Subject: [Isis-wg] ISIS code Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFDFB1.912A6686 Content-Type: text/plain; charset="iso-8859-1" Hi all, I resubmit this message in case someone has some info... > Is there any software/shareware/freeware available for ISIS and ISIS-TE? > TIA, > Nava ------_=_NextPart_001_01BFDFB1.912A6686 Content-Type: text/html; charset="iso-8859-1" ISIS code

Hi all,

I resubmit this message in case someone has some info...


> Is there any software/shareware/freeware available for ISIS and ISIS-TE?

> TIA,
> Nava

------_=_NextPart_001_01BFDFB1.912A6686-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon Jun 26 18:44:34 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16745 for ; Mon, 26 Jun 2000 18:44:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA20026; Mon, 26 Jun 2000 15:51:57 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA19996 for ; Mon, 26 Jun 2000 15:51:55 -0700 (PDT) Received: from redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 2F11F2AA29; Mon, 26 Jun 2000 15:40:40 -0700 (PDT) To: Jeff Learman Cc: Abe Martey , "Metz, E.T." , isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS In-reply-to: Mail from Jeff Learman dated Mon, 26 Jun 2000 12:22:11 EDT <3.0.1.32.20000626122211.0132b100@mail.one.com> Date: Mon, 26 Jun 2000 15:39:53 -0700 From: Naiming Shen Message-Id: <20000626224041.2F11F2AA29@postal.redback.com> Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net For IP, level-1 routes can be imported into level-2 domain on the L12 routers. This is done by default on some of the popular ISIS implementations. ] ]For CLNP, you would need to run L1 as well as L2. Otherwise, ]you wouldn't be able to manage the routers in Area 0. ]When a packet arrives in Area 0, the L1 FDB would ]be consulted, but would be empty or missing, causing the ]packet to be dropped. ] ]I suspect the same might be true for IP traffic. ] ]At 09:05 AM 6/21/00 -0700, Abe Martey wrote: ]> ]> ]>On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: ]>> Small question (related to below), if you do create a separate backbone ]>> (physically, or at least similar to OSPF area 0), is it then needed or ]>> advantagous to have L1 routing in this area. Instead of just L2? ]> ]>You could have a physical area x designated as the "core" of the ]>backbone..and all routers in this area don't have to run L1. Actually ]>they shouldn't since it'll be a resource waste....however your ]>"true" isis backbone will extend to the L1L2 border routers of the ]>various other areas. ]> ]> [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] ]> ]> |---area 1----| |--area x---| |----Area 2----| ]> |----------isis backbone-----------| ]> ]> ]>Cheers. ]> ]>- abe ]> ]>> ]>> cheers, ]>> Eduard ]>> ]>> > ---------- ]>> > From: Mike Shand[SMTP:mshand@cisco.com] ]>> > Sent: dinsdag 20 juni 2000 20:34 ]>> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' ]>> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net ]>> > Subject: RE: [Isis-wg] Areas in ISIS ]>> > ]>> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: ]>> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area ]>> > would ]>> > >it? It needs to be L2 or L1/L2 at least. ]>> > ]>> > Were running into terminological inexactitudes here :-) ]>> > ]>> > Yes it does need to be L2, but one way of designing an IS-IS network ]is to ]>> > ]>> > make an area of L1/L2 routers which constitutes the backbone and then ]hang ]>> > ]>> > all the other areas off this one. Of course you need at least one L1/L2 ]>> > router in each of those areas, so the backbone (in the sense we were ]>> > talking before, i.e. the set of connected L2 routers - or the ]distribution ]>> > ]>> > domain of L2 LSPs) spans multiple areas. But it does look rather like ]the ]>> > OSPF case, where the backbone is a single area (0 in that case). ]>> > ]>> > Mike (S) ]>> > ]>> > ]>> ]>> _______________________________________________ ]>> Isis-wg mailing list - Isis-wg@external.juniper.net ]>> http://external.juniper.net/mailman/listinfo/isis-wg ]> ]>-- ]> ]> ]>==.==.==.==.== ]>Abe Martey ]>San Jose, CA ]>408 527 9149 ]> ]>_______________________________________________ ]>Isis-wg mailing list - Isis-wg@external.juniper.net ]>http://external.juniper.net/mailman/listinfo/isis-wg ]> ]> ]____________________________________________________________________ ] ] Jeff Learman Internet: jjl@one.com ] Engineering Manager Voice: (734)-975-7323 ] ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 ] 2725 South Industrial Pkwy, Suite 100 ] Ann Arbor, MI 48104 USA ]____________________________________________________________________ ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue Jun 27 11:24:58 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15315 for ; Tue, 27 Jun 2000 11:24:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA21059; Tue, 27 Jun 2000 08:33:02 -0700 (PDT) Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA20990 for ; Tue, 27 Jun 2000 08:32:50 -0700 (PDT) Received: from sj-dial-2-140.cisco.com (sj-dial-2-140.cisco.com [10.19.226.141]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA12045; Tue, 27 Jun 2000 08:21:18 -0700 (PDT) Date: Tue, 27 Jun 2000 08:13:16 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems, ISP-Team, SJ X-Priority: 3 (Normal) Message-ID: <19342.000627@cisco.com> To: Naiming Shen CC: Jeff Learman , Abe Martey , "Metz, E.T." , isis-wg@external.juniper.net Subject: Re: [Isis-wg] Areas in ISIS In-reply-To: <20000626224041.2F11F2AA29@postal.redback.com> References: <20000626224041.2F11F2AA29@postal.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Also, IP forwarding doesn't care about route types. L1 or L2, it just looks for the best match in the very (and single, which is important) routing table. > For IP, level-1 routes can be imported into level-2 domain on the > L12 routers. This is done by default on some of the popular ISIS > implementations. > ] > ]For CLNP, you would need to run L1 as well as L2. Otherwise, > ]you wouldn't be able to manage the routers in Area 0. > ]When a packet arrives in Area 0, the L1 FDB would > ]be consulted, but would be empty or missing, causing the > ]packet to be dropped. > ] > ]I suspect the same might be true for IP traffic. > ] > ]At 09:05 AM 6/21/00 -0700, Abe Martey wrote: > ]> > ]> > ]>On Tue, Jun 20, 2000 at 08:50:38PM +0100, Metz, E.T. wrote: > ]>> Small question (related to below), if you do create a separate backbone > ]>> (physically, or at least similar to OSPF area 0), is it then needed or > ]>> advantagous to have L1 routing in this area. Instead of just L2? > ]> > ]>You could have a physical area x designated as the "core" of the > ]>backbone..and all routers in this area don't have to run L1. Actually > ]>they shouldn't since it'll be a resource waste....however your > ]>"true" isis backbone will extend to the L1L2 border routers of the > ]>various other areas. > ]> > ]> [L1]=====[L1L2]=====[L2]=====[L2]======[L1L2]======[L1] > ]> > ]> |---area 1----| |--area x---| |----Area 2----| > ]> |----------isis backbone-----------| > ]> > ]> > ]>Cheers. > ]> > ]>- abe > ]> > ]>> > ]>> cheers, > ]>> Eduard > ]>> > ]>> > ---------- > ]>> > From: Mike Shand[SMTP:mshand@cisco.com] > ]>> > Sent: dinsdag 20 juni 2000 20:34 > ]>> > To: Metz, E.T.; Dave Katz; 'truskows@cisco.com' > ]>> > Cc: E.T.Metz@kpn.com; isis-wg@external.juniper.net > ]>> > Subject: RE: [Isis-wg] Areas in ISIS > ]>> > > ]>> > At 20:14 20/06/2000 +0100, Metz, E.T. wrote: > ]>> > >ps. Mike (Shand) an ISIS backbone will never correspond to a L1 area > ]>> > would > ]>> > >it? It needs to be L2 or L1/L2 at least. > ]>> > > ]>> > Were running into terminological inexactitudes here :-) > ]>> > > ]>> > Yes it does need to be L2, but one way of designing an IS-IS network > ]is to > ]>> > > ]>> > make an area of L1/L2 routers which constitutes the backbone and then > ]hang > ]>> > > ]>> > all the other areas off this one. Of course you need at least one L1/L2 > ]>> > router in each of those areas, so the backbone (in the sense we were > ]>> > talking before, i.e. the set of connected L2 routers - or the > ]distribution > ]>> > > ]>> > domain of L2 LSPs) spans multiple areas. But it does look rather like > ]the > ]>> > OSPF case, where the backbone is a single area (0 in that case). > ]>> > > ]>> > Mike (S) > ]>> > > ]>> > > ]>> > ]>> _______________________________________________ > ]>> Isis-wg mailing list - Isis-wg@external.juniper.net > ]>> http://external.juniper.net/mailman/listinfo/isis-wg > ]> > ]>-- > ]> > ]> > ]>==.==.==.==.== > ]>Abe Martey > ]>San Jose, CA > ]>408 527 9149 > ]> > ]>_______________________________________________ > ]>Isis-wg mailing list - Isis-wg@external.juniper.net > ]>http://external.juniper.net/mailman/listinfo/isis-wg > ]> > ]> > ]____________________________________________________________________ > ] > ] Jeff Learman Internet: jjl@one.com > ] Engineering Manager Voice: (734)-975-7323 > ] ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > ] 2725 South Industrial Pkwy, Suite 100 > ] Ann Arbor, MI 48104 USA > ]____________________________________________________________________ > ] > ]_______________________________________________ > ]Isis-wg mailing list - Isis-wg@external.juniper.net > ]http://external.juniper.net/mailman/listinfo/isis-wg > - Naiming > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg