From isis-wg-admin@spider.juniper.net Fri Oct 5 07:34:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18821 for ; Fri, 5 Oct 2001 07:34:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA47235; Fri, 5 Oct 2001 04:43:40 -0700 (PDT) Received: from web13201.mail.yahoo.com (web13201.mail.yahoo.com [216.136.174.186]) by external.juniper.net (8.9.3/8.9.3) with SMTP id EAA47223 for ; Fri, 5 Oct 2001 04:42:53 -0700 (PDT) Message-ID: <20011005112831.78187.qmail@web13201.mail.yahoo.com> Received: from [203.200.20.224] by web13201.mail.yahoo.com via HTTP; Fri, 05 Oct 2001 04:28:31 PDT From: nabendu das To: isis-wg@spider.juniper.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-774477117-1002281311=:75661" Subject: [Isis-wg] spf implementation for level2 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 5 Oct 2001 04:28:31 -0700 (PDT) --0-774477117-1002281311=:75661 Content-Type: text/plain; charset=us-ascii hi list, about SPF implementation as per ISO -10589, TENT and PATH are of the form where N is a system identifier of 8 octet. But level2 SPF database & level2 forwarding database stores the address prefixs of the destination area. now my question is how to get area or area prefix after the SPF because we are operating the SPF only on system IDs. one thing can be done to get the area addresses from the LSP of the IS . but then how to arrange the SPF & forwarding database for level 2. for level1, we can hash on system ID & can store all the info of SPF & forwarding database in a single linked list for all the systems whose ID hashes to a particular hash value. u plz guide me for level 2 data structures for SPF & forwarding & also how to arrange those data structures. can we use hashing, & if so how is it done on the area addresses/ area prefixes. thanking in advance --------------------------------- Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. Yahoo! by Phone. --0-774477117-1002281311=:75661 Content-Type: text/html; charset=us-ascii

hi list,

about SPF implementation as per  ISO -10589, TENT and PATH are of the form <N, d(N), adj(N)> where N is a system identifier of 8 octet. But level2 SPF database & level2 forwarding database stores the address prefixs of the destination area. now my question is how to get area or area prefix after the SPF because we are operating the SPF only on system IDs. one thing can be done to get the area addresses from the LSP of the IS .  but then how to arrange the SPF & forwarding database for level 2. for level1, we can hash on system ID & can store all the info of SPF &  forwarding database in a single linked list for all the systems whose ID hashes to a particular hash value.

u plz guide me for level 2 data structures for SPF & forwarding & also how to arrange those data structures. can we use hashing, & if so how is it done on the area addresses/ area prefixes.

thanking in advance

 


Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. Yahoo! by Phone. --0-774477117-1002281311=:75661-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Oct 8 16:32:49 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01016 for ; Mon, 8 Oct 2001 16:32:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA68208; Mon, 8 Oct 2001 13:44:39 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA68196 for ; Mon, 8 Oct 2001 13:43:24 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f98KSOh87287 for ; Mon, 8 Oct 2001 16:28:24 -0400 (EDT) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f98KSOk94398 for ; Mon, 8 Oct 2001 16:28:24 -0400 (EDT) Received: from malibu.torrentnet.com (sherwin@localhost) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id f98KSGJ04443 for ; Mon, 8 Oct 2001 16:28:24 -0400 (EDT) Message-Id: <200110082028.f98KSGJ04443@malibu.torrentnet.com> To: isis-wg@spider.juniper.net From: Chris Sherwin Subject: [Isis-wg] Status of some drafts Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 08 Oct 2001 16:28:16 -0400 Hi, I am interested in knowing what the status of some work in this group is. In particular, I have been browsing the workgroup's mail archive and various proceedings trying to figure out what happened to the IS-IS over IPv4 and 3-way handshake efforts. It seems they have expired? They are listed as submitted for RFC status, but I cannot find any RFCs, although I can pick up old copies of the drafts. Even if expired, are these drafts supported widely in industry? Thanks, Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 05:10:19 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07056 for ; Wed, 10 Oct 2001 05:10:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA76996; Wed, 10 Oct 2001 02:21:40 -0700 (PDT) Received: from alpha-tli.procket.com (flowpoint.procket.com [209.140.237.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA76984 for ; Wed, 10 Oct 2001 02:20:45 -0700 (PDT) Received: (from tli@localhost) by alpha-tli.procket.com (8.9.3/8.9.3) id CAA22782; Wed, 10 Oct 2001 02:05:36 -0700 X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: alpha-tli.procket.com: tli set sender to tli@alpha-tli.procket.com using -f From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15300.3936.346196.194436@alpha-tli.procket.com> To: Chris Sherwin Cc: isis-wg@spider.juniper.net Subject: [Isis-wg] Status of some drafts In-Reply-To: <200110082028.f98KSGJ04443@malibu.torrentnet.com> References: <200110082028.f98KSGJ04443@malibu.torrentnet.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 02:05:36 -0700 Content-Transfer-Encoding: 7bit | I am interested in knowing what the status of some work in this group | is. In particular, I have been browsing the workgroup's mail archive | and various proceedings trying to figure out what happened to | the IS-IS over IPv4 and 3-way handshake efforts. | | It seems they have expired? They are listed as submitted for RFC status, | but I cannot find any RFCs, although I can pick up old copies of the | drafts. | | Even if expired, are these drafts supported widely in industry? Chris, I believe that we, as a group, came to the consensus that the IS-IS over IPv4 draft was not necessary. There were better ways of solving that particular problem. The 3-way handshake was being driven by Tony P. He's offline at the moment and I think we'll have to wait for his input. I'm hoping that it moves forward and I know that it's been implemented multiple times. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 07:52:38 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08002 for ; Wed, 10 Oct 2001 07:52:36 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA77692; Wed, 10 Oct 2001 05:03:39 -0700 (PDT) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA77680 for ; Wed, 10 Oct 2001 05:02:44 -0700 (PDT) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id NAA22067; Wed, 10 Oct 2001 13:49:37 +0200 From: Tony Przygienda Message-Id: <200110101149.NAA22067@net4u.net4u.ch> Subject: Re: [Isis-wg] Status of some drafts In-Reply-To: <15300.3936.346196.194436@alpha-tli.procket.com> from Tony Li at "Oct 10, 2001 2: 5:36 am" To: tli@Procket.com (Tony Li) Cc: sherwin@torrentnet.com, isis-wg@spider.juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 13:49:37 +0200 (MEST) Content-Transfer-Encoding: 7bit > > > | I am interested in knowing what the status of some work in this group > | is. In particular, I have been browsing the workgroup's mail archive > | and various proceedings trying to figure out what happened to > | the IS-IS over IPv4 and 3-way handshake efforts. > | > | It seems they have expired? They are listed as submitted for RFC status, > | but I cannot find any RFCs, although I can pick up old copies of the > | drafts. > | > | Even if expired, are these drafts supported widely in industry? > > > Chris, > > I believe that we, as a group, came to the consensus that the IS-IS over > IPv4 draft was not necessary. There were better ways of solving that > particular problem. yes, on ice now, if major reasons come up, will revive it. > The 3-way handshake was being driven by Tony P. He's offline at the moment > and I think we'll have to wait for his input. I'm hoping that it moves > forward and I know that it's been implemented multiple times. yes, multiple drafts are after last call stuck in 'will be RFC any minute now' status. Will check with AD later -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 09:36:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09857 for ; Wed, 10 Oct 2001 09:36:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA78147; Wed, 10 Oct 2001 06:49:39 -0700 (PDT) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA78135 for ; Wed, 10 Oct 2001 06:48:34 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Tony Przygienda'" Cc: sherwin@torrentnet.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Status of some drafts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 09:33:08 -0400 > > The 3-way handshake ... [is] > > stuck in 'will be RFC any minute now' status. Pity there is no way to have a semi-official link to docs that are between stools. I have a bootleg copy of draft-ietf-isis-3way-03.txt that I'd be happy to forward to those who need to implement but don't have any text. - jeff parker _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 15:04:39 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18641 for ; Wed, 10 Oct 2001 15:04:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79452; Wed, 10 Oct 2001 12:16:39 -0700 (PDT) Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by external.juniper.net (8.9.3/8.9.3) with SMTP id MAA79436 for ; Wed, 10 Oct 2001 12:15:10 -0700 (PDT) Received: from unknown (HELO c123294a) (38.169.12.100) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Oct 2001 19:00:09 -0000 X-Apparently-From: From: "Jing Zeng" To: "Tony Przygienda" , "Tony Li" Cc: , Subject: RE: [Isis-wg] Status of some drafts Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200110101149.NAA22067@net4u.net4u.ch> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 11:30:21 -0700 Content-Transfer-Encoding: 7bit Can any body explain the idea of three way handshake for ISIS or give some draft about this topic? (Sorry, I am new to this mailing-list) Jing -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Tony Przygienda Sent: Wednesday, October 10, 2001 4:50 AM To: Tony Li Cc: sherwin@torrentnet.com; isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Status of some drafts > > > | I am interested in knowing what the status of some work in this group > | is. In particular, I have been browsing the workgroup's mail archive > | and various proceedings trying to figure out what happened to > | the IS-IS over IPv4 and 3-way handshake efforts. > | > | It seems they have expired? They are listed as submitted for RFC status, > | but I cannot find any RFCs, although I can pick up old copies of the > | drafts. > | > | Even if expired, are these drafts supported widely in industry? > > > Chris, > > I believe that we, as a group, came to the consensus that the IS-IS over > IPv4 draft was not necessary. There were better ways of solving that > particular problem. yes, on ice now, if major reasons come up, will revive it. > The 3-way handshake was being driven by Tony P. He's offline at the moment > and I think we'll have to wait for his input. I'm hoping that it moves > forward and I know that it's been implemented multiple times. yes, multiple drafts are after last call stuck in 'will be RFC any minute now' status. Will check with AD later -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 15:26:46 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19150 for ; Wed, 10 Oct 2001 15:26:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79559; Wed, 10 Oct 2001 12:38:39 -0700 (PDT) Received: from bridge.axiowave.com ([216.49.69.50]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA79546 for ; Wed, 10 Oct 2001 12:37:29 -0700 (PDT) Message-ID: From: Jeff Parker To: "'Jing Zeng'" , Tony Przygienda , Tony Li Cc: sherwin@torrentnet.com, isis-wg@spider.juniper.net Subject: RE: [Isis-wg] Status of some drafts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 15:21:49 -0400 > Can any body explain the idea of three way handshake for ISIS or give > some draft about this topic? (Sorry, I am new to this mailing-list) > > Jing Jing - From the draft. The IS-IS protocol [1] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it. Once this occurs, each side then sends a Complete Sequence Number PDU (CSNP) to trigger database synchronization. Three failure modes are known. First, if the link goes down and then comes back up, or one of the systems restarts, and the CSNP packet is lost, and the network has a cut set of one through the link, the link state databases on either side of the link will not synchronize for a full LSP refresh period (up to eighteen hours). A second, more serious failure, is that if the link fails in only one direction, the failure will only be detected by one of the systems. Normally, this is not a serious issue; only one of the two systems will announce the adjacency in its link state packets, and the SPF algorithm will thus ignore the link. However, if there are two parallel links between systems and one of them fails in one direction, SPF will still calculate paths between the two systems, and the system that does not notice the failure will attempt to pass traffic down the failed link (in the direction that does not work). In addition, SONET links bring a third issue, which is that when SONET protection is used, a system may receive packets that are actually destined for a different system (or a different link on the same system). The receiving system may end up thinking that it has an adjacency with the remote system when in fact the remote system is adjacent with a third system. The solution proposed here ensures correct operation of the protocol over unreliable point-to-point links. As part of the solution to the three-way handshaking issue, a method is defined for supporting more than 256 point-to-point interfaces which is more robust than the ad hoc methods currently in use. I will send you a copy of the draft off-line. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 19:29:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23026 for ; Wed, 10 Oct 2001 19:29:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA80600; Wed, 10 Oct 2001 16:41:39 -0700 (PDT) Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA80588 for ; Wed, 10 Oct 2001 16:40:15 -0700 (PDT) Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4K3K4Z67>; Wed, 10 Oct 2001 19:24:31 -0400 Message-ID: <1117F7D44159934FB116E36F4ABF221B5A3CBD@celox-ma1-ems1.celoxnetworks.com> From: "Mammen, Biju" To: "'isis-wg@external.juniper.net'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C151E2.B0F80EB0" Subject: [Isis-wg] isisSysInstance Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 19:24:21 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C151E2.B0F80EB0 Content-Type: text/plain; charset="iso-8859-1" Hello all, This question seems to have popped up time and again but have gone unanswered on all occasions. Some guidance is really appreciated: a) What would be the implication of defining multiple instances of ISIS (as per draft-ietf-isis-wg-mib-05.txt)? b) Would all these instances work on the same Unified routing table or different ones? c) Would each of this instance have its own LSDatabases? d) Is this the same as CISCO's view of multi area support in a single router? ( A single Level 2 and 28 Level 1s) Thanks and regards Biju ------_=_NextPart_000_01C151E2.B0F80EB0 Content-Type: application/octet-stream; name="Mammen, Biju.vcf" Content-Disposition: attachment; filename="Mammen, Biju.vcf" BEGIN:VCARD VERSION:2.1 N:Mammen;Biju FN:Mammen, Biju ORG:;Development Engineering TITLE:MTS TEL;WORK;VOICE:508-305-7258 ADR;WORK:;2083;;Southborough;MA;;USA LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2083=0D=0ASouthborough, MA=0D=0AUSA EMAIL;PREF;INTERNET:bmammen@celoxnetworks.com REV:20010625T155925Z END:VCARD ------_=_NextPart_000_01C151E2.B0F80EB0-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 10 20:22:33 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23548 for ; Wed, 10 Oct 2001 20:22:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA80869; Wed, 10 Oct 2001 17:35:39 -0700 (PDT) Received: from usa04.ambernetworks.com ([63.121.148.133]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA80854 for ; Wed, 10 Oct 2001 17:34:24 -0700 (PDT) Received: by usa04.ambernetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 17:15:11 -0700 Message-ID: <9F4704BE89F7D4118A0F0002B328C36CA0F789@usa04.ambernetworks.com> From: Anand Ammundi To: "'Mammen, Biju'" , "'isis-wg@external.juniper.net'" Subject: RE: [Isis-wg] isisSysInstance MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 10 Oct 2001 17:15:11 -0700 Biju, my 2C on this... firstly most of the multi-instance routing protocol is fairly vendor specific. One of driving forces behind multi-instancing is from the VPN angle. So for example, BGP with 2547 would route between PE's, preserving the respective VPN route identities, while the local CE - PE IGP (typically RIP or OSPF) would multi-instance themselves, typically per VPN routing space and run independently. (and then there is that virtual router !!) IP for it's part would have to maintain it's routes seperately per VPN, but here is where things are different from vendor to vendor. One could have a many-to-many relationship between IGP and IP. so you could have multi-instance IS-IS over 1 IP as also an instance over an instance of IP. (do note when I say ISIS o IP, I mean the routing table part) However, whatever be the implementation, the LSP database would logically be separate for each instance and each instance runs on its own steam. I don't know much about Cisco multi-area support though. hope this helps. regards anand -----Original Message----- From: Mammen, Biju [mailto:bmammen@celoxnetworks.com] Sent: Wednesday, October 10, 2001 4:24 PM To: 'isis-wg@external.juniper.net' Subject: [Isis-wg] isisSysInstance Hello all, This question seems to have popped up time and again but have gone unanswered on all occasions. Some guidance is really appreciated: a) What would be the implication of defining multiple instances of ISIS (as per draft-ietf-isis-wg-mib-05.txt)? b) Would all these instances work on the same Unified routing table or different ones? c) Would each of this instance have its own LSDatabases? d) Is this the same as CISCO's view of multi area support in a single router? ( A single Level 2 and 28 Level 1s) Thanks and regards Biju _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Oct 11 05:08:18 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13814 for ; Thu, 11 Oct 2001 05:08:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA83045; Thu, 11 Oct 2001 02:19:40 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA83033 for ; Thu, 11 Oct 2001 02:18:23 -0700 (PDT) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id AC7DD1DCC65; Thu, 11 Oct 2001 02:03:17 -0700 (PDT) To: "Mammen, Biju" Cc: "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] isisSysInstance In-reply-to: Mail from "Mammen, Biju" dated Wed, 10 Oct 2001 19:24:21 EDT <1117F7D44159934FB116E36F4ABF221B5A3CBD@celox-ma1-ems1.celoxnetworks.com> From: Naiming Shen Message-Id: <20011011090317.AC7DD1DCC65@prattle.redback.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 11 Oct 2001 02:03:17 -0700 ] ]Hello all, ]This question seems to have popped up time and again but have gone ]unanswered on all occasions. Some guidance is really appreciated: Never seen those questions before. ] ]a) What would be the implication of defining multiple instances of ]ISIS (as per draft-ietf-isis-wg-mib-05.txt)? More work. ] ]b) Would all these instances work on the same Unified routing table or ]different ones? It depends. One can have a single instance using multiple routing/forwarding tables, such as in the case of M-ISIS(multi-topology isis). One can also have multiple instances using a single routing/forwarding table. A good example will be this: an ISP has an old backbone, and is building a new/next-generation backbone. Those two backbones use two seperate IGPs(ISIS in this case) at least before the complete migration. If some of the routers are shared among those two backbones, they may want to put two ISIS instances on those routers and they can share(or not to share) the same routing table, even though two ISISes don't talk to each other. Since the backbone ISIS usually handles router's loopback addresses and internal networks, they may not have overlapping address space, so there is no reason not to share the same routing table. Even in the case they have overlapping addresses, they can always set one instance to be prefered in distance and hopefully they go to the same destinations. They can even redistribute routes between the two instances, so they can run two seperate IGPs but only one instance of BGP. Just to make sure the redistributed routes are tagged properly or using some address mask scheme so that the routes will not be redistributed back to it's originating instance. In the case of VPN application, they have overlapping address space and also destinating to different places, then multiple instnaces need to have multiple routing tables. So in general, we can say N instances will result in M routing tables, where M and N > 0, depends on the network requirement and implementations. ] ]c) Would each of this instance have its own LSDatabases? this is always true. ] ]d) Is this the same as CISCO's view of multi area support in a single ]router? ]( A single Level 2 and 28 Level 1s) no comment on specific implementation. thanks. ] ]Thanks and regards ]Biju ] - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Thu Oct 11 10:06:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16709 for ; Thu, 11 Oct 2001 10:06:31 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA84282; Thu, 11 Oct 2001 07:18:40 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA84269 for ; Thu, 11 Oct 2001 07:17:01 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f9BE1q917882; Thu, 11 Oct 2001 10:01:52 -0400 (EDT) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f9BE1pf36190; Thu, 11 Oct 2001 10:01:51 -0400 (EDT) Received: from malibu.torrentnet.com (sherwin@localhost) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id f9BE1pv28204; Thu, 11 Oct 2001 10:01:51 -0400 (EDT) Message-Id: <200110111401.f9BE1pv28204@malibu.torrentnet.com> To: Tony Przygienda cc: isis-wg@spider.juniper.net Subject: Re: [Isis-wg] Status of some drafts In-Reply-To: Your message of "Wed, 10 Oct 2001 13:49:37 +0200." <200110101149.NAA22067@net4u.net4u.ch> From: Chris Sherwin Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Thu, 11 Oct 2001 10:01:51 -0400 Thanks to everyone for their quick responses to my question. So, I am wondering which other drafts are in this limbo state of being widely used/"will be RFC any minute now" like 3-way handshake, and which ones have been dropped as uninteresting, like IS-IS over IP? Chris. >> I believe that we, as a group, came to the consensus that the IS-IS over >> IPv4 draft was not necessary. There were better ways of solving that >> particular problem. > >yes, on ice now, if major reasons come up, will revive it. > >> The 3-way handshake was being driven by Tony P. He's offline at the moment >> and I think we'll have to wait for his input. I'm hoping that it moves >> forward and I know that it's been implemented multiple times. > >yes, multiple drafts are after last call stuck in 'will be RFC any minute >now' status. Will check with AD later > > -- tony > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Oct 16 19:38:50 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22909 for ; Tue, 16 Oct 2001 19:38:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16899; Tue, 16 Oct 2001 16:51:40 -0700 (PDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16887 for ; Tue, 16 Oct 2001 16:50:12 -0700 (PDT) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f9G6XKZ12401 for ; Tue, 16 Oct 2001 08:33:20 +0200 (MET DST) Message-ID: <3BCBD4AC.7E461711@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Isis-wg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] ManualL2Only Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 16 Oct 2001 08:33:16 +0200 Content-Transfer-Encoding: 7bit Hello, Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an explicit rule whether or not to include the network address of a manualL2only-enabled interface in the L1 LSP generated by a L1/L2 IS. Somebody has some ideas/good reasons for not including the address of that manualL2only interface in L1? Thanks, Koen _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 17 10:29:31 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25943 for ; Wed, 17 Oct 2001 10:29:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA20536; Wed, 17 Oct 2001 07:41:40 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA20524 for ; Wed, 17 Oct 2001 07:40:51 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9HEO9C05957; Wed, 17 Oct 2001 10:24:10 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-222-88.cisco.com [64.102.222.88]) by dingdong.cisco.com (Mirapoint) with ESMTP id ADZ00125; Wed, 17 Oct 2001 10:24:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20011017100605.0195ae70@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Koen Vermeulen From: Jeff Learman Subject: Re: [Isis-wg] ManualL2Only Cc: Isis-wg In-Reply-To: <3BCBD4AC.7E461711@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Oct 2001 10:19:39 -0400 At 02:33 AM 10/16/2001, Koen Vermeulen wrote: >Hello, > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an >explicit rule whether or not to include the network address >of a manualL2only-enabled interface in the L1 LSP generated >by a L1/L2 IS. >Somebody has some ideas/good reasons for not including >the address of that manualL2only interface in L1? Without consulting the specs, I can say that it doesn't make sense to include such an adjacency in the L1 LSP. If you do, then when you run SPF, you will either use "inadmissible" local knowledge when running SPF (thereby creating a different topology than other ISs) or else you won't heed the L2-only nature of the link and will forward L1 traffic on it. For example: A --- B ==== C ---- D | | E -- F -- G -- H -- I where all are in the same area, but the link between B and C is L2-only. If A wants to send data to D, it will send it to B. If B heeds the l2-only property, it would send it back to A. Note that B runs the SPF using the same data as everyone else: the LSDB. It uses its adjacency database also, true, but only to preload "tent" (or is it "paths", it's been a while). B needs to advertise links consistently with how it would use them itself, so that the area topology is identical for all ISs in the area. Regards, Jeff >Thanks, >Koen > >_______________________________________________ >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@spider.juniper.net Wed Oct 17 11:17:58 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27219 for ; Wed, 17 Oct 2001 11:17:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA20759; Wed, 17 Oct 2001 08:30:39 -0700 (PDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA20744 for ; Wed, 17 Oct 2001 08:29:44 -0700 (PDT) Received: from alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f9HFDav19143; Wed, 17 Oct 2001 17:13:36 +0200 (MET DST) Message-ID: <3BCDA01A.C97B057@alcatel.be> From: Koen Vermeulen X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Learman CC: Isis-wg Subject: Re: [Isis-wg] ManualL2Only References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Oct 2001 17:13:30 +0200 Content-Transfer-Encoding: 7bit Hello Jeff, I think I have to be more specific, because it seems that my question was not understood completely. I will try to explain what I meant with an example. Suppose you have following 3 IS's: 1 2 A ----- B ----- C L1 L1/L2 L2 where link 2 has network address x and is configured as manualL2only. This means that B will only try to form a L2 adjacency with C. My question is now: is it allowed to add address x in an ip reachability TLV to the L1 LSP of B or will this lead to some problems? Right now, I can't think of any problems adding the network address of a manualL2only to L1. I would even expect that this way of working is the correct one because of the fact that IS-IS areas cut through interfaces and not through routers as is done in OSPF. I hope this makes my question more clear? Thanks, Koen Jeff Learman wrote: > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > >Hello, > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > >explicit rule whether or not to include the network address > >of a manualL2only-enabled interface in the L1 LSP generated > >by a L1/L2 IS. > >Somebody has some ideas/good reasons for not including > >the address of that manualL2only interface in L1? > > Without consulting the specs, I can say that it doesn't make > sense to include such an adjacency in the L1 LSP. If you do, > then when you run SPF, you will either use "inadmissible" > local knowledge when running SPF (thereby creating a different > topology than other ISs) or else you won't heed the L2-only > nature of the link and will forward L1 traffic on it. > > For example: > > A --- B ==== C ---- D > | | > E -- F -- G -- H -- I > > where all are in the same area, but the link between B and C > is L2-only. If A wants to send data to D, it will send it to > B. If B heeds the l2-only property, it would send it back to A. > > Note that B runs the SPF using the same data as everyone else: > the LSDB. It uses its adjacency database also, true, but only > to preload "tent" (or is it "paths", it's been a while). > > B needs to advertise links consistently with how it would use > them itself, so that the area topology is identical for all ISs > in the area. > > Regards, > Jeff > > >Thanks, > >Koen > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 17 11:34:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27587 for ; Wed, 17 Oct 2001 11:34:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA20869; Wed, 17 Oct 2001 08:47:40 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA20838 for ; Wed, 17 Oct 2001 08:46:09 -0700 (PDT) Received: (qmail 7093 invoked from network); 17 Oct 2001 15:30:19 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Oct 2001 15:30:19 -0000 From: "Ken Larmer" To: "Jeff Learman" , "Koen Vermeulen" Cc: "Isis-wg" Subject: RE: [Isis-wg] ManualL2Only Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <4.3.2.7.2.20011017100605.0195ae70@dingdong.cisco.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Oct 2001 11:33:31 -0400 Content-Transfer-Encoding: 7bit Hi Koen, I found the following conflicting references. ISO-10589 V1 states the following: -In the Intermediate System Neighbours option the set of Intermediate system IDs of neighbouring In termediate systems formed from: The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state Up, on circuits of type Point-Point, In or Out, with xneighbourSystemType L1 Intermediate System xneighbourSystemType L2 Intermediate System and adjacencyUsage Level 2 or Level1 and 2. ISO-10589 V2 states the following: 7.3.7 Generation of level 1 LSPs (non-pseudonode) - In the Intermediate System Neighbours option - the set of Intermediate system IDs of neighbouring Intermediate systems formed from . The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state "Up", on circuits of type "ptToPt", "staticIn", or "staticOut", with x neighbourSystemType "L1 Intermediate System" x neighbourSystemType "L2 Intermediate System" and adjacencyUsage "Level 1" or "Level 1 and 2". I believe that this section should read as follows: 7.3.7 Generation of level 1 LSPs (non-pseudonode) - In the Intermediate System Neighbours option - the set of Intermediate system IDs of neighbouring Intermediate systems formed from . The set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state "Up", on circuits of type "ptToPt", "staticIn", or "staticOut", with x neighbourSystemType "L1 Intermediate System" RFC-1195 states the following for the IP Internal Reachability Information TLV for both L1 and L2 LSPs. IP Internal Reachability Information -- IP addresses within the routing domain reachable directly via one or more interfaces on this Intermediate system. I believe this should read as follows for L1 LSPs IP Internal Reachability Information -- IP addresses within the L1 routing subdomain reachable directly via one or more interfaces on this Intermediate system. Cheers, Ken Larmer CommSense Networks www.commsense.net > -----Original Message----- > From: isis-wg-admin@external.juniper.net > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > Sent: Wednesday, October 17, 2001 10:20 AM > To: Koen Vermeulen > Cc: Isis-wg > Subject: Re: [Isis-wg] ManualL2Only > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > >Hello, > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > >explicit rule whether or not to include the network address > >of a manualL2only-enabled interface in the L1 LSP generated > >by a L1/L2 IS. > >Somebody has some ideas/good reasons for not including > >the address of that manualL2only interface in L1? > > Without consulting the specs, I can say that it doesn't make > sense to include such an adjacency in the L1 LSP. If you do, > then when you run SPF, you will either use "inadmissible" > local knowledge when running SPF (thereby creating a different > topology than other ISs) or else you won't heed the L2-only > nature of the link and will forward L1 traffic on it. > > For example: > > A --- B ==== C ---- D > | | > E -- F -- G -- H -- I > > where all are in the same area, but the link between B and C > is L2-only. If A wants to send data to D, it will send it to > B. If B heeds the l2-only property, it would send it back to A. > > Note that B runs the SPF using the same data as everyone else: > the LSDB. It uses its adjacency database also, true, but only > to preload "tent" (or is it "paths", it's been a while). > > B needs to advertise links consistently with how it would use > them itself, so that the area topology is identical for all ISs > in the area. > > Regards, > Jeff > > > >Thanks, > >Koen > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 17 11:49:00 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27941 for ; Wed, 17 Oct 2001 11:49:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA20980; Wed, 17 Oct 2001 09:01:40 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA20968 for ; Wed, 17 Oct 2001 09:00:35 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9HFhuC11880; Wed, 17 Oct 2001 11:43:56 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-222-88.cisco.com [64.102.222.88]) by dingdong.cisco.com (Mirapoint) with ESMTP id ADZ02456; Wed, 17 Oct 2001 11:44:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20011017112619.0193ea88@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Koen Vermeulen From: Jeff Learman Subject: Re: [Isis-wg] ManualL2Only Cc: Isis-wg In-Reply-To: <3BCDA01A.C97B057@alcatel.be> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Oct 2001 11:44:32 -0400 Reading your original email more carefully, I see I made a mistake. You were talking about the interface address, not the adjacency. This case would not be covered in ISO 10589, because in OSI, interfaces do not have network layer addresses. It's only an issue for IP addresses. In general, I would prefer using an unnumbered interface between areas, if possible, to avoid wasting a subnet address that can't be wholly within a single area, and therefore able to be summarized. This is a minor point, and it's often not possible to use an unnumbered interface, so the question remains. I don't see any harm in including the address, and I don't see any benefit to omitting it. I don't have a lot of experience in integrated IS-IS, though, so you may want to wait for other opinions. Regards, Jeff Disclaimer: I am not working on IS-IS at Cisco nor am I familiar with Cisco's IS-IS implementation. Just trying to keep brain cells from a previous job alive. At 11:13 AM 10/17/2001, Koen Vermeulen wrote: >Hello Jeff, > >I think I have to be more specific, because it seems that >my question was not understood completely. I will try to >explain what I meant with an example. > >Suppose you have following 3 IS's: > > 1 2 >A ----- B ----- C >L1 L1/L2 L2 > >where link 2 has network address x and is configured as >manualL2only. This means that B will only try to form >a L2 adjacency with C. >My question is now: is it allowed to add address x in an ip >reachability TLV to the L1 LSP of B or will this lead to >some problems? >Right now, I can't think of any problems adding the >network address of a manualL2only to L1. I would >even expect that this way of working is the correct >one because of the fact that IS-IS areas cut through >interfaces and not through routers as is done in OSPF. > >I hope this makes my question more clear? > >Thanks, >Koen > >Jeff Learman wrote: > >> At 02:33 AM 10/16/2001, Koen Vermeulen wrote: >> >Hello, >> > >> >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an >> >explicit rule whether or not to include the network address >> >of a manualL2only-enabled interface in the L1 LSP generated >> >by a L1/L2 IS. >> >Somebody has some ideas/good reasons for not including >> >the address of that manualL2only interface in L1? >> >> Without consulting the specs, I can say that it doesn't make >> sense to include such an adjacency in the L1 LSP. If you do, >> then when you run SPF, you will either use "inadmissible" >> local knowledge when running SPF (thereby creating a different >> topology than other ISs) or else you won't heed the L2-only >> nature of the link and will forward L1 traffic on it. >> >> For example: >> >> A --- B ==== C ---- D >> | | >> E -- F -- G -- H -- I >> >> where all are in the same area, but the link between B and C >> is L2-only. If A wants to send data to D, it will send it to >> B. If B heeds the l2-only property, it would send it back to A. >> >> Note that B runs the SPF using the same data as everyone else: >> the LSDB. It uses its adjacency database also, true, but only >> to preload "tent" (or is it "paths", it's been a while). >> >> B needs to advertise links consistently with how it would use >> them itself, so that the area topology is identical for all ISs >> in the area. >> >> Regards, >> Jeff >> >> >Thanks, >> >Koen >> > >> >_______________________________________________ >> >Isis-wg mailing list - Isis-wg@external.juniper.net >> >http://external.juniper.net/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 17 22:22:56 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11958 for ; Wed, 17 Oct 2001 22:22:55 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA23465; Wed, 17 Oct 2001 19:35:40 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA23450 for ; Wed, 17 Oct 2001 19:34:20 -0700 (PDT) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA06059; Wed, 17 Oct 2001 19:17:59 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <4WXWT6TV>; Wed, 17 Oct 2001 19:17:59 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A748@avalon.pluris.com> From: Les Ginsberg To: "'Ken Larmer'" , Jeff Learman , Koen Vermeulen Cc: Isis-wg Subject: RE: [Isis-wg] ManualL2Only MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 17 Oct 2001 19:17:49 -0700 The text in both ISO 10589 V1 and V2 is correct. Please see my comments in line. Les > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Wednesday, October 17, 2001 8:34 AM > To: Jeff Learman; Koen Vermeulen > Cc: Isis-wg > Subject: RE: [Isis-wg] ManualL2Only > > > Hi Koen, > > I found the following conflicting references. > > ISO-10589 V1 states the following: > > -In the Intermediate System Neighbours option the set of > Intermediate system > IDs of neighbouring In > termediate systems formed from: > > The set of neighbourSystemIDs with an appended zero octet (indicating > non-pseudonode) > from adjacencies in the state Up, on circuits of type > Point-Point, In or > Out, with > > xneighbourSystemType L1 Intermediate System > > xneighbourSystemType L2 Intermediate System and > adjacencyUsage Level 2 or > Level1 and 2. > You have misquoted the text from 7.3.7. It actually states: x neighbourSystemType L2 Intermediate System and adjacencyUsage Level 1 or Level1 and 2. This text is identical to the text found in V2 which you correctly quote below. > > ISO-10589 V2 states the following: > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > - In the Intermediate System Neighbours option - the set > of Intermediate > system IDs of neighbouring Intermediate systems formed from > > . The set of neighbourSystemIDs with an appended zero > octet (indicating > non-pseudonode) from adjacencies in the state "Up", on > circuits of type > "ptToPt", "staticIn", or "staticOut", with > > x neighbourSystemType "L1 Intermediate System" > > x neighbourSystemType "L2 Intermediate System" and > adjacencyUsage "Level 1" > or "Level 1 and 2". > > I believe that this section should read as follows: > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > - In the Intermediate System Neighbours option - the set > of Intermediate > system IDs of neighbouring Intermediate systems formed from > > . The set of neighbourSystemIDs with an appended zero > octet (indicating > non-pseudonode) from adjacencies in the state "Up", on > circuits of type > "ptToPt", "staticIn", or "staticOut", with > > x neighbourSystemType "L1 Intermediate System" > This is not correct. On a point-point circuit, a single adjacency is formed and the adjacency usage is set based upon the advertised circuit types (L1, L2-only, L1 and L2) and whether the neighbors share an area address. If one system is an L1 IS or an L2 IS with circuit type L1-only, then it would set circuit type to L1 and adjacency usage could only be L1. If both neighbors are L2 ISs and do not have the circuit set to L2-only, then adjacency usage will be Level 1 and 2. In both cases you would want to advertise this neighbor in your L1 LSP since it is reachable at this level. It is probably somewhat confusing to talk about "neighborSystemType" since what is actually advertised in IIH PDUs is "circuit type". While the IS type bounds the possible values for circuit type, it is not equivalent. A Level 2 IS is assumed to operate as an L1 IS in its area and can therefore use the circuit for both L1 and L2 traffic (default behavior) or designate the circuit as L1 only or L2 only. An L1 IS of course, can only use the circuit for L1 traffic. On LANs, separate adjacencies are formed for Level 1 and Level 2 and the adjacency usage can be implicitly set to L1 and L2 respectively. (This is not explicitly stated in the spec.) > > RFC-1195 states the following for the IP Internal > Reachability Information > TLV for both L1 and L2 LSPs. > > IP Internal Reachability Information -- IP addresses within > the routing > domain reachable directly via one or more interfaces on this > Intermediate > system. > > I believe this should read as follows for L1 LSPs > > IP Internal Reachability Information -- IP addresses within > the L1 routing > subdomain reachable directly via one or more interfaces on > this Intermediate > system. > > > > Cheers, > Ken Larmer > CommSense Networks > www.commsense.net > > > > -----Original Message----- > > From: isis-wg-admin@external.juniper.net > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > > Sent: Wednesday, October 17, 2001 10:20 AM > > To: Koen Vermeulen > > Cc: Isis-wg > > Subject: Re: [Isis-wg] ManualL2Only > > > > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > > >Hello, > > > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > > >explicit rule whether or not to include the network address > > >of a manualL2only-enabled interface in the L1 LSP generated > > >by a L1/L2 IS. > > >Somebody has some ideas/good reasons for not including > > >the address of that manualL2only interface in L1? > > > > Without consulting the specs, I can say that it doesn't make > > sense to include such an adjacency in the L1 LSP. If you do, > > then when you run SPF, you will either use "inadmissible" > > local knowledge when running SPF (thereby creating a different > > topology than other ISs) or else you won't heed the L2-only > > nature of the link and will forward L1 traffic on it. > > > > For example: > > > > A --- B ==== C ---- D > > | | > > E -- F -- G -- H -- I > > > > where all are in the same area, but the link between B and C > > is L2-only. If A wants to send data to D, it will send it to > > B. If B heeds the l2-only property, it would send it back to A. > > > > Note that B runs the SPF using the same data as everyone else: > > the LSDB. It uses its adjacency database also, true, but only > > to preload "tent" (or is it "paths", it's been a while). > > > > B needs to advertise links consistently with how it would use > > them itself, so that the area topology is identical for all ISs > > in the area. > > > > Regards, > > Jeff > > > > > > >Thanks, > > >Koen > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Oct 19 09:06:40 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17735 for ; Fri, 19 Oct 2001 09:06:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA31842; Fri, 19 Oct 2001 06:19:41 -0700 (PDT) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA31830 for ; Fri, 19 Oct 2001 06:18:14 -0700 (PDT) Received: (qmail 80159 invoked from network); 19 Oct 2001 13:02:09 -0000 Received: from unknown (HELO NEIL) ([66.92.83.66]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Oct 2001 13:02:09 -0000 From: "Ken Larmer" To: "Les Ginsberg" , "Jeff Learman" , "Koen Vermeulen" Cc: "Isis-wg" Subject: RE: [Isis-wg] ManualL2Only Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <17C81AD1F1FED411991E006008F6D1CAA5A748@avalon.pluris.com> Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Oct 2001 09:05:24 -0400 Content-Transfer-Encoding: 7bit Hi Les, Please see my comments inline. Cheers, Ken Larmer > -----Original Message----- > From: Les Ginsberg [mailto:ginsberg@pluris.com] > Sent: Wednesday, October 17, 2001 10:18 PM > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen > Cc: Isis-wg > Subject: RE: [Isis-wg] ManualL2Only > > > The text in both ISO 10589 V1 and V2 is correct. Please see my comments in > line. > > Les > > > > -----Original Message----- > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > Sent: Wednesday, October 17, 2001 8:34 AM > > To: Jeff Learman; Koen Vermeulen > > Cc: Isis-wg > > Subject: RE: [Isis-wg] ManualL2Only > > > > > > Hi Koen, > > > > I found the following conflicting references. > > > > ISO-10589 V1 states the following: > > > > -In the Intermediate System Neighbours option the set of > > Intermediate system > > IDs of neighbouring In > > termediate systems formed from: > > > > The set of neighbourSystemIDs with an appended zero octet (indicating > > non-pseudonode) > > from adjacencies in the state Up, on circuits of type > > Point-Point, In or > > Out, with > > > > xneighbourSystemType L1 Intermediate System > > > > xneighbourSystemType L2 Intermediate System and > > adjacencyUsage Level 2 or > > Level1 and 2. > > > > You have misquoted the text from 7.3.7. It actually states: > > x neighbourSystemType L2 Intermediate System and > adjacencyUsage Level 1 or > Level1 and 2. > Les, here is a cut and paste from RFC-1142 (Integrated IS-IS) 7.3.7 Generation of Level 1 LSPs (non-pseudonode) The Level 1 Link State PDU not generated on behalf of a pseudonode contains the following information in its variable length fields. ... -In the Intermediate System Neighbours option the set of Intermediate system IDs of neighbouring In termediate systems formed from: xThe set of neighbourSystemIDs with an appended zero octet (indicating non-pseudonode) from adjacencies in the state Up, on circuits of type Point-Point, In or Out, with xneighbourSystemType L1 Intermediate System xneighbourSystemType L2 Intermediate System and adjacencyUsage Level 2 or Level1 and 2. I believe this is different from the V2 spec? > This text is identical to the text found in V2 which you correctly quote > below. > > > > > ISO-10589 V2 states the following: > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > - In the Intermediate System Neighbours option - the set > > of Intermediate > > system IDs of neighbouring Intermediate systems formed from > > > > . The set of neighbourSystemIDs with an appended zero > > octet (indicating > > non-pseudonode) from adjacencies in the state "Up", on > > circuits of type > > "ptToPt", "staticIn", or "staticOut", with > > > > x neighbourSystemType "L1 Intermediate System" > > > > x neighbourSystemType "L2 Intermediate System" and > > adjacencyUsage "Level 1" > > or "Level 1 and 2". > > > > I believe that this section should read as follows: > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > - In the Intermediate System Neighbours option - the set > > of Intermediate > > system IDs of neighbouring Intermediate systems formed from > > > > . The set of neighbourSystemIDs with an appended zero > > octet (indicating > > non-pseudonode) from adjacencies in the state "Up", on > > circuits of type > > "ptToPt", "staticIn", or "staticOut", with > > > > x neighbourSystemType "L1 Intermediate System" > > > > This is not correct. > > On a point-point circuit, a single adjacency is formed and the adjacency > usage is set based upon the advertised circuit types (L1, L2-only, L1 and > L2) and whether the neighbors share an area address. If one > system is an L1 > IS or an L2 IS with circuit type L1-only, then it would set > circuit type to > L1 and adjacency usage could only be L1. If both neighbors are L2 > ISs and do > not have the circuit set to L2-only, then adjacency usage will be Level 1 > and 2. In both cases you would want to advertise this neighbor in your L1 > LSP since it is reachable at this level. Les, yes you are correct! I was looking at the text in the V1 spec when I made the above statement. Of course, my proposed text was still wrong! The V2 spec is correct! > It is probably somewhat confusing to talk about "neighborSystemType" since > what is actually advertised in IIH PDUs is "circuit type". While > the IS type > bounds the possible values for circuit type, it is not > equivalent. A Level 2 > IS is assumed to operate as an L1 IS in its area and can therefore use the > circuit for both L1 and L2 traffic (default behavior) or designate the > circuit as L1 only or L2 only. An L1 IS of course, can only use > the circuit > for L1 traffic. > > On LANs, separate adjacencies are formed for Level 1 and Level 2 and the > adjacency usage can be implicitly set to L1 and L2 respectively. (This is > not explicitly stated in the spec.) > > > > > RFC-1195 states the following for the IP Internal > > Reachability Information > > TLV for both L1 and L2 LSPs. > > > > IP Internal Reachability Information -- IP addresses within > > the routing > > domain reachable directly via one or more interfaces on this > > Intermediate > > system. > > > > I believe this should read as follows for L1 LSPs > > > > IP Internal Reachability Information -- IP addresses within > > the L1 routing > > subdomain reachable directly via one or more interfaces on > > this Intermediate > > system. > > Any comments on the above text??? > > > > Cheers, > > Ken Larmer > > CommSense Networks > > www.commsense.net > > > > > > > -----Original Message----- > > > From: isis-wg-admin@external.juniper.net > > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman > > > Sent: Wednesday, October 17, 2001 10:20 AM > > > To: Koen Vermeulen > > > Cc: Isis-wg > > > Subject: Re: [Isis-wg] ManualL2Only > > > > > > > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > > > >Hello, > > > > > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > > > >explicit rule whether or not to include the network address > > > >of a manualL2only-enabled interface in the L1 LSP generated > > > >by a L1/L2 IS. > > > >Somebody has some ideas/good reasons for not including > > > >the address of that manualL2only interface in L1? > > > > > > Without consulting the specs, I can say that it doesn't make > > > sense to include such an adjacency in the L1 LSP. If you do, > > > then when you run SPF, you will either use "inadmissible" > > > local knowledge when running SPF (thereby creating a different > > > topology than other ISs) or else you won't heed the L2-only > > > nature of the link and will forward L1 traffic on it. > > > > > > For example: > > > > > > A --- B ==== C ---- D > > > | | > > > E -- F -- G -- H -- I > > > > > > where all are in the same area, but the link between B and C > > > is L2-only. If A wants to send data to D, it will send it to > > > B. If B heeds the l2-only property, it would send it back to A. > > > > > > Note that B runs the SPF using the same data as everyone else: > > > the LSDB. It uses its adjacency database also, true, but only > > > to preload "tent" (or is it "paths", it's been a while). > > > > > > B needs to advertise links consistently with how it would use > > > them itself, so that the area topology is identical for all ISs > > > in the area. > > > > > > Regards, > > > Jeff > > > > > > > > > >Thanks, > > > >Koen > > > > > > > >_______________________________________________ > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Oct 19 15:13:54 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28417 for ; Fri, 19 Oct 2001 15:13:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA33329; Fri, 19 Oct 2001 12:21:41 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA33317 for ; Fri, 19 Oct 2001 12:20:57 -0700 (PDT) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA28572; Fri, 19 Oct 2001 12:04:23 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <4WXW4B6X>; Fri, 19 Oct 2001 12:04:23 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A752@avalon.pluris.com> From: Les Ginsberg To: "'Ken Larmer'" , Les Ginsberg , Jeff Learman , Koen Vermeulen Cc: Isis-wg Subject: RE: [Isis-wg] ManualL2Only MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Oct 2001 12:04:22 -0700 Ken - Using RFC 1142 as a reference is something I would strongly discourage. It was an early draft of ISO 10589 - many corrections were made before the 1992 ISO standard was published. Clearly the section you quoted was one of them. When I accused you of misquoting, I was assuming you were referencing the 1992 spec. Certainly, one should never refer to RFC 1142 as ISO 10589 V1 - that designation rightfully belongs to the 1992 ISO standard. I would also go one step further and encourage folks to use the 2001 V2 draft. This includes corrections to the 1992 spec. ftp.cisco.com/pub/rfc/ISO/ISO10589v2-2001-07-04.pdf As for the issue of advertising directly connected reachability for L2-only circuits in L1 LSPs, I am not in favor of that. L1 routers are supposed to direct packets destined for addresses "out of the area" to the nearest L2 router. Including L2-only reachability deviates from that model - and I see no compelling reason to do so. Les > -----Original Message----- > From: Ken Larmer [mailto:Larmer@CommSense.Net] > Sent: Friday, October 19, 2001 6:05 AM > To: Les Ginsberg; Jeff Learman; Koen Vermeulen > Cc: Isis-wg > Subject: RE: [Isis-wg] ManualL2Only > > > Hi Les, > > Please see my comments inline. > > Cheers, > Ken Larmer > > > -----Original Message----- > > From: Les Ginsberg [mailto:ginsberg@pluris.com] > > Sent: Wednesday, October 17, 2001 10:18 PM > > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen > > Cc: Isis-wg > > Subject: RE: [Isis-wg] ManualL2Only > > > > > > The text in both ISO 10589 V1 and V2 is correct. Please see > my comments in > > line. > > > > Les > > > > > > > -----Original Message----- > > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > > > Sent: Wednesday, October 17, 2001 8:34 AM > > > To: Jeff Learman; Koen Vermeulen > > > Cc: Isis-wg > > > Subject: RE: [Isis-wg] ManualL2Only > > > > > > > > > Hi Koen, > > > > > > I found the following conflicting references. > > > > > > ISO-10589 V1 states the following: > > > > > > -In the Intermediate System Neighbours option the set of > > > Intermediate system > > > IDs of neighbouring In > > > termediate systems formed from: > > > > > > The set of neighbourSystemIDs with an appended zero octet > (indicating > > > non-pseudonode) > > > from adjacencies in the state Up, on circuits of type > > > Point-Point, In or > > > Out, with > > > > > > xneighbourSystemType L1 Intermediate System > > > > > > xneighbourSystemType L2 Intermediate System and > > > adjacencyUsage Level 2 or > > > Level1 and 2. > > > > > > > You have misquoted the text from 7.3.7. It actually states: > > > > x neighbourSystemType L2 Intermediate System and > > adjacencyUsage Level 1 or > > Level1 and 2. > > > > Les, here is a cut and paste from RFC-1142 (Integrated IS-IS) > > 7.3.7 Generation of Level 1 LSPs (non-pseudonode) > The Level 1 Link State PDU not generated on behalf of a > pseudonode contains > the following information in its variable length fields. > ... > -In the Intermediate System Neighbours option the set of > Intermediate system > IDs of neighbouring In > termediate systems formed from: > > xThe set of neighbourSystemIDs with an appended zero octet (indicating > non-pseudonode) > from adjacencies in the state Up, on circuits of type > Point-Point, In or > Out, with > > xneighbourSystemType L1 Intermediate System > > xneighbourSystemType L2 Intermediate System and > adjacencyUsage Level 2 or > Level1 and 2. > > I believe this is different from the V2 spec? > > > This text is identical to the text found in V2 which you > correctly quote > > below. > > > > > > > > ISO-10589 V2 states the following: > > > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > > > - In the Intermediate System Neighbours option - the set > > > of Intermediate > > > system IDs of neighbouring Intermediate systems formed from > > > > > > . The set of neighbourSystemIDs with an appended zero > > > octet (indicating > > > non-pseudonode) from adjacencies in the state "Up", on > > > circuits of type > > > "ptToPt", "staticIn", or "staticOut", with > > > > > > x neighbourSystemType "L1 Intermediate System" > > > > > > x neighbourSystemType "L2 Intermediate System" and > > > adjacencyUsage "Level 1" > > > or "Level 1 and 2". > > > > > > I believe that this section should read as follows: > > > > > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > > > > > > - In the Intermediate System Neighbours option - the set > > > of Intermediate > > > system IDs of neighbouring Intermediate systems formed from > > > > > > . The set of neighbourSystemIDs with an appended zero > > > octet (indicating > > > non-pseudonode) from adjacencies in the state "Up", on > > > circuits of type > > > "ptToPt", "staticIn", or "staticOut", with > > > > > > x neighbourSystemType "L1 Intermediate System" > > > > > > > This is not correct. > > > > On a point-point circuit, a single adjacency is formed and > the adjacency > > usage is set based upon the advertised circuit types (L1, > L2-only, L1 and > > L2) and whether the neighbors share an area address. If one > > system is an L1 > > IS or an L2 IS with circuit type L1-only, then it would set > > circuit type to > > L1 and adjacency usage could only be L1. If both neighbors are L2 > > ISs and do > > not have the circuit set to L2-only, then adjacency usage > will be Level 1 > > and 2. In both cases you would want to advertise this > neighbor in your L1 > > LSP since it is reachable at this level. > > Les, yes you are correct! I was looking at the text in the V1 > spec when I > made the above statement. Of course, my proposed text was > still wrong! The > V2 spec is correct! > > > It is probably somewhat confusing to talk about > "neighborSystemType" since > > what is actually advertised in IIH PDUs is "circuit type". While > > the IS type > > bounds the possible values for circuit type, it is not > > equivalent. A Level 2 > > IS is assumed to operate as an L1 IS in its area and can > therefore use the > > circuit for both L1 and L2 traffic (default behavior) or > designate the > > circuit as L1 only or L2 only. An L1 IS of course, can only use > > the circuit > > for L1 traffic. > > > > On LANs, separate adjacencies are formed for Level 1 and > Level 2 and the > > adjacency usage can be implicitly set to L1 and L2 > respectively. (This is > > not explicitly stated in the spec.) > > > > > > > > RFC-1195 states the following for the IP Internal > > > Reachability Information > > > TLV for both L1 and L2 LSPs. > > > > > > IP Internal Reachability Information -- IP addresses within > > > the routing > > > domain reachable directly via one or more interfaces on this > > > Intermediate > > > system. > > > > > > I believe this should read as follows for L1 LSPs > > > > > > IP Internal Reachability Information -- IP addresses within > > > the L1 routing > > > subdomain reachable directly via one or more interfaces on > > > this Intermediate > > > system. > > > > > Any comments on the above text??? > > > > > > > Cheers, > > > Ken Larmer > > > CommSense Networks > > > www.commsense.net > > > > > > > > > > -----Original Message----- > > > > From: isis-wg-admin@external.juniper.net > > > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of > Jeff Learman > > > > Sent: Wednesday, October 17, 2001 10:20 AM > > > > To: Koen Vermeulen > > > > Cc: Isis-wg > > > > Subject: Re: [Isis-wg] ManualL2Only > > > > > > > > > > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > > > > >Hello, > > > > > > > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > > > > >explicit rule whether or not to include the network address > > > > >of a manualL2only-enabled interface in the L1 LSP generated > > > > >by a L1/L2 IS. > > > > >Somebody has some ideas/good reasons for not including > > > > >the address of that manualL2only interface in L1? > > > > > > > > Without consulting the specs, I can say that it doesn't make > > > > sense to include such an adjacency in the L1 LSP. If you do, > > > > then when you run SPF, you will either use "inadmissible" > > > > local knowledge when running SPF (thereby creating a different > > > > topology than other ISs) or else you won't heed the L2-only > > > > nature of the link and will forward L1 traffic on it. > > > > > > > > For example: > > > > > > > > A --- B ==== C ---- D > > > > | | > > > > E -- F -- G -- H -- I > > > > > > > > where all are in the same area, but the link between B and C > > > > is L2-only. If A wants to send data to D, it will send it to > > > > B. If B heeds the l2-only property, it would send it back to A. > > > > > > > > Note that B runs the SPF using the same data as everyone else: > > > > the LSDB. It uses its adjacency database also, true, but only > > > > to preload "tent" (or is it "paths", it's been a while). > > > > > > > > B needs to advertise links consistently with how it would use > > > > them itself, so that the area topology is identical for all ISs > > > > in the area. > > > > > > > > Regards, > > > > Jeff > > > > > > > > > > > > >Thanks, > > > > >Koen > > > > > > > > > >_______________________________________________ > > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Oct 19 16:40:44 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00835 for ; Fri, 19 Oct 2001 16:40:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA33728; Fri, 19 Oct 2001 13:54:41 -0700 (PDT) Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA33716 for ; Fri, 19 Oct 2001 13:53:01 -0700 (PDT) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA03251; Fri, 19 Oct 2001 13:36:48 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id <4WXW4C2D>; Fri, 19 Oct 2001 13:36:48 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CAA5A754@avalon.pluris.com> From: Les Ginsberg To: "'Jeff Learman'" Cc: "'Isis-wg'" Subject: RE: [Isis-wg] ManualL2Only MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Oct 2001 13:36:48 -0700 > > Les, > > >As for the issue of advertising directly connected > reachability for L2-only > >circuits in L1 LSPs, I am not in favor of that. L1 routers > are supposed to > >direct packets destined for addresses "out of the area" to > the nearest L2 > >router. Including L2-only reachability deviates from that > model - and I see > >no compelling reason to do so. > > This is what I thought at first -- but the question was about > the LOCAL > IP address on the circuit, NOT the circuit itself or the remote IP > address. I see no reason not to advertise any of the box's > IP addresses, > do you? > Jeff - The question of advertising a /32 reachability to the interface address - as opposed to advertising reachability to the subnet connected to the L2-only circuit - is less interesting (at least to me). This is simply another advertisement for the router itself and is not likely to improve your chances of finding a shorter path to the router than you would have without this advertisement. This question is not really limited to the case of an L2-only interface and an L1-LSP. In theory, one could advertise /32 reachability to all local interface addresses - but this is not particularly useful, wastes LSP space, and is not typically done. Les > Note: this was sent only to you, but feel free to respond > using the list. > > > > Les > > > >> -----Original Message----- > >> From: Ken Larmer [mailto:Larmer@CommSense.Net] > >> Sent: Friday, October 19, 2001 6:05 AM > >> To: Les Ginsberg; Jeff Learman; Koen Vermeulen > >> Cc: Isis-wg > >> Subject: RE: [Isis-wg] ManualL2Only > >> > >> > >> Hi Les, > >> > >> Please see my comments inline. > >> > >> Cheers, > >> Ken Larmer > >> > >> > -----Original Message----- > >> > From: Les Ginsberg [mailto:ginsberg@pluris.com] > >> > Sent: Wednesday, October 17, 2001 10:18 PM > >> > To: 'Ken Larmer'; Jeff Learman; Koen Vermeulen > >> > Cc: Isis-wg > >> > Subject: RE: [Isis-wg] ManualL2Only > >> > > >> > > >> > The text in both ISO 10589 V1 and V2 is correct. Please see > >> my comments in > >> > line. > >> > > >> > Les > >> > > >> > > >> > > -----Original Message----- > >> > > From: Ken Larmer [mailto:Larmer@CommSense.Net] > >> > > Sent: Wednesday, October 17, 2001 8:34 AM > >> > > To: Jeff Learman; Koen Vermeulen > >> > > Cc: Isis-wg > >> > > Subject: RE: [Isis-wg] ManualL2Only > >> > > > >> > > > >> > > Hi Koen, > >> > > > >> > > I found the following conflicting references. > >> > > > >> > > ISO-10589 V1 states the following: > >> > > > >> > > -In the Intermediate System Neighbours option the set of > >> > > Intermediate system > >> > > IDs of neighbouring In > >> > > termediate systems formed from: > >> > > > >> > > The set of neighbourSystemIDs with an appended zero octet > >> (indicating > >> > > non-pseudonode) > >> > > from adjacencies in the state Up, on circuits of type > >> > > Point-Point, In or > >> > > Out, with > >> > > > >> > > xneighbourSystemType L1 Intermediate System > >> > > > >> > > xneighbourSystemType L2 Intermediate System and > >> > > adjacencyUsage Level 2 or > >> > > Level1 and 2. > >> > > > >> > > >> > You have misquoted the text from 7.3.7. It actually states: > >> > > >> > x neighbourSystemType L2 Intermediate System and > >> > adjacencyUsage Level 1 or > >> > Level1 and 2. > >> > > >> > >> Les, here is a cut and paste from RFC-1142 (Integrated IS-IS) > >> > >> 7.3.7 Generation of Level 1 LSPs (non-pseudonode) > >> The Level 1 Link State PDU not generated on behalf of a > >> pseudonode contains > >> the following information in its variable length fields. > >> ... > >> -In the Intermediate System Neighbours option the set of > >> Intermediate system > >> IDs of neighbouring In > >> termediate systems formed from: > >> > >> xThe set of neighbourSystemIDs with an appended zero octet > (indicating > >> non-pseudonode) > >> from adjacencies in the state Up, on circuits of type > >> Point-Point, In or > >> Out, with > >> > >> xneighbourSystemType L1 Intermediate System > >> > >> xneighbourSystemType L2 Intermediate System and > >> adjacencyUsage Level 2 or > >> Level1 and 2. > >> > >> I believe this is different from the V2 spec? > >> > >> > This text is identical to the text found in V2 which you > >> correctly quote > >> > below. > >> > > >> > > > >> > > ISO-10589 V2 states the following: > >> > > > >> > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > >> > > > >> > > - In the Intermediate System Neighbours option - the set > >> > > of Intermediate > >> > > system IDs of neighbouring Intermediate systems formed from > >> > > > >> > > . The set of neighbourSystemIDs with an appended zero > >> > > octet (indicating > >> > > non-pseudonode) from adjacencies in the state "Up", on > >> > > circuits of type > >> > > "ptToPt", "staticIn", or "staticOut", with > >> > > > >> > > x neighbourSystemType "L1 Intermediate System" > >> > > > >> > > x neighbourSystemType "L2 Intermediate System" and > >> > > adjacencyUsage "Level 1" > >> > > or "Level 1 and 2". > >> > > > >> > > I believe that this section should read as follows: > >> > > > >> > > 7.3.7 Generation of level 1 LSPs (non-pseudonode) > >> > > > >> > > - In the Intermediate System Neighbours option - the set > >> > > of Intermediate > >> > > system IDs of neighbouring Intermediate systems formed from > >> > > > >> > > . The set of neighbourSystemIDs with an appended zero > >> > > octet (indicating > >> > > non-pseudonode) from adjacencies in the state "Up", on > >> > > circuits of type > >> > > "ptToPt", "staticIn", or "staticOut", with > >> > > > >> > > x neighbourSystemType "L1 Intermediate System" > >> > > > >> > > >> > This is not correct. > >> > > >> > On a point-point circuit, a single adjacency is formed and > >> the adjacency > >> > usage is set based upon the advertised circuit types (L1, > >> L2-only, L1 and > >> > L2) and whether the neighbors share an area address. If one > >> > system is an L1 > >> > IS or an L2 IS with circuit type L1-only, then it would set > >> > circuit type to > >> > L1 and adjacency usage could only be L1. If both neighbors are L2 > >> > ISs and do > >> > not have the circuit set to L2-only, then adjacency usage > >> will be Level 1 > >> > and 2. In both cases you would want to advertise this > >> neighbor in your L1 > >> > LSP since it is reachable at this level. > >> > >> Les, yes you are correct! I was looking at the text in the V1 > >> spec when I > >> made the above statement. Of course, my proposed text was > >> still wrong! The > >> V2 spec is correct! > >> > >> > It is probably somewhat confusing to talk about > >> "neighborSystemType" since > >> > what is actually advertised in IIH PDUs is "circuit type". While > >> > the IS type > >> > bounds the possible values for circuit type, it is not > >> > equivalent. A Level 2 > >> > IS is assumed to operate as an L1 IS in its area and can > >> therefore use the > >> > circuit for both L1 and L2 traffic (default behavior) or > >> designate the > >> > circuit as L1 only or L2 only. An L1 IS of course, can only use > >> > the circuit > >> > for L1 traffic. > >> > > >> > On LANs, separate adjacencies are formed for Level 1 and > >> Level 2 and the > >> > adjacency usage can be implicitly set to L1 and L2 > >> respectively. (This is > >> > not explicitly stated in the spec.) > >> > > >> > > > >> > > RFC-1195 states the following for the IP Internal > >> > > Reachability Information > >> > > TLV for both L1 and L2 LSPs. > >> > > > >> > > IP Internal Reachability Information -- IP addresses within > >> > > the routing > >> > > domain reachable directly via one or more interfaces on this > >> > > Intermediate > >> > > system. > >> > > > >> > > I believe this should read as follows for L1 LSPs > >> > > > >> > > IP Internal Reachability Information -- IP addresses within > >> > > the L1 routing > >> > > subdomain reachable directly via one or more interfaces on > >> > > this Intermediate > >> > > system. > >> > > > >> > >> Any comments on the above text??? > >> > >> > > > >> > > Cheers, > >> > > Ken Larmer > >> > > CommSense Networks > >> > > www.commsense.net > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: isis-wg-admin@external.juniper.net > >> > > > [mailto:isis-wg-admin@external.juniper.net]On Behalf Of > >> Jeff Learman > >> > > > Sent: Wednesday, October 17, 2001 10:20 AM > >> > > > To: Koen Vermeulen > >> > > > Cc: Isis-wg > >> > > > Subject: Re: [Isis-wg] ManualL2Only > >> > > > > >> > > > > >> > > > At 02:33 AM 10/16/2001, Koen Vermeulen wrote: > >> > > > >Hello, > >> > > > > > >> > > > >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an > >> > > > >explicit rule whether or not to include the network address > >> > > > >of a manualL2only-enabled interface in the L1 LSP generated > >> > > > >by a L1/L2 IS. > >> > > > >Somebody has some ideas/good reasons for not including > >> > > > >the address of that manualL2only interface in L1? > >> > > > > >> > > > Without consulting the specs, I can say that it doesn't make > >> > > > sense to include such an adjacency in the L1 LSP. If you do, > >> > > > then when you run SPF, you will either use "inadmissible" > >> > > > local knowledge when running SPF (thereby creating a > different > >> > > > topology than other ISs) or else you won't heed the L2-only > >> > > > nature of the link and will forward L1 traffic on it. > >> > > > > >> > > > For example: > >> > > > > >> > > > A --- B ==== C ---- D > >> > > > | | > >> > > > E -- F -- G -- H -- I > >> > > > > >> > > > where all are in the same area, but the link between B and C > >> > > > is L2-only. If A wants to send data to D, it will send it to > >> > > > B. If B heeds the l2-only property, it would send > it back to A. > >> > > > > >> > > > Note that B runs the SPF using the same data as > everyone else: > >> > > > the LSDB. It uses its adjacency database also, > true, but only > >> > > > to preload "tent" (or is it "paths", it's been a while). > >> > > > > >> > > > B needs to advertise links consistently with how it would use > >> > > > them itself, so that the area topology is identical > for all ISs > >> > > > in the area. > >> > > > > >> > > > Regards, > >> > > > Jeff > >> > > > > >> > > > > >> > > > >Thanks, > >> > > > >Koen > >> > > > > > >> > > > >_______________________________________________ > >> > > > >Isis-wg mailing list - Isis-wg@external.juniper.net > >> > > > >http://external.juniper.net/mailman/listinfo/isis-wg > >> > > > > >> > > > _______________________________________________ > >> > > > Isis-wg mailing list - Isis-wg@external.juniper.net > >> > > > http://external.juniper.net/mailman/listinfo/isis-wg > >> > > > > >> > > > >> > > _______________________________________________ > >> > > Isis-wg mailing list - Isis-wg@external.juniper.net > >> > > http://external.juniper.net/mailman/listinfo/isis-wg > >> > > > >> > > >> > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Oct 19 18:46:27 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03944 for ; Fri, 19 Oct 2001 18:46:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA34280; Fri, 19 Oct 2001 16:00:41 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA34261 for ; Fri, 19 Oct 2001 15:59:35 -0700 (PDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9JMggO01746; Fri, 19 Oct 2001 18:42:42 -0400 (EDT) Received: from JLEARMAN-W2K1.cisco.com (dhcp-64-102-83-117.cisco.com [64.102.83.117]) by dingdong.cisco.com (Mirapoint) with ESMTP id AEB15167; Fri, 19 Oct 2001 18:43:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20011019174404.019bbe90@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Koen Vermeulen From: Jeff Learman Subject: Re: [Isis-wg] ManualL2Only Cc: Isis-wg In-Reply-To: <4.3.2.7.2.20011017112619.0193ea88@dingdong.cisco.com> References: <3BCDA01A.C97B057@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 19 Oct 2001 18:25:20 -0400 Koen, Sorry, I have to change my answer again. Les pointed out to me that you said "network address" (meaning with a net mask less than 32 bits), not "host address" (with 32 bits). I agree with Les that only L1 network addresses should be advertised in an L1 LSP. The host address of the router on that network could be advertised. Jeff At 11:44 AM 10/17/2001, Jeff Learman wrote: >Reading your original email more carefully, I see I made a >mistake. You were talking about the interface address, >not the adjacency. This case would not be covered in ISO 10589, >because in OSI, interfaces do not have network layer addresses. >It's only an issue for IP addresses. > >In general, I would prefer using an unnumbered interface between >areas, if possible, to avoid wasting a subnet address that can't >be wholly within a single area, and therefore able to be summarized. >This is a minor point, and it's often not possible to use an >unnumbered interface, so the question remains. > >I don't see any harm in including the address, and I don't >see any benefit to omitting it. I don't have a lot of experience >in integrated IS-IS, though, so you may want to wait for other >opinions. > >Regards, >Jeff > >Disclaimer: I am not working on IS-IS at Cisco nor am I familiar with >Cisco's IS-IS implementation. Just trying to keep brain cells from >a previous job alive. > > >At 11:13 AM 10/17/2001, Koen Vermeulen wrote: >>Hello Jeff, >> >>I think I have to be more specific, because it seems that >>my question was not understood completely. I will try to >>explain what I meant with an example. >> >>Suppose you have following 3 IS's: >> >> 1 2 >>A ----- B ----- C >>L1 L1/L2 L2 >> >>where link 2 has network address x and is configured as >>manualL2only. This means that B will only try to form >>a L2 adjacency with C. >>My question is now: is it allowed to add address x in an ip >>reachability TLV to the L1 LSP of B or will this lead to >>some problems? >>Right now, I can't think of any problems adding the >>network address of a manualL2only to L1. I would >>even expect that this way of working is the correct >>one because of the fact that IS-IS areas cut through >>interfaces and not through routers as is done in OSPF. >> >>I hope this makes my question more clear? >> >>Thanks, >>Koen >> >>Jeff Learman wrote: >> >>> At 02:33 AM 10/16/2001, Koen Vermeulen wrote: >>> >Hello, >>> > >>> >Nor in ISO/IEC 10589, neither in rfc 1195 I can't find an >>> >explicit rule whether or not to include the network address >>> >of a manualL2only-enabled interface in the L1 LSP generated >>> >by a L1/L2 IS. >>> >Somebody has some ideas/good reasons for not including >>> >the address of that manualL2only interface in L1? >>> >>> Without consulting the specs, I can say that it doesn't make >>> sense to include such an adjacency in the L1 LSP. If you do, >>> then when you run SPF, you will either use "inadmissible" >>> local knowledge when running SPF (thereby creating a different >>> topology than other ISs) or else you won't heed the L2-only >>> nature of the link and will forward L1 traffic on it. >>> >>> For example: >>> >>> A --- B ==== C ---- D >>> | | >>> E -- F -- G -- H -- I >>> >>> where all are in the same area, but the link between B and C >>> is L2-only. If A wants to send data to D, it will send it to >>> B. If B heeds the l2-only property, it would send it back to A. >>> >>> Note that B runs the SPF using the same data as everyone else: >>> the LSDB. It uses its adjacency database also, true, but only >>> to preload "tent" (or is it "paths", it's been a while). >>> >>> B needs to advertise links consistently with how it would use >>> them itself, so that the area topology is identical for all ISs >>> in the area. >>> >>> Regards, >>> Jeff >>> >>> >Thanks, >>> >Koen >>> > >>> >_______________________________________________ >>> >Isis-wg mailing list - Isis-wg@external.juniper.net >>> >http://external.juniper.net/mailman/listinfo/isis-wg >>> >>> _______________________________________________ >>> Isis-wg mailing list - Isis-wg@external.juniper.net >>> http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Oct 22 07:09:08 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10686 for ; Mon, 22 Oct 2001 07:09:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA50468; Mon, 22 Oct 2001 04:21:42 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA50456 for ; Mon, 22 Oct 2001 04:20:22 -0700 (PDT) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9MB3vt92074 for ; Mon, 22 Oct 2001 04:03:57 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 22 Oct 2001 04:02:03 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10342; Mon, 22 Oct 2001 07:02:50 -0400 (EDT) Message-Id: <200110221102.HAA10342@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 22 Oct 2001 11:02:03.0515 (UTC) FILETIME=[FB1F9CB0:01C15AE8] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Mon, 22 Oct 2001 07:02:50 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : M-ISIS: Multi Topology Routing in IS-IS Author(s) : T. Przygienda et al. Filename : draft-ietf-isis-wg-multi-topology-01.txt Pages : 7 Date : 19-Oct-01 This draft describes an optional implementation technique within IS-IS [ISO90 , Cal90a , Cal90b] used today by many ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs), or Multiple views of Topology. This MT extension can be used for variety of purposes such as an in-band management network on top' of the original IGP topology, transport multiple overlapping IP address spaces in the same protocol, force a subset of an address space to follow a different topology, or finally, even maintain a restricted number of protocol based VPNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-multi-topology-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011019141226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-multi-topology-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011019141226.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Tue Oct 23 07:07:29 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25892 for ; Tue, 23 Oct 2001 07:07:28 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA56191; Tue, 23 Oct 2001 04:21:42 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA56179 for ; Tue, 23 Oct 2001 04:20:04 -0700 (PDT) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9NB3Xt44540 for ; Tue, 23 Oct 2001 04:03:33 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 23 Oct 2001 04:01:49 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25477; Tue, 23 Oct 2001 07:02:37 -0400 (EDT) Message-Id: <200110231102.HAA25477@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 23 Oct 2001 11:01:49.0734 (UTC) FILETIME=[1D528C60:01C15BB2] Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-transient-02.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Tue, 23 Oct 2001 07:02:37 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Transient Blackhole Avoidance Author(s) : D. McPherson Filename : draft-ietf-isis-transient-02.txt Pages : 6 Date : 22-Oct-01 This document describes a simple, interoperable mechanism that can be employed in IS-IS networks in order to decrease data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-transient-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-transient-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-transient-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011022135523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-transient-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-transient-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011022135523.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Oct 26 07:10:04 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27218 for ; Fri, 26 Oct 2001 07:10:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73089; Fri, 26 Oct 2001 04:24:41 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73077 for ; Fri, 26 Oct 2001 04:23:10 -0700 (PDT) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9QB6HK14187 for ; Fri, 26 Oct 2001 04:06:17 -0700 (PDT) X-JNPR-Received-From: outside Received: from ietf.org ([132.151.1.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 26 Oct 2001 04:05:18 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27096; Fri, 26 Oct 2001 07:06:10 -0400 (EDT) Message-Id: <200110261106.HAA27096@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ospf@discuss.microsoft.com, isis-wg@juniper.net, te-wg@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org X-OriginalArrivalTime: 26 Oct 2001 11:05:18.0703 (UTC) FILETIME=[191DEFF0:01C15E0E] Subject: [Isis-wg] I-D ACTION:draft-ash-ospf-isis-congestion-control-01.txt Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Oct 2001 07:06:09 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks Author(s) : J. Ash et al. Filename : draft-ash-ospf-isis-congestion-control-01.txt Pages : Date : 25-Oct-01 Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101].The problem addressed is to enable link-state protocols to a) gracefully recover from massive loss of topology database information, and b) respond gracefully to network overloads and failures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-ospf-isis-congestion-control-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011025145328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ash-ospf-isis-congestion-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011025145328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Fri Oct 26 14:31:57 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14552 for ; Fri, 26 Oct 2001 14:31:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA74718; Fri, 26 Oct 2001 11:03:50 -0700 (PDT) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA74706 for ; Fri, 26 Oct 2001 11:02:07 -0700 (PDT) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9QHjCK31491 for ; Fri, 26 Oct 2001 10:45:12 -0700 (PDT) X-JNPR-Received-From: outside Received: from emerson.torrentnet.com ([198.78.51.110]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 26 Oct 2001 10:44:09 -0700 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f9QHj4L79382 for ; Fri, 26 Oct 2001 13:45:04 -0400 (EDT) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f9QHj3S57275 for ; Fri, 26 Oct 2001 13:45:03 -0400 (EDT) Received: from malibu.torrentnet.com (sherwin@localhost) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id f9QHj3A23704 for ; Fri, 26 Oct 2001 13:45:03 -0400 (EDT) Message-Id: <200110261745.f9QHj3A23704@malibu.torrentnet.com> To: isis-wg@juniper.net From: Chris Sherwin X-OriginalArrivalTime: 26 Oct 2001 17:44:09.0906 (UTC) FILETIME=[D139B920:01C15E45] Subject: [Isis-wg] M-ISIS Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Fri, 26 Oct 2001 13:45:03 -0400 Hi all, Is this M-ISIS draft similar to/the same as the multi-instance IS-IS Juniper has? Does CISCO support something like this? Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Mon Oct 29 01:15:23 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22741 for ; Mon, 29 Oct 2001 01:15: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 WAA90780; Sun, 28 Oct 2001 22:28:41 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA90768 for ; Sun, 28 Oct 2001 22:27:34 -0800 (PST) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9T6AKK92882 for ; Sun, 28 Oct 2001 22:10:20 -0800 (PST) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 28 Oct 2001 22:09:23 -0800 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 5A3CE1DCC79; Sun, 28 Oct 2001 22:10:20 -0800 (PST) To: Chris Sherwin Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] M-ISIS In-reply-to: Mail from Chris Sherwin dated Fri, 26 Oct 2001 13:45:03 EDT <200110261745.f9QHj3A23704@malibu.torrentnet.com> From: Naiming Shen Message-Id: <20011029061020.5A3CE1DCC79@prattle.redback.com> X-OriginalArrivalTime: 29 Oct 2001 06:09:23.0296 (UTC) FILETIME=[414F1600:01C16040] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Sun, 28 Oct 2001 22:10:20 -0800 To the wg list, the new version M-ISIS 01.txt has been posted on ietf websiet. The main change is to add an IPv6 reachable prefix TLV for multi-topology(section 8.4). Please send comments. ]Hi all, ] ]Is this M-ISIS draft similar to/the same as the multi-instance IS-IS ]Juniper has? No. The main point of M-ISIS is "SINGLE instance". Even though its possible to use multi-instance to form multi-topology of ISIS, the tricky thing is if more than one instance need to share the same interface on a router, a mechanism is needed to multiplex inbound isis packets to the right instance. Although one can freely add new TLVs inside ISIS packets, the issue is backwards compatibility, especially when the DIS on a LAN runs old code. But M-ISIS does not exclude multi-instance application of ISIS. It will be perfectly reasonable to run multiple instances of M-ISIS on a router. If two networks both run M-ISIS as IGPs resides on the router, multi-instance of M-ISIS will be useful there. ]Does CISCO support something like this? ] ]Chris. - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 31 05:16:32 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09585 for ; Wed, 31 Oct 2001 05:16:32 -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 CAA03333; Wed, 31 Oct 2001 02:28:43 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA03321 for ; Wed, 31 Oct 2001 02:27:20 -0800 (PST) Received: from pong.juniper.net (pong.juniper.net [207.17.137.102]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9VA9oK00763 for ; Wed, 31 Oct 2001 02:09:51 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by pong.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Oct 2001 00:18:00 -0800 Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp29.cisco.com [144.254.108.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA11862; Wed, 31 Oct 2001 08:18:56 GMT Message-Id: <4.3.2.7.2.20011031081332.00b4c868@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Przygienda From: mike shand Cc: isis-wg@juniper.net In-Reply-To: <3B79992B.9E287E89@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2001 08:18:00.0765 (UTC) FILETIME=[8E1AE6D0:01C161E4] Subject: [Isis-wg] tlv codepoint for ISIS-restart draft Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 31 Oct 2001 08:19:29 +0000 Tony, I need to assign a real codepoint for the "restart" TLV in draft-ietf-isis-restart. I don't think we have any procedure to do this. Looking at your draft, I see that 11 is currently free. So may I propose that I use that? Mike _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 31 07:38:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11791 for ; Wed, 31 Oct 2001 07:38:24 -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 EAA03960; Wed, 31 Oct 2001 04:52:43 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA03948 for ; Wed, 31 Oct 2001 04:51:20 -0800 (PST) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9VCXoK05296 for ; Wed, 31 Oct 2001 04:33:51 -0800 (PST) X-JNPR-Received-From: outside Received: from net4u.net4u.ch ([194.191.0.1]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Oct 2001 04:31:09 -0800 Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id NAA18079; Wed, 31 Oct 2001 13:34:23 +0100 From: Tony Przygienda Message-Id: <200110311234.NAA18079@net4u.net4u.ch> Subject: Re: [Isis-wg] tlv codepoint for ISIS-restart draft In-Reply-To: <4.3.2.7.2.20011031081332.00b4c868@jaws.cisco.com> from mike shand at "Oct 31, 2001 8:19:29 am" To: mshand@cisco.com (mike shand) Cc: prz@redback.com, isis-wg@juniper.net X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2001 12:31:10.0125 (UTC) FILETIME=[EBAB4DD0:01C16207] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 31 Oct 2001 13:34:23 +0100 (MET) Content-Transfer-Encoding: 7bit > Tony, > I need to assign a real codepoint for the "restart" TLV in > draft-ietf-isis-restart. I don't think we have any procedure to do this. > Looking at your draft, I see that 11 is currently free. So may I propose > that I use that? > > Mike we tend to crash in low numbers more likely, could you live something >128, let's say 211? -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 31 08:26:25 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16932 for ; Wed, 31 Oct 2001 08:26:23 -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 FAA04238; Wed, 31 Oct 2001 05:40:45 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA04196 for ; Wed, 31 Oct 2001 05:39:12 -0800 (PST) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9VDLfK06484 for ; Wed, 31 Oct 2001 05:21:41 -0800 (PST) X-JNPR-Received-From: outside Received: from cisco.com ([198.135.0.176]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Oct 2001 05:16:19 -0800 Received: from mshand-w2k.cisco.com (lon-sto4-lan-vlan133-dhcp29.cisco.com [144.254.108.96]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA26264; Wed, 31 Oct 2001 13:16:41 GMT Message-Id: <4.3.2.7.2.20011031131604.00b7b398@jaws.cisco.com> X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Tony Przygienda From: mike shand Subject: Re: [Isis-wg] tlv codepoint for ISIS-restart draft Cc: prz@redback.com, isis-wg@juniper.net In-Reply-To: <200110311234.NAA18079@net4u.net4u.ch> References: <4.3.2.7.2.20011031081332.00b4c868@jaws.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 31 Oct 2001 13:16:19.0718 (UTC) FILETIME=[3AB66260:01C1620E] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 31 Oct 2001 13:17:14 +0000 At 13:34 31/10/2001 +0100, Tony Przygienda wrote: > > Tony, > > I need to assign a real codepoint for the "restart" TLV in > > draft-ietf-isis-restart. I don't think we have any procedure to do this. > > Looking at your draft, I see that 11 is currently free. So may I propose > > that I use that? > > > > Mike > >we tend to crash in low numbers more likely, could you live something >128, >let's say 211? I have no vested interest in any number (apart from 42 of course :-) 211 is as good as any other. Mike > -- tony > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@spider.juniper.net Wed Oct 31 15:15:52 2001 Received: from external.juniper.net (spider.juniper.net [207.17.137.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29667 for ; Wed, 31 Oct 2001 15:15:51 -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 MAA05928; Wed, 31 Oct 2001 12:30:42 -0800 (PST) Received: from colo-rojo.jnpr.net (ns1.juniper.net [207.17.137.28] (may be forged)) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA05913 for ; Wed, 31 Oct 2001 12:29:00 -0800 (PST) Received: from ping.juniper.net (scanners.jnpr.net [207.17.137.101]) by colo-rojo.jnpr.net (8.11.2/8.11.2) with ESMTP id f9VKBSK26099 for ; Wed, 31 Oct 2001 12:11:28 -0800 (PST) X-JNPR-Received-From: outside Received: from prattle.redback.com ([155.53.12.9]) by ping.juniper.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 31 Oct 2001 12:10:21 -0800 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 9B72FF2C40; Wed, 31 Oct 2001 12:11:20 -0800 (PST) To: mike shand Cc: Tony Przygienda , prz@redback.com, isis-wg@juniper.net Subject: Re: [Isis-wg] tlv codepoint for ISIS-restart draft In-reply-to: Mail from mike shand dated Wed, 31 Oct 2001 13:17:14 GMT <4.3.2.7.2.20011031131604.00b7b398@jaws.cisco.com> From: Naiming Shen Message-Id: <20011031201120.9B72FF2C40@prattle.redback.com> X-OriginalArrivalTime: 31 Oct 2001 20:10:21.0109 (UTC) FILETIME=[1155D650:01C16248] Sender: isis-wg-admin@spider.juniper.net Errors-To: isis-wg-admin@spider.juniper.net X-BeenThere: isis-wg@external.juniper.net X-Mailman-Version: 2.0rc1 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: Date: Wed, 31 Oct 2001 12:11:20 -0800 tony, please update it also with tlv 237: Multi-Topology Reachable IPv6 Prefixes TLV cheers. ]At 13:34 31/10/2001 +0100, Tony Przygienda wrote: ]> > Tony, ]> > I need to assign a real codepoint for the "restart" TLV in ]> > draft-ietf-isis-restart. I don't think we have any procedure to do this. ]> > Looking at your draft, I see that 11 is currently free. So may I propose ]> > that I use that? ]> > ]> > Mike ]> ]>we tend to crash in low numbers more likely, could you live something >128, ]>let's say 211? ] ]I have no vested interest in any number (apart from 42 of course :-) ] ]211 is as good as any other. ] ] Mike ] ] ] ]> -- tony ]> ]>_______________________________________________ ]>Isis-wg mailing list - Isis-wg@external.juniper.net ]>http://external.juniper.net/mailman/listinfo/isis-wg ] ]_______________________________________________ ]Isis-wg mailing list - Isis-wg@external.juniper.net ]http://external.juniper.net/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg