From isis-wg-admin@external.juniper.net Wed Jan 5 12:16: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 MAA10971 for ; Wed, 5 Jan 2000 12:16:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA41339; Wed, 5 Jan 2000 09:09:03 -0800 (PST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA41307 for ; Wed, 5 Jan 2000 09:09:01 -0800 (PST) Received: from sh.bel.alcatel.be (btm04u.sh.bel.alcatel.be [138.203.194.104]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id SAA18139 for ; Wed, 5 Jan 2000 18:05:13 +0100 (MET) Received: from sh.bel.alcatel.be (btmp6y [138.203.194.110]) by sh.bel.alcatel.be (8.7/8.7) with ESMTP id RAA20487 for ; Wed, 5 Jan 2000 17:58:01 +0100 (MET) Message-ID: <38737818.E29ED900@sh.bel.alcatel.be> Date: Wed, 05 Jan 2000 17:58:00 +0100 From: Hans De Vleeschouwer A0 VR233 58223 Organization: Alcatel Telecom X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "isis-wg@external.juniper.net" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] contents of the MIB object: isisManAreaAddr 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, I am trying to work my way through the the ISIS MIB defintion. In doing so, I have a question wrt the field isisManAreaAddr in the mib table IsisManAreaAddrEntryTable: Does this field contain only the area address, or does it also include the actual systemid (i.e. the full NET)? From the description field, I would assume that only the area id is included, however this seems to be contradicted by looking at its type defintion (being OSINSAddress). Any help is kindly appreciated. Kind regards, hans. _______________________________________________ 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 Jan 5 13:20: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 NAA12564 for ; Wed, 5 Jan 2000 13:20:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41488; Wed, 5 Jan 2000 10:15:23 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA41461 for ; Wed, 5 Jan 2000 10:15:13 -0800 (PST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jan 2000 13:11:28 -0500 Message-ID: From: Jeff Parker To: Hans De Vleeschouwer A0 VR233 58223 Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr Date: Wed, 5 Jan 2000 13:11:27 -0500 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 > Hi, > > I am trying to work my way through the the ISIS MIB defintion. > > In doing so, I have a question wrt the field isisManAreaAddr > in the mib > table IsisManAreaAddrEntryTable: > > Does this field contain only the area address, or does it also include > the actual systemid (i.e. the full NET)? > > From the description field, I would assume that only the area id is > included, however this seems to be contradicted by looking at its type > defintion (being OSINSAddress). > > Any help is kindly appreciated. > > Kind regards, > hans. Hans - It is only the area portion. I could add another type parallel to the OSINSAddress, but this is the orginal form, and it holds exactly what is needed. - jeff parker isisManAreaAddr OBJECT-TYPE SYNTAX OSINSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "A manually configured area address for this system. This object follows the index behaviour." ::= { isisManAreaAddrEntry 2 } _______________________________________________ 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 Jan 7 09:51: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 JAA19158 for ; Fri, 7 Jan 2000 09:51:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA43853; Fri, 7 Jan 2000 06:46:21 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA43821 for ; Fri, 7 Jan 2000 06:46:14 -0800 (PST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 09:42:16 -0500 Message-ID: From: Jeff Parker To: Hans De Vleeschouwer A0 VR233 58223 , Jeff Parker Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr Date: Fri, 7 Jan 2000 09:42:15 -0500 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 > Hi Jeff, > > Thanks for your reply. > > I am really going through the MIB field by field now. ... > I am not quite sure whether I can contact you with those directly, or > wether I should keep on posting them to the newsgroup? Hans - If you think it isn't of general interest, you might send it only to me. I would rather see traffic to the list, for the selfish reason that I will need at some point to make the case that there has been public comment on the draft. It may also serve to keep me honest. Thus I'm going to copy the list on this reply. > In the mean time I came upon with another question related to the > field isisSysMaxAreaAddresses in the isisSysTable. > > The MIB indicates that the value of this field ranges between > 0 and 254. To be honest, this value is 3. It is 3 in all existing implementations, and it is a show stopper if two implementations don't agree. My ToDo list (see below) has the line isisSysMaxAreaAddresses should be 1..3, not 0..254 You could argue that it should be 3..3 instead. My current ToDo list includes the following items: I do intend to rev the draft this millennium. - jeff parker isisL2SummAddrTable isisL2SummAddrOperState change to AdminState The table name should change to IsisSummAddr instead of IsisL2SummAddr Cisco supports summarization at level-1 also and we have implemented an extended OperState to add this capability Remove isisCircManL2Only - replaced by isisCircLevel CircOperstate should be read-only Only isisCircISISL2HelloMultiplier - should be 2, or one, or none. isisSysMaxAreaAddresses should be 1..3, not 0..254 What is the story with IS(2) vs L1 and L2 below? isisISAdjNeighSysType OBJECT-TYPE SYNTAX INTEGER { unknown(1), intermediateSystem(3), l1IntermediateSystem(4), l2IntermediateSystem(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the neighboring system." REFERENCE "{ISIS.aoi neighbourSystemType (80)}" ::= { isisISAdjEntry 6 } Don't use IP addresses as index - summary table and IP reach table Split off optional parameters Overload bit Compliance - grouping Add boolean to mark L2 to L1 leaking Add Auth Type for MD5 Auth key will need to be a table (Rx values) Clarify UpTime _______________________________________________ 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 Jan 7 12:41:04 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 MAA23806 for ; Fri, 7 Jan 2000 12:41:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA44072; Fri, 7 Jan 2000 09:34:35 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA44043 for ; Fri, 7 Jan 2000 09:34:33 -0800 (PST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 12:30:34 -0500 Message-ID: From: Jeff Parker To: Henk Smit , Jeff Parker Cc: vleeschh@sh.bel.alcatel.be, isis-wg@external.juniper.net Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr Date: Fri, 7 Jan 2000 12:30:23 -0500 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 > > To be honest, [isisSysMaxAreaAddresses] is 3. > > It is 3 in all existing implementations, and it is > > a show stopper if two implementations don't agree. > > ... > Just for the record, in IOS, since about a year, you can configure > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > an ISIS MIB (yet). But I implemented it because of pressure that > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > note that ADMs usually only implement CLNS routing, not IP routing. > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > usefull. Still bad network design, IMHO. Oh, and I don't think any > of our customers use it. ;-) > > Henk. I think Henk has just demonstrated the importance of keeping such conversations on the list. Thanks, Henk! - jeff _______________________________________________ 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 Jan 7 13:56: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 NAA25128 for ; Fri, 7 Jan 2000 13:56:43 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA44231; Fri, 7 Jan 2000 10:52:43 -0800 (PST) Received: from mlsrv1.avici.com ([208.246.215.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA44203 for ; Fri, 7 Jan 2000 10:52:41 -0800 (PST) Received: from Kontoff.com (mkontoff-pc.avici.com [10.1.2.117]) by mlsrv1.avici.com (8.8.5/8.8.4) with ESMTP id NAA12121; Fri, 7 Jan 2000 13:47:44 -0500 (EST) Message-ID: <387634BE.C43AED56@Kontoff.com> Date: Fri, 07 Jan 2000 13:47:26 -0500 From: Matthew Kontoff X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: Henk Smit , vleeschh@sh.bel.alcatel.be, isis-wg@external.juniper.net Subject: Re: [Isis-wg] contents of the MIB object: isisManAreaAddr 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: > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > It is 3 in all existing implementations, and it is > > > a show stopper if two implementations don't agree. > > > > ... > > Just for the record, in IOS, since about a year, you can configure > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > > an ISIS MIB (yet). But I implemented it because of pressure that > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > > note that ADMs usually only implement CLNS routing, not IP routing. > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > > usefull. Still bad network design, IMHO. Oh, and I don't think any > > of our customers use it. ;-) The Avici TSR supports 1..255 area addresses. Matt _______________________________________________ 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 Jan 7 14:13: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 OAA25373 for ; Fri, 7 Jan 2000 14:13:07 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA44344; Fri, 7 Jan 2000 11:07:52 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA44318 for ; Fri, 7 Jan 2000 11:07:50 -0800 (PST) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 7 Jan 2000 13:02:18 -0600 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.2448.0) id ZAR1WWJR; Fri, 7 Jan 2000 11:02:11 -0800 Received: from nortelnetworks.com (lead.engeast.baynetworks.com [192.32.148.52]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id ZNDQC9SW; Fri, 7 Jan 2000 14:02:09 -0500 Message-ID: <38763831.C7076CC9@nortelnetworks.com> Date: Fri, 07 Jan 2000 14:02:09 -0500 From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Kontoff CC: Jeff Parker , Henk Smit , vleeschh@sh.bel.alcatel.be, isis-wg@external.juniper.net Subject: Re: [Isis-wg] contents of the MIB object: isisManAreaAddr References: <387634BE.C43AED56@Kontoff.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 Why can't this be 0 ? Do you need at least one manual area address for L2-only router also? To me, it seems that isisSysMaxAreaAddresses can be 0..X. Thanks, Rajesh Matthew Kontoff wrote: > Jeff Parker wrote: > > > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > > It is 3 in all existing implementations, and it is > > > > a show stopper if two implementations don't agree. > > > > > > ... > > > Just for the record, in IOS, since about a year, you can configure > > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement > > > an ISIS MIB (yet). But I implemented it because of pressure that > > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also > > > note that ADMs usually only implement CLNS routing, not IP routing. > > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more > > > usefull. Still bad network design, IMHO. Oh, and I don't think any > > > of our customers use it. ;-) > > The Avici TSR supports 1..255 area addresses. > > Matt > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri Jan 7 15:28: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 PAA26629 for ; Fri, 7 Jan 2000 15:27:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA44514; Fri, 7 Jan 2000 12:24:36 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA44486 for ; Fri, 7 Jan 2000 12:24:34 -0800 (PST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jan 2000 15:20:34 -0500 Message-ID: From: Jeff Parker To: Rajesh Saluja , Matthew Kontoff Cc: Jeff Parker , Henk Smit , vleeschh@sh.bel.alcatel.be, isis-wg@external.juniper.net Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr Date: Fri, 7 Jan 2000 15:20:30 -0500 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 is at stake is the maximum -allowed- (isisSysMaxAreaAddresses) not the number of entries in use (the size of isisManAreaAddrTable.) While a size of 0, 1, 2, or 3 are conceivable for this table, I hope we can agree that we wouldn't want a router that didn't allow the user to include 3 Manual Areas, if the user is so foolish as to want that. I did notice the following MIB variable, which suggests I was hasty in calling this a show stopper (see isisSysMaxAreaCheck) The conclusion I will draw from this is that existing practice allows the variable be 3..255. - jeff parker isisSysMaxAreaCheck OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When on, enables checking of maximum area addresses per IS version of ISO10589." DEFVAL { 1 } ::= { isisSysEntry 36 } [Messages edited] > Why can't this be 0 ? Do you need at least one manual area address for > L2-only router also? To me, it seems that > isisSysMaxAreaAddresses can be 0..X. > > Rajesh > > > > > > To be honest, [isisSysMaxAreaAddresses] is 3. > > > > > It is 3 in all existing implementations, and it is > > > > > a show stopper if two implementations don't agree. > > > > > > > > > > Jeff Parker > > > > > > > > Just for the record, in IOS, since about a year, you > > > > can configure isisSysMaxAreaAddresses 3..254. > > > > > > > > Henk Smit > > > > The Avici TSR supports 1..255 area addresses. > > > > Matt Kontoff _______________________________________________ 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 Jan 7 16:07: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 QAA27369 for ; Fri, 7 Jan 2000 16:07:20 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA44637; Fri, 7 Jan 2000 12:46:43 -0800 (PST) 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 MAA44608 for ; Fri, 7 Jan 2000 12:46:42 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25882 for ; Fri, 7 Jan 2000 12:42:41 -0800 (PST) Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA10839 for ; Fri, 7 Jan 2000 15:42:39 -0500 (EST) Received: from elm (elm [129.148.75.61]) by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id PAA29922 for ; Fri, 7 Jan 2000 15:42:40 -0500 (EST) Message-Id: <200001072042.PAA29922@bcn.East.Sun.COM> Date: Fri, 7 Jan 2000 15:42:39 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr To: isis-wg@external.juniper.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0IxBWBDl+JbFRsWfFROvbQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4 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 > > To be honest, [isisSysMaxAreaAddresses] is 3. > > It is 3 in all existing implementations, and it is > > a show stopper if two implementations don't agree. > > Having this be a parameter is, in my opinion, really silly. It's one of the things that the ISO committee added, along with ID size, that seems like unnecessary flexibility, and as Henk pointed out, everyone in the area has to have the same values or it won't work. The reason for area address, if I recall, is so that you can detect accidentally merging two areas, so they have different names. In CLNP it also told level 1 routers what prefixes should be routed via level 1 (look at the bottom 6 ...er ID_length... bytes) or sent to a level 2 router. The reason it's nice to allow more than one area address is to be able to merge or split up areas while the net's running. To merge A and B, add B as an allowable address to A, and A to B, and then when everyone agrees on both names, then one by one turn off one of the addresses. There's really no reason to need 3 -- 2 suffices but 3 seemed like a good idea at the time, maybe so you could simultaneously merge 3 areas, or perhaps it allowed you to be lazy about removing an area address for awhile, but certainly there's no reason to need 107 area addresses! It would be nice to leave it fixed at 3 and remove it from the MIB, I'd think. 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 Fri Jan 7 16:54: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 QAA27959 for ; Fri, 7 Jan 2000 16:54:52 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA44830; Fri, 7 Jan 2000 13:49:59 -0800 (PST) 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 NAA44799 for ; Fri, 7 Jan 2000 13:49:56 -0800 (PST) Received: from jharper-7020ct.cisco.com (ams-async15.cisco.com [144.254.45.26]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id VAA01283; Fri, 7 Jan 2000 21:46:04 GMT Message-Id: <200001072146.VAA01283@jaws.cisco.com> X-Sender: jharper@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 07 Jan 2000 21:45:40 +0000 To: Radia Perlman - Boston Center for Networking From: John Harper Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr Cc: isis-wg@external.juniper.net In-Reply-To: <200001072042.PAA29922@bcn.East.Sun.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 And in fact, it was more or less deliberate perversity on our part at the time to make it this way. We (those of us who worked on the original design at DEC and subsequently took it into ISO) thought the idea of having this as a parameter was really stupid (as Radia says), and we certainly weren't going to waste any of our neurones figuring out how to make misconfiguration recover gracefully, as we generally tried to do in the parts of the protocol that we cared about. Why anyone would see it as a feature to be able to set this to 8 boggles my mind. "I really like this Ferrari, but Caterpillar make vehicles with 96 wheels." "OK signor, in V550.1 we'll add the 96 wheel feature". John At 15:42 07/01/00 -0500, Radia Perlman - Boston Center for Networking wrote: >> > To be honest, [isisSysMaxAreaAddresses] is 3. >> > It is 3 in all existing implementations, and it is >> > a show stopper if two implementations don't agree. >> > > >Having this be a parameter is, in my opinion, really silly. It's >one of the things that the ISO committee added, along with ID size, >that seems like unnecessary flexibility, and as Henk pointed out, >everyone in the area has to have the same values or it won't work. > >The reason for area address, if I recall, is so that you can detect >accidentally merging two areas, so they have different names. In CLNP >it also told level 1 routers what prefixes should be routed via >level 1 (look at the bottom 6 ...er ID_length... bytes) or sent to >a level 2 router. > >The reason it's nice to allow more than one area address is to be able >to merge or split up areas while the net's running. To merge A and B, >add B as an allowable address to A, and A to B, and then when everyone >agrees on both names, then one by one turn off one of the addresses. >There's really no reason to need 3 -- 2 suffices but 3 seemed >like a good idea at the time, maybe so you could simultaneously merge >3 areas, or perhaps it allowed you to be lazy about removing an area >address for awhile, but certainly there's no reason to >need 107 area addresses! > >It would be nice to leave it fixed at 3 and remove it from the MIB, I'd >think. > >Radia > > >_______________________________________________ >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 Jan 7 17:00:16 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 RAA28053 for ; Fri, 7 Jan 2000 17:00:15 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA44787; Fri, 7 Jan 2000 13:48:45 -0800 (PST) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA44755 for ; Fri, 7 Jan 2000 13:48:39 -0800 (PST) Received: from jjl (pc15 [192.147.230.37]) by one.com (8.8.8/8.8.8) with SMTP id QAA10501; Fri, 7 Jan 2000 16:39:51 -0500 (EST) Message-Id: <3.0.1.32.20000107163949.0135a820@one.com> X-Sender: jjl@one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 07 Jan 2000 16:39:49 -0500 To: "Rajesh Saluja" From: Jeff Learman Subject: Re: [Isis-wg] contents of the MIB object: isisManAreaAddr Cc: Matthew Kontoff , Jeff Parker , Henk Smit , vleeschh@sh.bel.alcatel.be, isis-wg@external.juniper.net In-Reply-To: <38763831.C7076CC9@nortelnetworks.com> References: <387634BE.C43AED56@Kontoff.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 Rajesh, Some implementations may permit it to be provisioned to zero, but only because 0 in the PDU actually means "use the standard default of 3". At least one area address is absolutely required to do any CLNP routing at all, which is what IS-IS was originally designed for. A level 2 router is, according to the IS-IS spec "also a level 1 router in its own area", although there may be some implementations that skirt this issue. Practically speaking, though, there isn't any advantage to setting the value below three -- since it has to be the same for all ISs in the area, it's a bad idea to change it from the default of 3 unless you really need to (or *feel* you need to). Jeff At 02:02 PM 1/7/00 -0500, Rajesh Saluja wrote: >Why can't this be 0 ? Do you need at least one manual area address for >L2-only router also? To me, it seems that >isisSysMaxAreaAddresses can be 0..X. > >Thanks, >Rajesh > > >Matthew Kontoff wrote: > >> Jeff Parker wrote: >> > >> > > > To be honest, [isisSysMaxAreaAddresses] is 3. >> > > > It is 3 in all existing implementations, and it is >> > > > a show stopper if two implementations don't agree. >> > > > >> > ... >> > > Just for the record, in IOS, since about a year, you can configure >> > > isisSysMaxAreaAddresses 3..254. You're lucky, IOS does not implement >> > > an ISIS MIB (yet). But I implemented it because of pressure that >> > > some ADM vendors "could do isisSysMaxAreaAddresses up to 8". Also >> > > note that ADMs usually only implement CLNS routing, not IP routing. >> > > For CLNS routing multiple isisSysMaxAreaAddresses is a little more >> > > usefull. Still bad network design, IMHO. Oh, and I don't think any >> > > of our customers use it. ;-) >> >> The Avici TSR supports 1..255 area addresses. >> >> Matt >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- > >------------------------------------------------------------- >Rajesh Saluja >Nortel Networks Inc 600 Technology Park Billerica, MA 01821 >Ph: (978) 288-7791 Fax: (978) 670-8760 >-------------------------------------------------------------- > > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ 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 Sat Jan 8 05:49: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 FAA17454 for ; Sat, 8 Jan 2000 05:49:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA45709; Sat, 8 Jan 2000 02:46:07 -0800 (PST) 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 CAA45680 for ; Sat, 8 Jan 2000 02:46:05 -0800 (PST) Received: from mshand-8kcdt (mshand-isdn-home.cisco.com [10.49.144.122]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA06686; Sat, 8 Jan 2000 10:42:11 GMT Message-Id: <4.2.0.58.20000108103924.009e0f00@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 08 Jan 2000 10:41:49 +0000 To: Radia Perlman - Boston Center for Networking , isis-wg@external.juniper.net From: Mike Shand Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr In-Reply-To: <200001072042.PAA29922@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 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for Networking wrote: >The reason it's nice to allow more than one area address is to be able >to merge or split up areas while the net's running. To merge A and B, >add B as an allowable address to A, and A to B, and then when everyone >agrees on both names, then one by one turn off one of the addresses. >There's really no reason to need 3 -- 2 suffices but 3 seemed >like a good idea at the time, maybe so you could simultaneously merge >3 areas, or perhaps it allowed you to be lazy about removing an area >address for awhile, but certainly there's no reason to >need 107 area addresses! It was to do with DECnet Phase IV compatibility Radia. Typically an area would have two area addresses, a Phaseiv compatible one, and a real OSI one. So that makes two. Now if you want to merge/split the OSI area you need another one. I think that was the argument anyway. Mike ps. and yes I think a value other than 3 is silly too. _______________________________________________ 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 Jan 9 13:43: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 NAA09655 for ; Sun, 9 Jan 2000 13:43:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA49245; Sun, 9 Jan 2000 10:40:24 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA49217 for ; Sun, 9 Jan 2000 10:40:22 -0800 (PST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Sun, 9 Jan 2000 13:35:53 -0500 Message-ID: From: Jeff Parker To: Mike Shand , Radia Perlman - Boston Center for Networking , isis-wg@external.juniper.net Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr Date: Sun, 9 Jan 2000 13:35:52 -0500 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 While I don't want to claim I understand exactly what Cisco is trying to do, and while I haven't seen any documentation of what Avici is trying to do, I suspect the issue is supporting multiple L1 domains on a single router, not supporting multiple areas in a single domain. That is, I suspect that each of the L1 domains has a single area address: perhaps 2 when needed, and it may wish to implement upto 3. I don't think anyone is talking about recognizing 254 different Areas in the same domain. I would rather capture this as different SysInstances, each running with a different area address, which can then summarize the collection of routes learned into a common L2. I will try to clarify the language surrounding isisSysMaxAreaAddresses, to make clear that this is the Maximum Area Addresses in one Domain. A name change may help that effort. - jeff parker > At 15:42 07/01/2000 -0500, Radia Perlman - Boston Center for > Networking wrote: > >The reason it's nice to allow more than one area address is > to be able > >to merge or split up areas while the net's running. To merge A and B, > >add B as an allowable address to A, and A to B, and then > when everyone > >agrees on both names, then one by one turn off one of the addresses. > >There's really no reason to need 3 -- 2 suffices but 3 seemed > >like a good idea at the time, maybe so you could simultaneously merge > >3 areas, or perhaps it allowed you to be lazy about removing an area > >address for awhile, but certainly there's no reason to > >need 107 area addresses! > > It was to do with DECnet Phase IV compatibility Radia. > Typically an area > would have two area addresses, a Phaseiv compatible one, and > a real OSI > one. So that makes two. Now if you want to merge/split the > OSI area you > need another one. I think that was the argument anyway. > > Mike > > ps. and yes I think a value other than 3 is silly too. _______________________________________________ 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 Jan 10 03:35: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 DAA27835 for ; Mon, 10 Jan 2000 03:35:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA49992; Mon, 10 Jan 2000 00:33:06 -0800 (PST) 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 AAA49965 for ; Mon, 10 Jan 2000 00:33:03 -0800 (PST) Received: from mshand-8kcdt (lon-sto4-lan-vlan133-dhcp45.cisco.com [144.254.108.112]) by jaws.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA19326; Mon, 10 Jan 2000 08:28:54 GMT Message-Id: <4.2.0.58.20000110082642.00953f10@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 10 Jan 2000 08:28:53 +0000 To: Jeff Parker , Radia Perlman - Boston Center for Networking , isis-wg@external.juniper.net From: Mike Shand Subject: RE: [Isis-wg] contents of the MIB object: isisManAreaAddr In-Reply-To: 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:35 09/01/2000 -0500, Jeff Parker wrote: >While I don't want to claim I understand exactly what Cisco is >trying to do, and while I haven't seen any documentation of >what Avici is trying to do, I suspect the issue is supporting >multiple L1 domains on a single router, not supporting multiple >areas in a single domain. The two issues are pretty much orthogonal. The former is useful; the latter is not. 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 Jan 10 06:17: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 GAA28663 for ; Mon, 10 Jan 2000 06:17:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA50376; Mon, 10 Jan 2000 03:14:34 -0800 (PST) Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA50346 for ; Mon, 10 Jan 2000 03:14:27 -0800 (PST) Received: from sh.bel.alcatel.be (btm04u.sh.bel.alcatel.be [138.203.194.104]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id MAA15550 for ; Mon, 10 Jan 2000 12:09:54 +0100 (MET) Received: from sh.bel.alcatel.be (btmp6y [138.203.194.110]) by sh.bel.alcatel.be (8.7/8.7) with ESMTP id MAA22091 for ; Mon, 10 Jan 2000 12:02:41 +0100 (MET) Message-ID: <3879BC54.151668E4@sh.bel.alcatel.be> Date: Mon, 10 Jan 2000 12:02:44 +0100 From: Hans De Vleeschouwer A0 VR233 58223 Organization: Alcatel Telecom X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: "isis-wg@external.juniper.net" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Another question wrt to the isisSysTable 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, I have followed the discussion related to the isisSysTable field isisSysMaxAreaAddresses with great interest. For now, I think I will stick to the solution where: 1. the value can range between 1 and 3 2. the default value = 3 This will imply that a request to change the field isisSysOperState to 'on' will be rejected if no entry exists in the isisManAddrTable for this system instance. Now I have a different question related to the field isisSysAuthAreaType. I already understand from Jeff Parker that this field will be extended to allow also MD5 as authentication method. However, I still have the following questions: 1. The description talks about 'protecting L1 LSPs' . However, If I look at the RFC1195, it seems that authentication can apply to all types of messages, not only to LSP PDU. e.g. authentication can be applied to L1 Hello PDUs. Is there any reason to authenticate only the LSP PDU? 2. The value of the field is set to read-write. Would it make sense to state that this object follows the 'replaceOnlyWhileDisabled behavior' ? Kind regards, Hans De Vleeschouwer (alcatel Belgium). _______________________________________________ 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 Jan 10 10:00:35 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 KAA05352 for ; Mon, 10 Jan 2000 10:00:33 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA50654; Mon, 10 Jan 2000 06:54:18 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA50624 for ; Mon, 10 Jan 2000 06:54:16 -0800 (PST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 09:49:55 -0500 Message-ID: From: Jeff Parker To: Hans De Vleeschouwer A0 VR233 58223 , isis-wg@external.juniper.net Subject: RE: [Isis-wg] Another question wrt to the isisSysTable Date: Mon, 10 Jan 2000 09:49:55 -0500 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 have followed the discussion related to the isisSysTable field > isisSysMaxAreaAddresses with great interest. > > For now, I think I will stick to the solution where: > 1. the value can range between 1 and 3 > 2. the default value = 3 > > This will imply that a request to change the field isisSysOperState to > 'on' will be rejected if no entry exists in the isisManAddrTable for > this system instance. > > Now I have a different question related to the field > isisSysAuthAreaType. > I already understand from Jeff Parker that this field will be extended > to allow also MD5 as authentication method. > > However, I still have the following questions: > 1. The description talks about 'protecting L1 LSPs' . > However, If I look > at the RFC1195, it seems that authentication can apply to all types of > messages, not only to LSP PDU. e.g. authentication can be > applied to L1 Hello PDUs. There are four Authentication types: isisSysAuthAreaType - level 1 pkts isisSysAuthDomainType - level 2 pkts isisCircL1PasswordType- level 1 hellos isisCircL2PasswordType- level 2 hellos > Is there any reason to authenticate only the LSP PDU? The dominant implementation only protects the LSPs with the Area and Dommain values. > 2. The value of the field is set to read-write. Would it > make sense to > state that this object follows the 'replaceOnlyWhileDisabled > behavior' ? I need to review this with my SNMP gurus - I don't want to allow these to be set via SNMP for obvious security reasons. > > Kind regards, > Hans De Vleeschouwer (alcatel Belgium). _______________________________________________ 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 Jan 12 04:25: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 EAA11350 for ; Wed, 12 Jan 2000 04:25:29 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA52828; Wed, 12 Jan 2000 01:26:24 -0800 (PST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA52803 for ; Wed, 12 Jan 2000 01:26:19 -0800 (PST) Received: from zinin.amt.ru (zinin.amt.ru [10.0.0.175]) by amtsun.amt.ru (8.8.8/8.7.3.1) with ESMTP id MAA13269; Wed, 12 Jan 2000 12:21:26 +0300 (MSK) Date: Wed, 12 Jan 2000 12:21:25 +0300 From: Alex Zinin X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: Alex Zinin Organization: AMT Group X-Priority: 3 (Normal) Message-ID: <11514.000112@amt.ru> To: Mailing List , isis-wg@external.juniper.net In-reply-To: <200001072228.RAA04252@bacardi.torrentnet.com> References: <200001072228.RAA04252@bacardi.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] New ID: draft-ietf-ospf-refresh-guide-00.txt 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 Hello, all A new I-D that can be interesting for the OSPF and IS-IS WGs has been submitted to the IETF directories : "Guidelines for Efficient LSA Refreshment in OSPF" http://www.ietf.org/internet-drafts/draft-ietf-ospf-refresh-guide-00.txt The abstract section from the I-D follows: OSPF, an IGP widely deployed in IP networks today, requires each LSA to be refreshed by the originating router every 30 minutes. This method increases the protocol's robustness and solves potential problems that may be caused by software bugs, as well as some properties of the protocol itself. Though OSPF expects each LSA to be refreshed independently, ABRs and ASBRs tend to originate Type 3/4/5 LSAs within a short period of time, thus causing periodical network resource exhaustion by LSA refreshments. This document discusses the techniques that can be used to remedy this problem and provide smooth protocol operation. It must be noted that discussed methods can be applied to other link-state routing protocols, such as IS-IS. I would like to encourage everyone to send their comments, corrections and questions. Please use the address of the OSPF WG list (OSPF@DISCUSS.MICROSOFT.COM) for postings. It is ok to send the notes to me directly. ALSO, anyone feeling [s]he can contribute something to the document is welcomed to co-author. Best regards, Alex. _______________________________________________ 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 Jan 12 08:15: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 IAA14929 for ; Wed, 12 Jan 2000 08:15:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA53350; Wed, 12 Jan 2000 05:16:19 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA53318 for ; Wed, 12 Jan 2000 05:14:39 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 12 Jan 2000 18:47:36 +0530 Received: from tangcm.future.futsoft.com ([172.16.1.29]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id SAA26967 for ; Wed, 12 Jan 2000 18:30:14 +0530 Received: by tangcm.future.futsoft.com with Microsoft Mail id <01BF5D2C.2753A2C0@tangcm.future.futsoft.com>; Wed, 12 Jan 2000 18:38:00 +0530 Message-Id: <01BF5D2C.2753A2C0@tangcm.future.futsoft.com> From: Jorge To: "'IS-IS-Group'" Date: Wed, 12 Jan 2000 18:37:59 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id FAA53322 Subject: [Isis-wg] ask a question . 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: 8bit Hi, everyone I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you know ,i am eager to get those answer.Thanks in advance. HuaWei Development Facility of CHINA Future Software Private Limited 480-481,Mount Road,Nandanam, Chennai-600 -35.Inida _______________________________________________ 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 Jan 12 11:23: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 LAA18577 for ; Wed, 12 Jan 2000 11:23:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA53588; Wed, 12 Jan 2000 08:21:12 -0800 (PST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA53560 for ; Wed, 12 Jan 2000 08:21:09 -0800 (PST) Received: from zinin.amt.ru (zinin.amt.ru [10.0.0.175]) by amtsun.amt.ru (8.8.8/8.7.3.1) with ESMTP id TAA21227; Wed, 12 Jan 2000 19:15:57 +0300 (MSK) Date: Wed, 12 Jan 2000 19:15:56 +0300 From: Alex Zinin X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: Alex Zinin Organization: AMT Group X-Priority: 3 (Normal) Message-ID: <1802.000112@amt.ru> To: Jorge CC: isis-wg@external.juniper.net Subject: Re: [Isis-wg] ask a question . In-reply-To: <01BF5D2C.2753A2C0@tangcm.future.futsoft.com> References: <01BF5D2C.2753A2C0@tangcm.future.futsoft.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 Other people will add some input here if my answer is not complete. One way of dealing with NBMA media is assigning the VCs to logical point-to-point or multipoint interfaces. IS-IS is then enabled on the logical rather then physical interfaces, but transmission of a packet over a logical interface results in sending the packet through the physical one. Sending an IP packet over a p-t-p interface is simple, since the layer-2 details are either not necessary (in case of physical links) or predetermined (in case of logical links). Having split the VCs you basically represent an NBMA cloud as a set of p-t-p links. Another way (also used for multipoint logical interfaces) is treating the NBMA cloud as a broadcast media. This requires providing (manually or dynamically as in the case of FR) the information on which VCs should multicast packets be sent over. So, the router replicates the IP packets and sends the copies over each involved VCs. This, of course, implies that you have your VCs fully meshed. Regards, Alex. Wednesday, January 12, 2000, 4:07:59 PM, Jorge wrote: J> Hi, everyone J> I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS J> document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you J> know ,i am eager to get those answer.Thanks in advance. J> HuaWei Development Facility of CHINA J> Future Software Private Limited J> 480-481,Mount Road,Nandanam, J> Chennai-600 -35.Inida J> _______________________________________________ J> Isis-wg mailing list - Isis-wg@external.juniper.net J> 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 Wed Jan 12 11:40:31 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 LAA19186 for ; Wed, 12 Jan 2000 11:40:26 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA53727; Wed, 12 Jan 2000 08:38:53 -0800 (PST) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA53698 for ; Wed, 12 Jan 2000 08:38:50 -0800 (PST) Received: from jjl (pc15 [192.147.230.37]) by one.com (8.8.8/8.8.8) with SMTP id LAA00698; Wed, 12 Jan 2000 11:33:02 -0500 (EST) Message-Id: <3.0.1.32.20000112113257.01274150@one.com> X-Sender: jjl@one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 12 Jan 2000 11:32:57 -0500 To: Alex Zinin From: Jeff Learman Subject: Re: [Isis-wg] ask a question . Cc: Jorge , isis-wg@external.juniper.net In-Reply-To: <1802.000112@amt.ru> References: <01BF5D2C.2753A2C0@tangcm.future.futsoft.com> <01BF5D2C.2753A2C0@tangcm.future.futsoft.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 At 07:15 PM 1/12/00 +0300, Alex Zinin wrote: >Other people will add some input here >if my answer is not complete. > >One way of dealing with NBMA media >is assigning the VCs to logical point-to-point >or multipoint interfaces. IS-IS is then >enabled on the logical rather then physical >interfaces, but transmission of a packet >over a logical interface results in sending >the packet through the physical one. >Sending an IP packet over a p-t-p interface >is simple, since the layer-2 details are >either not necessary (in case of physical links) >or predetermined (in case of logical links). >Having split the VCs you basically represent >an NBMA cloud as a set of p-t-p links. > >Another way (also used for multipoint logical >interfaces) is treating the NBMA cloud as a >broadcast media. This requires providing (manually >or dynamically as in the case of FR) the information >on which VCs should multicast packets be sent over. >So, the router replicates the IP packets and >sends the copies over each involved VCs. >This, of course, implies that you have your VCs >fully meshed. This should be done with great care (or not at all). In general, it's important to send routing protocol traffic the same way data would be sent, as much as possible. Otherwise, you run the risk of thinking there is a data connection where there is none, or of incomplete distribution of routing information. In particular, pay careful attention to IS-IS's transitivity requirement for broadcast networks -- that is, if A can hear B and B can hear C, then A must be able to hear C. This rule would be easy to violate in a misprovisioned NBMA network, and would probably lead to serious connectivity problems. Regareds, Jeff >Regards, >Alex. > >Wednesday, January 12, 2000, 4:07:59 PM, Jorge wrote: > >J> Hi, everyone >J> I am a new member of IS-IS Group. Now i am engaged in the work of implementation for IS-IS over IPv4. i am a newcomer for IS-IS procotol,My dout is that going through all of IS-IS >J> document,i cann't find the content for how the IS-IS over IPv4 protocol supporting the X.25 ,Frame-Relay ,multi-link access network.who can give me some advice for it, i will very appreciated.you >J> know ,i am eager to get those answer.Thanks in advance. > >J> HuaWei Development Facility of CHINA >J> Future Software Private Limited >J> 480-481,Mount Road,Nandanam, >J> Chennai-600 -35.Inida > > >J> _______________________________________________ >J> Isis-wg mailing list - Isis-wg@external.juniper.net >J> 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 Thu Jan 13 01:36:04 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 BAA03721 for ; Thu, 13 Jan 2000 01:36:02 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA54477; Wed, 12 Jan 2000 22:36:59 -0800 (PST) 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 WAA54452 for ; Wed, 12 Jan 2000 22:36:57 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id WAA19242 for ; Wed, 12 Jan 2000 22:32:18 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id WAA56668 for ; Wed, 12 Jan 2000 22:38:13 -0800 (PST) (envelope-from navaneethk@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 13 Jan 2000 12:09:19 +0530 Received: from navaneethk.future.futsoft.com ([172.16.1.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA07174 for ; Thu, 13 Jan 2000 11:51:54 +0530 Received: by navaneethk.future.futsoft.com with Microsoft Mail id <01BF5DBD.C7907B00@navaneethk.future.futsoft.com>; Thu, 13 Jan 2000 12:00:26 -0800 Message-Id: <01BF5DBD.C7907B00@navaneethk.future.futsoft.com> From: navaneeth K To: "'isis-wg@juniper.net'" Date: Thu, 13 Jan 2000 12:00:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id WAA54453 Subject: [Isis-wg] ISH PDU.. 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: 8bit Hi all.. In the context of ISIS over IP , I have a doubt as to how the ISH PDUs will be handled and by whom... ISO 10589 1992 mentions that as a exception, ISH PDUs will have to be handled on PPP links when they first come up.. ISO 10589 1998 mentions that the ISIS shall cause ES-IS (9542 protocol machine) to send the ISH PDUs on PPP links.. So Who handles ISH PDU? ES-IS or IS-IS. In a pure IP implementation of ISIS we are not to take care of of ES-IS..In this case who sends the ISH PDU... If it is responsibilty of ES-IS, then why the standard talks about IS sendinh ISH in ISIS document.. Please clarify.. Navaneetha Krishnan.N Senior Software Engineer, HDF, Future Software Pvt Ltd, 480 - 481, Anna Salai, Nandanam, Chennai - 600 035 India. Phone : +91-44-4330550 Ext.412 Resi: 91 044 4338421 (After 10 P.M , Before 8 A.M) _______________________________________________ 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 Jan 13 01:37:59 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 BAA03767 for ; Thu, 13 Jan 2000 01:37:59 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA54524; Wed, 12 Jan 2000 22:39:15 -0800 (PST) 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 WAA54497 for ; Wed, 12 Jan 2000 22:39:14 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id WAA19321 for ; Wed, 12 Jan 2000 22:34:35 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id WAA56686 for ; Wed, 12 Jan 2000 22:40:43 -0800 (PST) (envelope-from navaneethk@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 13 Jan 2000 12:09:51 +0530 Received: from navaneethk.future.futsoft.com ([172.16.1.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA07197 for ; Thu, 13 Jan 2000 11:52:29 +0530 Received: by navaneethk.future.futsoft.com with Microsoft Mail id <01BF5DBD.DDE46C40@navaneethk.future.futsoft.com>; Thu, 13 Jan 2000 12:01:04 -0800 Message-Id: <01BF5DBD.DDE46C40@navaneethk.future.futsoft.com> From: navaneeth K To: "'isis-wg@juniper.net'" Date: Thu, 13 Jan 2000 12:01:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id WAA54498 Subject: [Isis-wg] ISH PDU.. 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: 8bit Hi all.. In the context of ISIS over IP , I have a doubt as to how the ISH PDUs will be handled and by whom... ISO 10589 1992 mentions that as a exception, ISH PDUs will have to be handled on PPP links when they first come up.. ISO 10589 1998 mentions that the ISIS shall cause ES-IS (9542 protocol machine) to send the ISH PDUs on PPP links.. So Who handles ISH PDU? ES-IS or IS-IS. In a pure IP implementation of ISIS we are not to take care of of ES-IS..In this case who sends the ISH PDU... If it is responsibilty of ES-IS, then why the standard talks about IS sendinh ISH in ISIS document.. Please clarify.. Navaneeth. _______________________________________________ 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 Jan 13 17:33: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 RAA25966 for ; Thu, 13 Jan 2000 17:33:13 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA55488; Thu, 13 Jan 2000 14:29:17 -0800 (PST) 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 OAA55459 for ; Thu, 13 Jan 2000 14:29:16 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id OAA11474 for ; Thu, 13 Jan 2000 14:24:32 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id OAA69565 for ; Thu, 13 Jan 2000 14:30:55 -0800 (PST) (envelope-from kim@telia.net) Received: from mailbox.telia.net (root@mailbox.telia.net [194.237.170.234]) by maile.telia.com (8.9.3/8.9.3) with ESMTP id XAA22267 for ; Thu, 13 Jan 2000 23:24:28 +0100 (CET) Received: from telia.net (k49d4.isdn-adv.telia.com [195.198.193.132]) by mailbox.telia.net (8.8.8/8.8.8) with ESMTP id XAA04415 for ; Thu, 13 Jan 2000 23:24:27 +0100 (CET) Message-ID: <387E511E.88084052@telia.net> Date: Thu, 13 Jan 2000 23:26:38 +0100 From: Michael Kim X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] BCP for building Integrated IS-IS Network 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! I have som question about design issue of the Integrated IS-IS network. Network is 200-300 nodes. Should this network be buildt with multiple level-1 IS-IS area and 1 level-2 IS-IS area or should this be buildt with just big one level-1-2 IS-IS area. I prefer to build network with the first alternative because in the first alternative will keep the database small on the routers. It will take few ms to recalculate SPF. I got recommendation from some vendor that network with this size it will be the best to build with just one big level-1-2 area. Reason is that there will be just one database so it will take less time to recalculate SPF. In the first case there will be some routers talking both level-1 and level-2 so there will be 2 database on those router and for those routers it will take longer time to recalculate SPF. But I think this is wrong becase in second alternative all the router is talking level-1 and level-2 so all of the router will have one level-1 and one level-2 database with bigger LSDB. It will increase recalculation time. Do I think right? Is there any BCP document other recommendation document for build IS-IS network? Thank You in advances /michael _______________________________________________ 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 Jan 13 19:52: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 TAA26805 for ; Thu, 13 Jan 2000 19:52:53 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA55654; Thu, 13 Jan 2000 16:51:13 -0800 (PST) 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 QAA55624 for ; Thu, 13 Jan 2000 16:51:11 -0800 (PST) From: hsmit@cisco.com Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id QAA23054 for ; Thu, 13 Jan 2000 16:46:28 -0800 (PST) Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id QAA72374 for ; Thu, 13 Jan 2000 16:52:52 -0800 (PST) (envelope-from hsmit@cisco.com) Received: from mdavison-ss20.cisco.com (mdavison-ss20.cisco.com [171.69.71.37]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id QAA01278; Thu, 13 Jan 2000 16:39:34 -0800 (PST) Received: (hsmit@localhost) by mdavison-ss20.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26085; Thu, 13 Jan 2000 16:46:25 -0800 (PST) Message-Id: <200001140046.QAA26085@mdavison-ss20.cisco.com> Subject: Re: [Isis-wg] BCP for building Integrated IS-IS Network To: kim@telia.net (Michael Kim) Date: Thu, 13 Jan 2000 16:46:24 -0800 (PST) Cc: isis-wg@juniper.net In-Reply-To: <387E511E.88084052@telia.net> from "Michael Kim" at Jan 13, 2000 11:26:38 PM 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! > I have som question about design issue of the Integrated IS-IS network. > Network is 200-300 nodes. > > Should this network be buildt with multiple level-1 IS-IS area and 1 > level-2 IS-IS area or should this be buildt with just big one level-1-2 > IS-IS area. This all depends on the strength of the IS-IS implementation of your vendor. And on the type of routers that you are using. I know at least one vendor where you can build areas with a 1000+ routers, if you buy their high end boxes. > I prefer to build network with the first alternative because in the > first alternative will keep the database small on the routers. It will > take few ms to recalculate SPF. Yes, the SPFs will be cheaper. But you run two of them. Also the mathemetical part of the SPF is usually not that expensive. Route installation (and FIB updates) is typically more expensive. Also when you use a lot of inter-area routes (L1->L2), it doesn't matter much if you deal with complexity of inter-area routes, or the complexity of SPF and intra-area routes. All this is just IMHO, and from experience with one implementation. The benefits of using multiple areas are: 1) a little more protection against link flaps 2) ability to extend your network easier. once your network grows so much that you finally really need multipkle areas, you have already layed them out 3) you can do summarization and filtering between area/level boundaries Drawbacks: 1) added configuration and troubleshooting complexity 2) if you do BGP, the fact that L1 areas are stub areas can give you troubles. (Giving MED to customers, doing shortest-exit-routing, etc). BTW, in some implementations L1 areas are more like NSSA. Also you can now do route-leaking with the old TLVs, or with the newer TLVs. See the recent drafts. > I got recommendation from some vendor that network with this size it > will be the best to build with just one big level-1-2 area. Reason is > that there will be just one database so it will take less time to > recalculate SPF. In the first case there will be some routers talking > both level-1 and level-2 so there will be 2 database on those router and > for those routers it will take longer time to recalculate SPF. I would say the main reason to run 200-300 routers in one area is simplicity. Why bother with multiple areas if you can get away with just one. > But I > think this is wrong becase in second alternative all the router is > talking level-1 and level-2 so all of the router will have one level-1 > and one level-2 database with bigger LSDB. It will increase > recalculation time. > > > Do I think right? I think the duration of SPF computation is not really relevant to the design of your network. > Is there any BCP document other recommendation document for build IS-IS > network? Don't think so. > Thank You in advances Hope this helps, Henk. > /michael > > > > > > _______________________________________________ > 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 Thu Jan 13 21:40: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 VAA27441 for ; Thu, 13 Jan 2000 21:40:06 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA55787; Thu, 13 Jan 2000 18:35:17 -0800 (PST) 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 SAA55757 for ; Thu, 13 Jan 2000 18:35:16 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id SAA00258 for ; Thu, 13 Jan 2000 18:30:30 -0800 (PST) Received: from ice.ip.qwest.net (ice.ip.qwest.net [216.111.66.200]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id SAA73943 for ; Thu, 13 Jan 2000 18:36:56 -0800 (PST) (envelope-from danny@ice.ip.qwest.net) Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id TAA14008; Thu, 13 Jan 2000 19:33:20 -0700 (MST) Message-Id: <200001140233.TAA14008@ice.ip.qwest.net> X-Mailer: exmh version 2.0.2 2/24/98 To: hsmit@cisco.com cc: kim@telia.net (Michael Kim), isis-wg@juniper.net From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: [Isis-wg] BCP for building Integrated IS-IS Network Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jan 2000 19:33:20 -0700 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 agree with Henk's comments. We run a single area L2-only domain with a couple hundred routers, other places I've worked had 350+ in a single domain. The primary reasons for not introducing hierarchy are those Henk mentioned: o Inability to derive accurate BGP MED values o L1 routers defaulting to closest L2 router can result in sub-optimal routing. o Troubleshooting is a bit more complex The ability to route leak does make a multi-level IS-IS network more appealing, though it's certainly not worth the complexity trade-offs at this point, or anywhere in the foreseeable future. I didn't see Henk mention it, but it would perhaps also seem that while a multi-level network is a bit more protected against potential of instabilities introduced by link oscillation, a single level network should converge slightly faster, though the gain is probably negligible. As for the SPF runtimes, they don't seem at all concerning in our network today. We use two different vendor implementations and SPF runtimes seem to be ~200 microseconds per node. We don't have any NBMA stuff or psuedonodes though, so the size of the LSDB is probably pretty small in comparison to other networks. -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 Fri Jan 14 11:14:41 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 LAA19162 for ; Fri, 14 Jan 2000 11:14:41 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA56629; Fri, 14 Jan 2000 08:13:45 -0800 (PST) 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 IAA56599 for ; Fri, 14 Jan 2000 08:13:43 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id IAA03852 for ; Fri, 14 Jan 2000 08:08:54 -0800 (PST) Received: from dragonfly.corp.home.net (dragonfly.corp.home.net [24.0.31.130]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id IAA81022 for ; Fri, 14 Jan 2000 08:15:25 -0800 (PST) (envelope-from rja@dragonfly.corp.home.net) Received: from dragonfly.corp.home.net (rja@localhost [127.0.0.1]) by dragonfly.corp.home.net (8.9.3/8.9.3) with ESMTP id LAA03336 for ; Fri, 14 Jan 2000 11:08:53 -0500 (EST) Message-Id: <200001141608.LAA03336@dragonfly.corp.home.net> X-Mailer: exmh version 2.1.0 09/18/1999 To: isis-wg@juniper.net Subject: Re: [Isis-wg] BCP for building Integrated IS-IS Network In-Reply-To: Message from Danny McPherson of "Thu, 13 Jan 2000 19:33:20 MST." <200001140233.TAA14008@ice.ip.qwest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Jan 2000 11:08:52 -0500 From: Ran Atkinson 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 IMHO, the analyses in recent emails (e.g. Henk's) would be useful to document in a short Informational RFC. Ran rja@corp.home.net _______________________________________________ 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 Jan 14 11:32: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 LAA19514 for ; Fri, 14 Jan 2000 11:32:30 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA56703; Fri, 14 Jan 2000 08:32:22 -0800 (PST) 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 IAA56679 for ; Fri, 14 Jan 2000 08:32:20 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id IAA04642 for ; Fri, 14 Jan 2000 08:27:30 -0800 (PST) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by rojo.juniper.net (8.9.3/8.9.3) with SMTP id IAA81322 for ; Fri, 14 Jan 2000 08:33:59 -0800 (PST) (envelope-from emmanuel.dauvergne@cnet.francetelecom.fr) Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 17:27:52 +0100 Message-ID: <98388C05D464D111B61800805F1504160148B304@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel CNET/DAC/ISS To: hsmit@cisco.com, "'danny@ice.ip.qwest.net'" Cc: kim@telia.net, isis-wg@juniper.net Subject: RE: [Isis-wg] BCP for building Integrated IS-IS Network Date: Fri, 14 Jan 2000 17:27:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id IAA56680 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: 8bit I'm not an MPLS expert, but I'm also thinking about the following drawback (in multi-level) : o Complexity in MPLS environnement : Inability to setup an LSP between two PE located in different L1-areas (stub areas). As Henk mentionned for MED calculation, this issue is solved with route-leaking concept. Manu > ---------- > De : Danny McPherson[SMTP:danny@qwest.net] > Répondre à : danny@ice.ip.qwest.net > Date : vendredi 14 janvier 2000 03:33 > A : hsmit@cisco.com > Cc : kim@telia.net; isis-wg@juniper.net > Objet : Re: [Isis-wg] BCP for building Integrated IS-IS Network > > > I agree with Henk's comments. > > We run a single area L2-only domain with a couple hundred routers, other > places I've worked had 350+ in a single domain. The primary reasons for > not > introducing hierarchy are those Henk mentioned: > > o Inability to derive accurate BGP MED values > o L1 routers defaulting to closest L2 router can result in sub-optimal > routing. > o Troubleshooting is a bit more complex > > The ability to route leak does make a multi-level IS-IS network more > appealing, though it's certainly not worth the complexity trade-offs at > this > point, or anywhere in the foreseeable future. > > I didn't see Henk mention it, but it would perhaps also seem that while a > multi-level network is a bit more protected against potential of > instabilities > introduced by link oscillation, a single level network should converge > slightly faster, though the gain is probably negligible. > > As for the SPF runtimes, they don't seem at all concerning in our network > today. We use two different vendor implementations and SPF runtimes seem > to > be ~200 microseconds per node. We don't have any NBMA stuff or > psuedonodes > though, so the size of the LSDB is probably pretty small in comparison to > other networks. > > -danny > > > _______________________________________________ > 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 Jan 14 17:56: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 RAA23459 for ; Fri, 14 Jan 2000 17:56:39 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA57101; Fri, 14 Jan 2000 14:54:57 -0800 (PST) Received: from mail.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by exernal.juniper.net (8.9.3/8.9.3) with ESMTP id TAA08104 for ; Wed, 17 Nov 1999 19:26:29 -0800 (PST) Received: from siara.com ([24.6.232.151]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991118033127.ZKCL24721.mail.rdc1.nj.home.com@siara.com>; Wed, 17 Nov 1999 19:31:27 -0800 Message-ID: <38337395.B4B499DE@siara.com> Date: Wed, 17 Nov 1999 22:33:42 -0500 From: Tony Przygienda Reply-To: prz@siara.com Organization: Siara Systems X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Christian E. Hopps" CC: Henk Smit , Rajesh Saluja , tli@procket.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt References: <199910051526.RAA17946@kraak.cisco.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 "Christian E. Hopps" wrote: > > Henk Smit writes: > > If you want to mark an IP prefix as external, we can do it via sub-TLVs. > > My collegues Naiming Shen has been working on tagging/coloring IP > > prefixes. Similar to OSPF tags or BGP communities. Maybe we can > > introduce some "well known" tags, to indicate that some prefixes > > were redistributed from outside into ISIS. > > What about support of incomparable metrics (i.e, ospf's type 2 metric). > The idea being you import the metric form the other protocol into the > `external' metric and it takes precedence over the IGP metric (which is > used to break ties). > > You can add this as a new sub-TLV in another draft; however, then you > run into transition issues. Routing loops are easy to come by if you > give the external metric precendence in the SPF and then some router > ignores that sub-tlv. By defining this in the main draft you at least > eliminate trying to transition twice. > > Since I don't have a lot of operational experience I'd like to ask: is > an incomparable external metric perceived as a gratuitous addition? I > was under the impression that it was used just about anytime you wanted > to import an EGP (or some aggregates of the EGP) into the IGP. Christian, I thought that adding an external metric into 135 would be a good thing to do since it's such a well-known "color" to borrow Henk's view of the world. However, from the customers of the protocol (those I checked with) I didn't hear any violent uproar telling me that they couldn't live without so my interpretation was taht we can let it pass that way and spend energy otherwise. Actually, thinking deeper, it was just telling me that nobody re-distributes today from/into ISIS heavily and doesn't intend to ;-) but as soon as they do the issue may arise. If you really want an external metric that is worse than any internal metric and interoperate with other people without agreeing on coloring your implementation could set the highest bit in the long-metric field considering If an IP prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see below), this IP prefix should not be considered during the normal SPF computation. This will allow advertisment of an IP prefix for other purposes than building the normal IP routing table. anything with 0x1000000 and above would be external. You'd just assume nobody ever comes with an internal metric > 0x1000000. I know it's a hack and I wouldn't recommend it and as I said I'd rather see the external bit with the appropriate preference in SPF being spelled out but I leave it to the customers to push that one if it's necessary. thanks -- 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 Jan 16 23:38: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 XAA15677 for ; Sun, 16 Jan 2000 23:38:28 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61719; Sun, 16 Jan 2000 20:39:17 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61687 for ; Sun, 16 Jan 2000 20:39:09 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 17 Jan 2000 10:11:06 +0530 Received: from tangcm.future.futsoft.com ([172.16.1.29]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id JAA15356 for ; Mon, 17 Jan 2000 09:53:08 +0530 Message-Id: <005301bf60a3$c4567780$1d0110ac@future.futsoft.com> From: "Jorge" To: "IS-IS-Group" Date: Mon, 17 Jan 2000 10:01:12 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01BF60D1.C8E8E200" Subject: [Isis-wg] Problem for Support Frame Relay . 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_004E_01BF60D1.C8E8E200 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkgLA0KICAgIE5vdyBpIG1ldCBzb21lIHByb2JsZW0gYWJvdXQgSVMtSVMgb24gSVB2NC5XZSB3 YW50IHRvICBpbXBsZW1lbnQgdGhlIElTLUlTIHRvIHN1cHBvcnQgdGhlIEZyYW1lIFJlbGF5ICxi dXQgaSB3YW50IHRvICBrbm93IGhvdyBpIGNhbiBpbXBsZW1lbnQgaXQgLkp1c3QgYXMgc29tZW9u ZSBzYWlkIGluIHByaW8gbWFpbHMgLHRvIHJlZ2FyZCB0aGUgRnJhbWUgUmVsYXkgYXMgbXVsdGlw bGUgUFBQIGxpbmtzICxpIHRoaW5rICx0aGlzIG1ldGhvZCBjYW4gYmUgZml0YWJsZSBmb3IgUFZD LCBidXQgaG93IHRvIGRlYWwgd2l0aCBTVkMsaSBkb24ndCBrbm93IHdoZXRoZXIgaXMgbWVhbnMg d2UgZG9uJ3QgbmVlZCB0byBjYXJlIGFib3V0IFNWQyAscGxlYXNlICBnaXZlIHNvbWUgYWR2aWNl IGZvciBtZS4gIFRoYW5rcyBhIGxvdCENCg== ------=_NextPart_000_004E_01BF60D1.C8E8E200 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yMDE0LjIxMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj5oaSAsPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNw OyBOb3cgaSBtZXQgc29tZSBwcm9ibGVtIGFib3V0IElTLUlTIA0Kb24gSVB2NC5XZSB3YW50IHRv ICBpbXBsZW1lbnQmbmJzcDt0aGUgSVMtSVMgdG8gc3VwcG9ydCB0aGUgRnJhbWUgUmVsYXkgLGJ1 dCBpIA0Kd2FudCB0byZuYnNwOyBrbm93IGhvdyBpIGNhbiBpbXBsZW1lbnQgaXQgLkp1c3QgYXMg c29tZW9uZSZuYnNwO3NhaWQgaW4gcHJpbyANCm1haWxzICx0byByZWdhcmQgdGhlIEZyYW1lIFJl bGF5IGFzIG11bHRpcGxlIFBQUCBsaW5rcyANCixpJm5ic3A7dGhpbmsmbmJzcDssdGhpcyZuYnNw O21ldGhvZCZuYnNwO2NhbiZuYnNwO2JlIGZpdGFibGUgDQpmb3ImbmJzcDtQVkMsJm5ic3A7YnV0 IGhvdyZuYnNwO3RvIGRlYWwgd2l0aCZuYnNwO1NWQyxpIA0KZG9uJ3QmbmJzcDtrbm93Jm5ic3A7 d2hldGhlciZuYnNwO2lzIG1lYW5zJm5ic3A7d2UgZG9uJ3QgbmVlZCZuYnNwO3RvIGNhcmUgDQph Ym91dCZuYnNwO1NWQyZuYnNwOyxwbGVhc2UmbmJzcDsgZ2l2ZSZuYnNwO3NvbWUmbmJzcDthZHZp Y2UgZm9yIG1lLiZuYnNwOyANClRoYW5rcyBhIGxvdCE8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_000_004E_01BF60D1.C8E8E200-- _______________________________________________ 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 Jan 17 11:06: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 LAA03213 for ; Mon, 17 Jan 2000 11:06:22 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62460; Mon, 17 Jan 2000 08:06:36 -0800 (PST) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62431 for ; Mon, 17 Jan 2000 08:06:34 -0800 (PST) Received: from jjl (pc15 [192.147.230.37]) by one.com (8.8.8/8.8.8) with SMTP id LAA22333; Mon, 17 Jan 2000 11:01:09 -0500 (EST) Message-Id: <3.0.1.32.20000117110103.0135dd60@one.com> X-Sender: jjl@one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 17 Jan 2000 11:01:03 -0500 To: "Jorge" From: Jeff Learman Subject: Re: [Isis-wg] Problem for Support Frame Relay . Cc: "IS-IS-Group" In-Reply-To: <005301bf60a3$c4567780$1d0110ac@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable It's not important whether the links are PVCs or SVCs, it's just important that they're "statically assigned". In other words, they have to be opened at startup time and in general, kept open the whole time. If you need to have the links open and close on an as-needed basis, then you can't use IS-IS to exchange routing information over them. It's OK if you want to shut down a link; just keep in mind that it won't be opened automatically if it is needed for data traffic. If the Frame Relay links are to end systems, then it isn't a problem. I'ts only a problem if the links are between routers, and you need to exchange IS-IS routing information between them. The reason is that IS-IS relies on the fact that all routers in an area (or for level 2, all L2 routers in the domain) must agree on the topology. In order for this to work, they need to be in constant communication. Therefore, "dynamically assigned" links, those that come up and go down on an as-needed basis, aren't appropriate for links between routers (simply because they're always needed.)=20 Regards, Jeff At 10:01 AM 1/17/00 +0530, Jorge wrote:=20 >>>> =CB=CE=CC=E5hi , Now i met some problem about IS-IS on IPv4.We want to implement the IS-IS to support the Frame Relay ,but i want to know how i can implement it .Just as someone said in prio mails ,to regard the Frame Relay as multiple PPP links ,i think ,this method can be fitable for PVC, but how to deal with SVC,i don't know whether is means we don't need to care about SVC ,please give some advice for me. Thanks a lot! <<<<<<<< ____________________________________________________________________ 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 Jan 17 11:36: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 LAA03617 for ; Mon, 17 Jan 2000 11:36:37 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62597; Mon, 17 Jan 2000 08:33:49 -0800 (PST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62565 for ; Mon, 17 Jan 2000 08:33:46 -0800 (PST) Received: from zinin.amt.ru (zinin.amt.ru [10.0.0.175]) by amtsun.amt.ru (8.8.8/8.7.3.1) with ESMTP id TAA29214; Mon, 17 Jan 2000 19:27:25 +0300 (MSK) Date: Mon, 17 Jan 2000 19:27:25 +0300 From: Alex Zinin X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: Alex Zinin Organization: AMT Group X-Priority: 3 (Normal) Message-ID: <15810.000117@amt.ru> To: Jeff Learman CC: "Jorge" , "IS-IS-Group" Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . In-reply-To: <3.0.1.32.20000117110103.0135dd60@one.com> References: <3.0.1.32.20000117110103.0135dd60@one.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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: 8bit Hmmm...I wouldn't say so. One can easily run IS-IS (or any other dynamic routing proto) over on-demand circuits provided that the idle timer doesn't close the VC before the next Hello PDU is sent over it. This is, actually, how these things are done in a number of implementations. As for Jorge's question---when SVCs are used, just make sure the SVC is open before sending anything along it. If it is not---generate a request for the circuit manager asking it to open the VC. This is assumed to be done in the IP-to-Layer2 part of the code, not in IS-IS. Just like with PVSs, mapping statements for SVCs are marked to be used for broadcast/multicast propagation. HTH Alex. Monday, January 17, 2000, 7:01:03 PM, Jeff Learman wrote: > It's not important whether the links are PVCs or SVCs, it's > just important that they're "statically assigned". In other > words, they have to be opened at startup time and in general, > kept open the whole time. If you need to have the links open > and close on an as-needed basis, then you can't use IS-IS > to exchange routing information over them. It's OK if you > want to shut down a link; just keep in mind that it won't be > opened automatically if it is needed for data traffic. > If the Frame Relay links are to end systems, then it isn't a > problem. I'ts only a problem if the links are between routers, > and you need to exchange IS-IS routing information between them. > The reason is that IS-IS relies on the fact that all routers > in an area (or for level 2, all L2 routers in the domain) must > agree on the topology. In order for this to work, they need to > be in constant communication. Therefore, "dynamically assigned" > links, those that come up and go down on an as-needed basis, > aren't appropriate for links between routers (simply because > they're always needed.) > Regards, > Jeff > At 10:01 AM 1/17/00 +0530, Jorge wrote: >>>>> > ËÎÌåhi , > Now i met some problem about IS-IS on IPv4.We want to implement the > IS-IS to support the Frame Relay ,but i want to know how i can implement > it .Just as someone said in prio mails ,to regard the Frame Relay as > multiple PPP links ,i think ,this method can be fitable for PVC, but how > to deal with SVC,i don't know whether is means we don't need to care > about SVC ,please give some advice for me. Thanks a lot! > > <<<<<<<< > ____________________________________________________________________ > 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 Jan 17 12:02:13 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 MAA04082 for ; Mon, 17 Jan 2000 12:02:12 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA62716; Mon, 17 Jan 2000 09:01:11 -0800 (PST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA62689 for ; Mon, 17 Jan 2000 09:01:06 -0800 (PST) Received: from zinin.amt.ru (zinin.amt.ru [10.0.0.175]) by amtsun.amt.ru (8.8.8/8.7.3.1) with ESMTP id TAA29422; Mon, 17 Jan 2000 19:54:53 +0300 (MSK) Date: Mon, 17 Jan 2000 19:54:53 +0300 From: Alex Zinin X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: Alex Zinin Organization: AMT Group X-Priority: 3 (Normal) Message-ID: <1829.000117@amt.ru> To: Tony Przygienda CC: Jeff Learman , Jorge , IS-IS-Group Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . In-reply-To: <3883469B.7F8F9532@siara.com> References: <3883469B.7F8F9532@siara.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 Monday, January 17, 2000, 7:43:07 PM, Tony Przygienda wrote: > again, first a problem statement would be nice to make sure > we're all tackling the same problem. Well, I think Jorge's initial messages are quite clear on that---running IS-IS over NBMA media. ...and whichever issues related :) > 2nd, Alex, you're oversimpliofying here ;-) Tony, I'm not. I'm just correcting the statement that on-demand VCs cannot be used with IS-IS. > Just "running" > the protocol that way leads to extensive thrashing of up&downs > of the circuit Quoting myself: "...provided that the idle timer doesn't close the VC before the next Hello PDU is sent over it." Note "doesn't" above. I think you misunderstood me a bit. I'm not proposing to open a VC for every packet and close it afterwards, I'm saying one doesn't need to emulate PVCs using SVCs. > [and therefore billing, if you don't get billed for your > FR or ATM service, you may as well always leave the circuit up ;-)], > a usable solution needs more thought like in OSPF > (don't age bits, smart adjacency stay-up and couple of more details) Agree. Alex. _______________________________________________ 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 Jan 17 13:48: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 NAA05479 for ; Mon, 17 Jan 2000 13:48:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA62856; Mon, 17 Jan 2000 10:46:51 -0800 (PST) Received: from mail.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62642 for ; Mon, 17 Jan 2000 08:48:17 -0800 (PST) Received: from siara.com ([24.6.232.151]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000117164305.BXAA3365.mail.rdc1.nj.home.com@siara.com>; Mon, 17 Jan 2000 08:43:05 -0800 Message-ID: <3883469B.7F8F9532@siara.com> Date: Mon, 17 Jan 2000 11:43:07 -0500 From: Tony Przygienda Reply-To: prz@siara.com Organization: Siara Systems Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Jeff Learman , Jorge , IS-IS-Group Subject: Re: [Isis-wg] Problem for Support Frame Relay . References: <3.0.1.32.20000117110103.0135dd60@one.com> <15810.000117@amt.ru> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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: 8bit Alex Zinin wrote: > Hmmm...I wouldn't say so. > One can easily run IS-IS (or any other dynamic routing > proto) over on-demand circuits provided that the idle > timer doesn't close the VC before the next Hello PDU > is sent over it. > > This is, actually, how these things are done in a number > of implementations. > > As for Jorge's question---when SVCs are used, just make > sure the SVC is open before sending anything along it. > If it is not---generate a request for the circuit manager > asking it to open the VC. This is assumed to be done > in the IP-to-Layer2 part of the code, not in IS-IS. > Just like with PVSs, mapping statements for SVCs are > marked to be used for broadcast/multicast propagation. again, first a problem statement would be nice to make sure we're all tackling the same problem. 2nd, Alex, you're oversimpliofying here ;-) Just "running" the protocol that way leads to extensive thrashing of up&downs of the circuit [and therefore billing, if you don't get billed for your FR or ATM service, you may as well always leave the circuit up ;-)], a usable solution needs more thought like in OSPF (don't age bits, smart adjacency stay-up and couple of more details) thasnk -tony > HTH > > Alex. > > Monday, January 17, 2000, 7:01:03 PM, Jeff Learman wrote: > > It's not important whether the links are PVCs or SVCs, it's > > just important that they're "statically assigned". In other > > words, they have to be opened at startup time and in general, > > kept open the whole time. If you need to have the links open > > and close on an as-needed basis, then you can't use IS-IS > > to exchange routing information over them. It's OK if you > > want to shut down a link; just keep in mind that it won't be > > opened automatically if it is needed for data traffic. > > > If the Frame Relay links are to end systems, then it isn't a > > problem. I'ts only a problem if the links are between routers, > > and you need to exchange IS-IS routing information between them. > > > The reason is that IS-IS relies on the fact that all routers > > in an area (or for level 2, all L2 routers in the domain) must > > agree on the topology. In order for this to work, they need to > > be in constant communication. Therefore, "dynamically assigned" > > links, those that come up and go down on an as-needed basis, > > aren't appropriate for links between routers (simply because > > they're always needed.) > > > Regards, > > Jeff > > > At 10:01 AM 1/17/00 +0530, Jorge wrote: > > >>>>> > > > ËÎÌåhi , > > > Now i met some problem about IS-IS on IPv4.We want to implement the > > IS-IS to support the Frame Relay ,but i want to know how i can implement > > it .Just as someone said in prio mails ,to regard the Frame Relay as > > multiple PPP links ,i think ,this method can be fitable for PVC, but how > > to deal with SVC,i don't know whether is means we don't need to care > > about SVC ,please give some advice for me. Thanks a lot! _______________________________________________ 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 Jan 17 13:49: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 NAA05500 for ; Mon, 17 Jan 2000 13:49:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA62918; Mon, 17 Jan 2000 10:48:31 -0800 (PST) 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 OAA57021 for ; Fri, 14 Jan 2000 14:12:17 -0800 (PST) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id OAA29750 for ; Fri, 14 Jan 2000 14:07:26 -0800 (PST) Received: from siara.com (fw.siara.com [209.10.58.69]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id OAA87660 for ; Fri, 14 Jan 2000 14:14:00 -0800 (PST) (envelope-from prz@siara.com) Received: from siara.com (prz-laptop.mtv.siara.com [192.168.1.96]) by siara.com (8.9.3-LCCHA/8.9.3/lccha Siara hub 1.4) with ESMTP id OAA26343; Fri, 14 Jan 2000 14:06:15 -0800 (PST) Message-ID: <387F9E16.B1F28E8E@siara.com> Date: Fri, 14 Jan 2000 17:07:18 -0500 From: Tony Przygienda Reply-To: prz@siara.com Organization: Siara Systems Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DAUVERGNE Emmanuel CNET/DAC/ISS CC: hsmit@cisco.com, "'danny@ice.ip.qwest.net'" , kim@telia.net, isis-wg@juniper.net Subject: Re: [Isis-wg] BCP for building Integrated IS-IS Network References: <98388C05D464D111B61800805F1504160148B304@p-ibis.issy.cnet.fr> 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 DAUVERGNE Emmanuel CNET/DAC/ISS wrote: 1. Ran's comment on the issues being worth written down is good but I assume I cannot interpret that as equal to volunteering to do it ;-) ?? > I'm not an MPLS expert, but I'm also thinking about the following drawback > (in multi-level) : > > o Complexity in MPLS environnement : Inability to setup an LSP between two > PE located in different L1-areas (stub areas). 2. there is some current thinking by the usual suspects how to solve the problem. I expect some kind of solution to gel. thanks -- 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 Jan 17 13:49: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 NAA05521 for ; Mon, 17 Jan 2000 13:49:38 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA62962; Mon, 17 Jan 2000 10:48:49 -0800 (PST) Received: from mail.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA61759 for ; Sun, 16 Jan 2000 20:57:49 -0800 (PST) Received: from siara.com ([24.6.232.151]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000117045237.VEVY3365.mail.rdc1.nj.home.com@siara.com>; Sun, 16 Jan 2000 20:52:37 -0800 Message-ID: <3882A019.6DF3E48A@siara.com> Date: Sun, 16 Jan 2000 23:52:41 -0500 From: Tony Przygienda Reply-To: prz@siara.com Organization: Siara Systems Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jorge CC: IS-IS-Group Subject: Re: [Isis-wg] Problem for Support Frame Relay . References: <005301bf60a3$c4567780$1d0110ac@future.futsoft.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 Jorge wrote: > hi , Now i met some problem about IS-IS on IPv4.We want to implement the IS-IS to support the Frame Relay ,but i want to know how i can implement it .Just as someone said in > prio mails ,to regard the Frame Relay as multiple PPP links ,i think ,this method can be fitable for PVC, but how to deal with SVC,i don't know whether is means we don't need to > care about SVC ,please give some advice for me. Thanks a lot! seems that the issue is being rised of whether we need support for ISIS in terms of P2M as OSPF has (and not of ISIS over IPv4 as the confusing topic and text suggests). It is a non-trivial (and not the most elegant and intuitive) extension to the protocol and probably only worth doing if customer demand exists. I think I pinged once on this list whether the potential customers have interest in P2M for ISIS with 0 answers. So I'd consider the issue not worth tackling for the moment since if there is nobody to deploy it, why put the effort in ? Just run SVCs and FR in P2P mode. However, if someone out there is implementing something proprietary to support P2M, it's probably much better that a draft shows up, rather than struggle with proprietary, incompatible (and probably buggy due to lack of review by knowledgable parties) later. thanks -- 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 Jan 17 13:52: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 NAA05503 for ; Mon, 17 Jan 2000 13:49:01 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA63001; Mon, 17 Jan 2000 10:48:55 -0800 (PST) Received: from mail.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA62540 for ; Mon, 17 Jan 2000 08:31:17 -0800 (PST) Received: from siara.com ([24.6.232.151]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000117162605.BPTT3365.mail.rdc1.nj.home.com@siara.com>; Mon, 17 Jan 2000 08:26:05 -0800 Message-ID: <3883429F.7BC2BF36@siara.com> Date: Mon, 17 Jan 2000 11:26:07 -0500 From: Tony Przygienda Reply-To: prz@siara.com Organization: Siara Systems Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Learman CC: Jorge , IS-IS-Group Subject: Re: [Isis-wg] Problem for Support Frame Relay . References: <3.0.1.32.20000117110103.0135dd60@one.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 Jeff Learman wrote: > It's not important whether the links are PVCs or SVCs, it's > just important that they're "statically assigned". In other > words, they have to be opened at startup time and in general, > kept open the whole time. If you need to have the links open > and close on an as-needed basis, then you can't use IS-IS > to exchange routing information over them. It's OK if you > want to shut down a link; just keep in mind that it won't be > opened automatically if it is needed for data traffic. > > If the Frame Relay links are to end systems, then it isn't a > problem. I'ts only a problem if the links are between routers, > and you need to exchange IS-IS routing information between them. > > The reason is that IS-IS relies on the fact that all routers > in an area (or for level 2, all L2 routers in the domain) must > agree on the topology. In order for this to work, they need to > be in constant communication. Therefore, "dynamically assigned" > links, those that come up and go down on an as-needed basis, > aren't appropriate for links between routers (simply because > they're always needed.) I'm not clear which problem this thread is pursuiting. Are we talking about the problem of partial meshes (P2M mode) or are we talking about the problem of dynamic FR circuits (SVCs) coming up ? Both problems have solutions (P2M mode or dial-up link extensions that allow the circuit to be shut down but adjacency maintained) but this whole "ISIS and FR" needs a short problem definition before solutions are being tossed around, I'd say. More important even, is anyone from the customers on this list interested in running ISIS over FR ? htankas -=-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 Jan 17 13:53:47 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 NAA05692 for ; Mon, 17 Jan 2000 13:53:47 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA63137; Mon, 17 Jan 2000 10:54:20 -0800 (PST) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA63111 for ; Mon, 17 Jan 2000 10:54:18 -0800 (PST) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA11685 for ; Mon, 17 Jan 2000 10:49:07 -0800 (PST) Received: by monterey.pluris.com with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 10:49:07 -0800 Message-ID: <6342F12F9359D311990B009027A1B9B61EBBC2@monterey.pluris.com> From: Nageswara Rao Soma To: "'isis-wg@external.juniper.net'" Date: Mon, 17 Jan 2000 10:49:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Passive interface 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, Somewhere I read that only routing updates are not sent over passive interfaces. However, neighbors' updates are received and processed over passive interfaces without affecting adjacencies. Could someone please explain me little more about this? Advance thanks for any help. Soma. PS: Forgive me if have not sent to correct mailing list address. _______________________________________________ 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 Jan 17 14:40: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 OAA07100 for ; Mon, 17 Jan 2000 14:40:34 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA63285; Mon, 17 Jan 2000 11:37:52 -0800 (PST) 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 LAA63253 for ; Mon, 17 Jan 2000 11:37:50 -0800 (PST) Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id LAA04426; Mon, 17 Jan 2000 11:32:38 -0800 (PST) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id LAA10432; Mon, 17 Jan 2000 11:32:37 -0800 (PST) Date: Mon, 17 Jan 2000 11:32:37 -0800 (PST) Message-Id: <200001171932.LAA10432@cirrus.juniper.net> From: Dave Katz To: nrsoma@pluris.com CC: isis-wg@external.juniper.net In-reply-to: <6342F12F9359D311990B009027A1B9B61EBBC2@monterey.pluris.com> (message from Nageswara Rao Soma on Mon, 17 Jan 2000 10:49:02 -0800) Subject: Re: [Isis-wg] Passive interface 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 Passive interfaces are a figment of implementation, rather than of specmanship. For LS protocols, the implementations with which I'm familiar will advertise passive interfaces as internal routes, but don't attempt to do any protocol handling at all (since it doesn't make a whole lot of sense and wouldn't work anyhow). For periodic DV protocols (i.e., RIP and IGRP), passive usually means that you're receiving the updates (since they're being blindly sent) but not sending anything back. This is the classic RIP-as-a- router-discovery-protocol mode. From: Nageswara Rao Soma Hi, Somewhere I read that only routing updates are not sent over passive interfaces. However, neighbors' updates are received and processed over passive interfaces without affecting adjacencies. _______________________________________________ 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 Jan 18 06:33: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 GAA27919 for ; Tue, 18 Jan 2000 06:33:08 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA64278; Tue, 18 Jan 2000 03:32:54 -0800 (PST) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA64246 for ; Tue, 18 Jan 2000 03:32:51 -0800 (PST) Received: from zinin.amt.ru (zinin.amt.ru [10.0.0.175]) by amtsun.amt.ru (8.8.8/8.7.3.1) with ESMTP id OAA04691; Tue, 18 Jan 2000 14:27:31 +0300 (MSK) Date: Tue, 18 Jan 2000 14:27:31 +0300 From: Alex Zinin X-Mailer: The Bat! (v1.38e) S/N A1D26E39 / Educational Reply-To: Alex Zinin Organization: AMT Group X-Priority: 3 (Normal) Message-ID: <6602.000118@amt.ru> To: IS-IS-Group CC: Jeff Learman , Jorge Subject: Re[2]: [Isis-wg] Problem for Support Frame Relay . In-reply-To: <3883864D.EFA54AA0@siara.com> References: <3883864D.EFA54AA0@siara.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 Tuesday, January 18, 2000, 12:14:54 AM, Tony Przygienda wrote: >> >> Tony, I'm not. I'm just correcting the statement >> that on-demand VCs cannot be used with IS-IS. > this part you don't, right. But after that you're saying it's easy and doesn't > need anything, that's at least slightly oversimplifying. You can run it that > way but you'll stop pretty soon after the montly bills come. If you don't > beleive me, try an ISDN link with OSPF active ;-) Tony, I'm a Russian, not stupid :) Just, please, don't read between the lines. When I say "x != y", I don't mean "(log(x) > sin(z))&&(exp(z) < log10(y))" Similarly, when I say "IS-IS *can* be easily run over SVCs" in contrast to "SVCs cannot be used with IS-IS", it doesn't mean "Guys, come on! Don't care about your money!"... I agree, however, that P2M and on-demand circuits are two different problems. This thread is more about the second issue, I believe. Sorry for BW wastage. Alex. _______________________________________________ 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 Jan 24 11:19: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 LAA12610 for ; Mon, 24 Jan 2000 11:19:56 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA73829; Mon, 24 Jan 2000 08:18:17 -0800 (PST) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA73803 for ; Mon, 24 Jan 2000 08:18:06 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 24 Jan 2000 21:49:25 +0530 Received: from selvarajr ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id VAA02521 for ; Mon, 24 Jan 2000 21:30:48 +0530 Received: by localhost with Microsoft MAPI; Mon, 24 Jan 2000 21:42:12 +0530 Message-Id: <01BF66B3.DFCA00C0.selvarajr@future.futsoft.com> From: SelvarajR To: "'isis-wg@external.juniper.net'" Date: Mon, 24 Jan 2000 21:42:11 +0530 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Doubts in MIB and SNDF 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, I'm implementing Integrated ISIS protocol which is very new for me . I've the following doubts. 1. In the MIB draft, draft-ietf-isis-wg-mib-02.txt , for Integrated ISIS It has been stated that , isisSystem table contains information specific to a single instance of ISIS protocol running on a router. Does this means more than one Integrated ISIS runs on a single machine ? If yes, what is the purpose of having more than one instance in a single machine and where does it apply. 2. In ISO 10589 1998, in SNDF for PPP , it has been mentioned setting circuit ID Status after receiving IIH PDU ( section 8.2.5.2( c ) ) . What is the significance of this circiut ID status? Also there is no such MIB object. Please , clarify me. Thanx in advance Selva _______________________________________________ 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 Jan 28 14:16: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 OAA24323 for ; Fri, 28 Jan 2000 14:16:44 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA78898; Fri, 28 Jan 2000 11:13:40 -0800 (PST) Received: from sigma.cisco.com (sigma.cisco.com [171.69.63.142]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA78871 for ; Fri, 28 Jan 2000 11:13:39 -0800 (PST) Received: from kraak.cisco.com (hsmit-isdn-home.cisco.com [10.49.64.98]) by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA18790 for ; Fri, 28 Jan 2000 11:07:02 -0800 (PST) Received: (from hsmit@localhost) by kraak.cisco.com (8.8.4-Cisco.1/HSMIT190697) id UAA23005 for isis-wg@external.juniper.net; Fri, 28 Jan 2000 20:06:51 +0100 (MET) From: Henk Smit Message-Id: <200001281906.UAA23005@kraak.cisco.com> To: isis-wg@external.juniper.net Date: Fri, 28 Jan 2000 20:06:51 +0100 (MET) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Concerns about ISIS in IP encapsulation 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 During the IETF ISIS WG meeting in Oslo we had a bit of a discussion about the proposal for ISIS in IP encapsulation. (See draft-ietf-isis-wg-over-ip-01.txt for details). At that meeting, I have voiced my concerns about the proposal. I had prepared an email to send to this list long time ago. But there was never a compeling reason to bring up the subject again. Let me try to recap some of the discussion. Benefits of ISIS in IP encapsulation. A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP. My opinion: - This true. But had I hope my proposal was a more simple and easier solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt). Last summer I have emailed two of our largest ISIS+ATM customers that I had the code ready, but they didn't seem much interested. Now I wonder how bad ISPs really want to improve the efficiency of the ISIS+ATM combo. B) ISIS-in-IP prevents the need of defining OSI/ISIS encapses every time a new layer2 technology is emerging. - This is true. But it is very likely that native OSI/ISIS encapsulations will be defined for new layer2 technologies anyway. E.g. CLNS itself is not dead yet. CLNS is not relevant in the Internet, and probably not in Enterprise networks. But RBOCs are using CLNS for their management networks for their Sonet/SDH infrastructure. So native OSI/ISIS/CLNS will be around for a while, so there will be new encapsulations for OSI/ISIS/CLNS defined. C) ISIS-in-IP improves portability of gated. - Personally I don't care much about this. While people might not expect this from a cisco employee, I do like open source software. But I think that new technology should not be based on what is easy to implement in one particular operating system (even if it is Unix). Also the fact remains that all current ISIS implementation run native over layer2, so if gated or any other ISIS implementation wants any acceptance in the real world, it still needs to implement ISIS-in-layer2 encapsulation. D) ISIS-in-IP might improve the acceptance of ISIS in circles of IP bigots. - IMHO people who don't like ISIS won't suddenly like it because they can now encapsulate ISIS in IP. Now the drawbacks: 1) Why add a second method of encapsulation ? ISIS-over-IP doesn't solve a real problem. If the efficiency of ISIS+ATM is really an issue for some customers, this could be solved by using the first byte in the IP header as NLPID. Maybe we can get away without a more complex solution. If we solve this problem just for ATM (actually just for "aal5mux ip"), then if ATM becomes less popular in a couple of years (at least in highspeed networks), we can forget about this hack. If we do ISIS-over-IP we will be stuck with it forever. See IPX. 2) It adds more complexity to the protocol. One of the reasons some people like ISIS over OSPF is the fact that ISIS is simpler in some areas. We are now adding all kinds of features and extensions. If we add too many, ISIS will be worse than OSPF in this respect. Personally I would hate to see that happen. 3) It adds more complexity to the configuration. The less configuration choices there are, the easier ISIS will be to deploy. Look at a similar case: IPX. It has four encapsulations. There are no benefits to that, just added confusion. 4) IP fragmentation. I think that people will not move whole networks at the same time. They will run hybrid networks with ISIS-over-layer2 and ISIS-over-IP. That in itself will add complexity. I am sure customers won't configure smaller LSP buffer sizes on all their routers. At least not until their network really breaks. So I am afraid that LSP will be fragmented at the IP layer. Note, if a router has more than 1492 bytes of info to advertise into ISIS, that router must fragment its LSP. It will probably create a first LSP of size 1492, and at least one small LSP. That first LSP of size 1492 will be fragmented at the IP layer on links that have an MTU of 1500 and run ISIS-over-IP. So a router that redistributes more than 100 IP routes or so will have at least one LSP of size 1492. Right now lots of ISIS networks I know run in a single flat area. But if they ever do true L1L2, the L1L2 routers will advertise lots of interarea routes. So most likely the L1L2 routers will all create LSP fragments of size 1492. As you all know, link-state protocols have two areas of concern regarding scalability. One is route computation, and the other is flooding. I think fragmentation at the IP layer will make ISIS flooding less scalable. I was told by one of editors of 10589 that preventing fragmentation during the flooding was the main reason why ISIS fragments only at the originating router. BTW, I am not so much concerned about fragmentation, but more about reassambly. 5) Consistency towards other standards bodies. The ISIS-over-IP draft recommends that routers use an LSPBufferSize of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world the Sonet Interoperability Forum (SIF) works on ISIS too. They want to run ISIS over the DCC. The DCC channel is a part of the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC says that the DCC must use LAPD encaps, and that the *maximum* MTU is 512 bytes. So you can't run ISIS over the DCC, because some routers might send LSPs of size larger than 512 bytes. Those LSPs can not be flooded over the DCC. So the SIF wanted to add some cruft to 10589 that changes the LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to that. But if the ISIS WG in the IETF recommends to lower the LSPBufferSize from 1492 to 1480, why not lower it to 512 ? We will not be able to defend ourselves to changes like the proposal from the SIF. To be honest, I don't know about the latest status on the SIF proposal. It actually might have been withdrawn. 6) Security. ISIS-over-layer2 is actually a feature. ISIS packets are not routable. It makes sure that nobody but your direct physical neighbors can inject routing packets into your IGP. Suppose a network uses ISIS-over-IP. That means I can send ISIS packets from my PC at home to any router in that network. It is easy to fake source IP addresses. So I can inject LSPs into this network, or do other nasty things, like break adjacencies, etc. So now this network needs to use ISIS authentication. Probably strong authentication, like HMAC/MD5 (not cleartext passwords). But still if that is done, I can send a 1000 LSPs/second to those routers. And they need to check the authentication, which might use lots of CPU power. Or I can send IP fragments, which will use buffers. All kinds of nasty denial of service attacks come to mind. I guess these attacks could be applicable to OSPF today, so the OSPF people might already have a solution which we can use. But I would like to point out that ISIS-over-layer2 is a feature. 7) What about IPv6 ? If we ever get around to define TLVs to do IPv6 routing in ISIS, which encapsulation would it use ? A nice thing about ISIS is that ISIS packets are not encapsulated in CLNS, and not in IP. Now if we add ISIS-over-IPv4, we might end up in a situation where we will have to define an ISIS-over-IPv6 encapsulation too. What if routing for other layer3 protocols gets defined ? Will we add an encapsulation for that layer3 too ? 8) Why not encapsulate in CLNS as well ? 10589 defines virtual links for area repair. Those virtual links use CLNS encapsulation to get packets across the L2 backbone. Extra complexity for little gain. (The gain would be that networks with a broken design seem a little less broken). That added complexity was one of the reasons why I have discourge my employer from implementing virtual links and area partition repair. Once we implement virtual links for area partition repair, we probably will have to support area partitioning for IP as well. The result will be that if gated and others want to stay compatible with current features, they might have to implement a full CLNS stack, just to be able to deal with area partition repair. Just ISIS-over-layer2 encapsulation will not be enough anymore. Some comments on my concerns. - Curtis Villamizer said that networks don't run their IGP over 10 Mbps ethernet anymore. ISPs use POS, ATM, FDDI, Fast Ethernet and Gigabit Ethernet. Those layer2 technology all can have MTUs of 1512 or higher. 10 Mbps ethernet is only used at the edges towards the hosts. I guess that is correct. So fragmentation migh occur less often then I fear. After all, the large NBMA meshes are mostly over ATM today, which has a larger MTU. However, enterprise networks might run ISIS over 10 Mbps Ethernet. And some router implementations use standard MTUs of 1500 on their serial (PPP, HDLC, frame-relay) interfaces. To use larger MTUs over FE and Gig-ethernet we need the new encapsulation, which might cause other problems (like on bridges). So I am not fully convinced yet that fragmentation won't be a problem. Thank you for your attention, 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 Fri Jan 28 18:07: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 SAA29307 for ; Fri, 28 Jan 2000 18:07:25 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79162; Fri, 28 Jan 2000 15:03:36 -0800 (PST) Received: from allegro.juniper.net (allegro.juniper.net [208.197.169.65]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79131 for ; Fri, 28 Jan 2000 15:03:34 -0800 (PST) Received: by allegro.juniper.net with Internet Mail Service (5.5.2650.21) id ; Fri, 28 Jan 2000 15:02:35 -0800 Message-ID: <25928A4228FDD211BD80009027628222D90B23@allegro.juniper.net> From: Paul Traina To: isis-wg@external.juniper.net Subject: RE: [Isis-wg] Concerns about ISIS in IP encapsulation Date: Fri, 28 Jan 2000 15:02:33 -0800 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 Allow me to reiterate my support (and Dave's) from Oslo. I really like Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed out that this is well within the expected behavior for OSI protocols. With Henk's proposal as a tool for solving the MUX encaps issues of ATM and similar encapsulations that are incapable of carrying a ptype, I do not see any great need for IS-IS to be reimplemented to use IP as a transport layer. Your IGPs may as well be multi-protocol. The world is already a happy place. 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 Fri Jan 28 18:24:20 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 SAA29451 for ; Fri, 28 Jan 2000 18:24:19 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79323; Fri, 28 Jan 2000 15:23:21 -0800 (PST) Received: from ice.ip.qwest.net (ice.ip.qwest.net [216.111.66.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79262 for ; Fri, 28 Jan 2000 15:23:17 -0800 (PST) Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id QAA08877 for ; Fri, 28 Jan 2000 16:19:43 -0700 (MST) Message-Id: <200001282319.QAA08877@ice.ip.qwest.net> X-Mailer: exmh version 2.0.2 2/24/98 To: isis-wg@external.juniper.net From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: [Isis-wg] Concerns about ISIS in IP encapsulation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 16:19:43 -0700 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 To chime is as "an operator", I agree. I don't see any significant advantages with deploying it in my network, other than the job security that comes along introducing new complexities into a system. Am I missing something? -danny > Allow me to reiterate my support (and Dave's) from Oslo. I really like > Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed > out that this is well within the expected behavior for OSI protocols. > > With Henk's proposal as a tool for solving the MUX encaps issues of ATM and > similar encapsulations that are incapable of carrying a ptype, I do not see > any great need for IS-IS to be reimplemented to use IP as a transport layer. > Your IGPs may as well be multi-protocol. The world is already a happy > place. _______________________________________________ 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 Jan 28 18:24:57 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 SAA29462 for ; Fri, 28 Jan 2000 18:24:57 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79311; Fri, 28 Jan 2000 15:23:20 -0800 (PST) Received: from ice.ip.qwest.net (ice.ip.qwest.net [216.111.66.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79263 for ; Fri, 28 Jan 2000 15:23:17 -0800 (PST) Received: from ice.ip.qwest.net (localhost [127.0.0.1]) by ice.ip.qwest.net (8.9.3/8.9.3) with ESMTP id QAA08885 for ; Fri, 28 Jan 2000 16:19:44 -0700 (MST) Message-Id: <200001282319.QAA08885@ice.ip.qwest.net> X-Mailer: exmh version 2.0.2 2/24/98 To: isis-wg@external.juniper.net From: Danny McPherson Reply-To: danny@ice.ip.qwest.net Subject: Re: [Isis-wg] Concerns about ISIS in IP encapsulation Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 16:19:44 -0700 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 To chime is as "an operator", I agree. I don't see any significant advantages with deploying it in my network, other than the job security that comes along introducing new complexities into a system. Am I missing something? -danny > Allow me to reiterate my support (and Dave's) from Oslo. I really like > Henk's proposal (draft-hsmit-isis-ip-aal5mux-00.txt), and Dave has pointed > out that this is well within the expected behavior for OSI protocols. > > With Henk's proposal as a tool for solving the MUX encaps issues of ATM and > similar encapsulations that are incapable of carrying a ptype, I do not see > any great need for IS-IS to be reimplemented to use IP as a transport layer. > Your IGPs may as well be multi-protocol. The world is already a happy > place. _______________________________________________ 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 Jan 28 18:28: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 SAA29494 for ; Fri, 28 Jan 2000 18:28:04 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79247; Fri, 28 Jan 2000 15:21:43 -0800 (PST) Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA79217 for ; Fri, 28 Jan 2000 15:21:40 -0800 (PST) Received: from localhost (wrath@localhost) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with SMTP id SAA15736; Fri, 28 Jan 2000 18:15:00 -0500 (EST) Date: Fri, 28 Jan 2000 18:15:00 -0500 (EST) From: Vijay Gill To: Henk Smit cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Concerns about ISIS in IP encapsulation In-Reply-To: <200001281906.UAA23005@kraak.cisco.com> Message-ID: 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 On Fri, 28 Jan 2000, Henk Smit wrote: > Benefits of ISIS in IP encapsulation. > A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP. > > My opinion: > - This true. But had I hope my proposal was a more simple and easier > solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt). > Last summer I have emailed two of our largest ISIS+ATM customers > that I had the code ready, but they didn't seem much interested. > Now I wonder how bad ISPs really want to improve the efficiency > of the ISIS+ATM combo. I'll speak to this point briefly. As the promising local ISP I work for transitions from IP over ATM to Packet over SONET, the effort to deploy the above proposals doesn't give us a good enough return. Two years ago, yes; today, the benefits are not that glaringly obvious given the transitioning already in place. /vijay _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat Jan 29 15:20: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 PAA22936 for ; Sat, 29 Jan 2000 15:20:54 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA82441; Sat, 29 Jan 2000 12:15:26 -0800 (PST) Received: from scotch.merit.edu (scotch.merit.edu [198.108.60.195]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA82400 for ; Sat, 29 Jan 2000 12:15:24 -0800 (PST) Received: (from chopps@localhost) by scotch.merit.edu (8.8.8/8.8.8) id PAA15182; Sat, 29 Jan 2000 15:04:51 -0500 (EST) To: Henk Smit Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] Concerns about ISIS in IP encapsulation References: <200001281906.UAA23005@kraak.cisco.com> From: chopps@merit.edu (Christian E. Hopps) Date: 29 Jan 2000 15:04:51 -0500 In-Reply-To: Henk Smit's message of "Fri, 28 Jan 2000 20:06:51 +0100 (MET)" Message-ID: Lines: 45 User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) XEmacs/20.4 (Emerald) 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 Henk Smit writes: > C) ISIS-in-IP improves portability of gated. This of course was my fault, and was not the intent of what I was trying to say. People who were at the meeting will recall that I was asked to give an example of system that might not have OSI available. I too quickly fired off, ``well e.g., someone using gated on unix''. I unfortunetly mentioned an implementation and so it seemed like a at least a few people ``latched'' that and didn't actually take the statement in context. GateD has support for OSI/CLNS. So this is not a GateD issue. As you point out: if your going to do an IS-IS, right now, you have to support CLNS encapsulation. > - Personally I don't care much about this. While people might not > expect this from a cisco employee, I do like open source software. > But I think that new technology should not be based on what is > easy to implement in one particular operating system (even if > it is Unix). > Also the fact remains that all current ISIS implementation run > native over layer2, so if gated or any other ISIS implementation > wants any acceptance in the real world, it still needs to implement > ISIS-in-layer2 encapsulation. A huge amount of networking research occurs on Unix systems. To toss Unix out as unimportant to the internet or routing protocols seems unwise to me. Some Unix vendors even have OSI support e.g., NetBSD, BSDI and I think Digital/Compaq. The BSD stacks, at least, are aging, poorly, mostly through lack of use. I think the only point I'd like to make WRT to this discussion is that: CLNS is dead to most of the world. Maybe IS-IS will continue to drag the dead horse along with it, and maybe IS-IS will continue to be a mostly unknown or unpopular routing protocol for most people. I think this would be sad. Why should such a nice protocol be restricted to only the elite in routing? Thanks, Chris. P.S. I found many of Henk's comments worthwhile and well though out, specifically with regards to issues facing us today. Other than what I've said above I choose not to disagree with any of them. _______________________________________________ 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 Jan 31 14:14: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 OAA13359 for ; Mon, 31 Jan 2000 14:14:46 -0500 (EST) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA84921; Mon, 31 Jan 2000 11:16:38 -0800 (PST) Received: from bacardi.vertel.com (zinfandel.vertel.com [207.238.118.22]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA84891 for ; Mon, 31 Jan 2000 11:16:36 -0800 (PST) Received: from bacardi.vertel.com ([127.0.0.1]) by bacardi.vertel.com (Post.Office MTA v3.5.2 release 221 ID# 0-61713U300L300S0V35) with SMTP id com; Mon, 31 Jan 2000 11:09:35 -0800 From: "Lester Ginsberg" To: hsmit@cisco.com CC: isis-wg@external.juniper.net In-reply-to: <200001281906.UAA23005@kraak.cisco.com> (message from Henk Smit on Fri, 28 Jan 2000 20:06:51 +0100 (MET)) Subject: Re: [Isis-wg] Concerns about ISIS in IP encapsulation X-Actually-From: "Les Ginsberg" Date: Mon, 31 Jan 2000 11:09:34 -0800 Message-ID: <20000131190934.AAA1009@bacardi.vertel.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 > > 5) Consistency towards other standards bodies. > The ISIS-over-IP draft recommends that routers use an LSPBufferSize > of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world > the Sonet Interoperability Forum (SIF) works on ISIS too. > They want to run ISIS over the DCC. The DCC channel is a part of > the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC > says that the DCC must use LAPD encaps, and that the *maximum* > MTU is 512 bytes. So you can't run ISIS over the DCC, because > some routers might send LSPs of size larger than 512 bytes. > Those LSPs can not be flooded over the DCC. > So the SIF wanted to add some cruft to 10589 that changes the > LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to > that. But if the ISIS WG in the IETF recommends to lower the > LSPBufferSize from 1492 to 1480, why not lower it to 512 ? > We will not be able to defend ourselves to changes like the > proposal from the SIF. > To be honest, I don't know about the latest status on the SIF > proposal. It actually might have been withdrawn. > To clarify the position presented by SIF - SIF never proposed changing the LSPBufferSize. The current spec allows values of 512-1492, though most folks prefer to use 1492 whenever possible - which, as Henk points out is not possible over the SONET DCC. What SIF did propose is to define TLVs to allow the detection of inconsistent provisioning throughout the area/domain. So at least someone would have a clue when a system generated a 1492 LSP and it couldn't be forwarded over a DCC link. A complete discussion of the SIF proposal can be found on the (renamed) NSIF web site: www.atis.org go to NSIF - then documents - then 1998 - then find SIF-AR-9802-031 (R7) or ftp from ftp.juniper.net:/pub/isis/lspsize.PDF The proposal is still viable - if the work on the 10589 second edition draft ever resumes (there is still hope, I think) - then this proposal will be part of the discussion. Les _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg