From isis-wg-admin@ietf.org Sun Oct 5 23:36:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04198 for ; Sun, 5 Oct 2003 23:36:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6M9G-0000aT-Pd; Sun, 05 Oct 2003 23:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VI9-0006eK-2Y for isis-wg@optimus.ietf.org; Fri, 03 Oct 2003 15:08:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21494 for ; Fri, 3 Oct 2003 15:08:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VI5-00054g-00 for isis-wg@ietf.org; Fri, 03 Oct 2003 15:08:37 -0400 Received: from [208.229.251.198] (helo=oxide.local) by ietf-mx with esmtp (Exim 4.12) id 1A5VI4-00054d-00 for isis-wg@ietf.org; Fri, 03 Oct 2003 15:08:36 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by oxide.local (8.12.9/8.12.6) with ESMTP id h93J8YDF019174 for ; Fri, 3 Oct 2003 12:08:35 -0700 (PDT) From: Ed Kern To: isis-wg@ietf.org Message-ID: <2147483647.1065182914@[208.229.251.198]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Last Call for draft-ietf-tewg-diff-te-proto-05.txt and friends Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 03 Oct 2003 12:08:34 -0700 Content-Transfer-Encoding: 7bit ##Note: This last call is being sent to te-wg,ISIS,OSPF,MPLS in separate emails to trim silly "respond-all" people and aggressive junk filters. This will serve as a last call for the standards track document draft-ietf-tewg-diff-te-proto-05.txt available at and the "friends" (accompanying bandwidth control drafts) going towards experimental: draft-ietf-tewg-diff-te-russian-04.txt draft-ietf-tewg-diff-te-mar-02.txt draft-ietf-tewg-diff-te-mam-01.txt This last call will be three weeks ending 10/24/03 after which time many beers will be consumed. All comments about the drafts should be to/on the te-wg@ops.ietf.org list. All flames about duplicates of this message to me. thx Ed _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Oct 7 07:36:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27442 for ; Tue, 7 Oct 2003 07:36:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6q8I-0003w7-5I; Tue, 07 Oct 2003 07:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6gg7-00036G-1c for isis-wg@optimus.ietf.org; Mon, 06 Oct 2003 21:30:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01087 for ; Mon, 6 Oct 2003 21:30:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6gg4-0006iu-00 for isis-wg@ietf.org; Mon, 06 Oct 2003 21:30:16 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1A6gg3-0006iq-00 for isis-wg@ietf.org; Mon, 06 Oct 2003 21:30:15 -0400 Received: from user-2ivfmh4.dialup.mindspring.com ([165.247.218.36] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1A6gg3-0007iM-00; Mon, 06 Oct 2003 18:30:15 -0700 Message-ID: <3F8216D5.D6468A5F@earthlink.net> From: Erblichs X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@ietf.org, tli@procket.com, hhwsmit@xs4all.nl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] clarification : draft-ietf-isis-traffic-05.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 06 Oct 2003 18:28:53 -0700 Content-Transfer-Encoding: 7bit Group and authors, I have a number(6) of clarifications that I am unsure how to proceed with. Just trying to work up a implementation.. Oh, I don't think I am on this mailing list so please include my addr in the reply. :) 2.0 Introducing Sub-TLVs "The number of items in a sub-TLV can be computed from the length of the whole sub-TLV, when the length of each item is known" a)What do we do if we have a length / subTLV mismatch? If the length indicates lost sub-TLVs? Because the sub-type is 0, etc? Do we stop processing just this sub-TLV OR do we stop processing all sub-TLVs from this sub-TLV OR do we throw away all the sub-TLVs that were based on this TLV? 3.1 Sub-TLV 3: Administrative group ... b) Can a network administrator assign multiple groups to a single interface with two or more bits being set? c) "Should appear at most once". Does that mean only the first one is used? Does that mean if we see two of these sub-TLVs, then both should be discarded? 3.3 Sub-TLV 8: IPv4 neighbor address d) Can two identical nbr addrs exist in this sub-TLV? e) Should/ could the nbr addrs be ordered? What would be the consequences of ordering nbr addrs? 3.5) and 3.6) Repeat the c) Clarification.. 3.3) f) Why isn't the same caution in 3.6 "For stability reasons,... applied to 3.3? Mitchell Erblich Sr Software Engineer _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Oct 10 18:54:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28053 for ; Fri, 10 Oct 2003 18:54:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8692-0002bQ-SY; Fri, 10 Oct 2003 18:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A868k-0002au-Rl for isis-wg@optimus.ietf.org; Fri, 10 Oct 2003 18:53:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28025 for ; Fri, 10 Oct 2003 18:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A868h-00043q-00 for isis-wg@ietf.org; Fri, 10 Oct 2003 18:53:39 -0400 Received: from nn5.excitenetwork.com ([207.159.120.59] helo=xmxpita.excite.com) by ietf-mx with esmtp (Exim 4.12) id 1A868g-00043f-00 for isis-wg@ietf.org; Fri, 10 Oct 2003 18:53:39 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 378F81E421; Fri, 10 Oct 2003 18:53:03 -0400 (EDT) To: jparker@axiowave.com, isis-wg@ietf.org Received: from [64.47.48.10] by xprdmailfe24.nwk.excite.com via HTTP; Fri, 10 Oct 2003 18:53:03 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 Reply-To: dgoodspe@excite.com From: "Don Goodspeed" MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20031010225303.378F81E421@xmxpita.excite.com> Content-Transfer-Encoding: 7bit Subject: [Isis-wg] ISIS MIB: isisNotificationTable Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 10 Oct 2003 18:53:03 -0400 (EDT) Content-Transfer-Encoding: 7bit Jeff (and all), My SNMP developer just informed me that the attributes in the isisNotificationTable should actually have a MAX-ACCESS clause of accessible-for-notify instead of read-only. Have a good weekend, Don _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Oct 13 15:57:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24179 for ; Mon, 13 Oct 2003 15:57:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98oQ-00050w-84; Mon, 13 Oct 2003 15:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A98o9-0004zx-Bh for isis-wg@optimus.ietf.org; Mon, 13 Oct 2003 15:56:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24033; Mon, 13 Oct 2003 15:56:36 -0400 (EDT) Message-Id: <200310131956.PAA24033@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-17.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 13 Oct 2003 15:56:35 -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 Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-17.txt Pages : 12 Date : 2003-10-13 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-17.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-gmpls-extensions-17.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-gmpls-extensions-17.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: <2003-10-13145723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-13145723.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Oct 14 08:35:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06333 for ; Tue, 14 Oct 2003 08:35:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OOE-0002Nb-BQ; Tue, 14 Oct 2003 08:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9ONR-0002Md-FA for isis-wg@optimus.ietf.org; Tue, 14 Oct 2003 08:34:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06248 for ; Tue, 14 Oct 2003 08:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9ONQ-0001mY-00 for isis-wg@ietf.org; Tue, 14 Oct 2003 08:34:12 -0400 Received: from web40606.mail.yahoo.com ([66.218.78.143]) by ietf-mx with smtp (Exim 4.12) id 1A9ONP-0001mA-00 for isis-wg@ietf.org; Tue, 14 Oct 2003 08:34:11 -0400 Message-ID: <20031014123340.1775.qmail@web40606.mail.yahoo.com> Received: from [165.213.1.1] by web40606.mail.yahoo.com via HTTP; Tue, 14 Oct 2003 05:33:40 PDT From: Nob To: isis-wg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1375780042-1066134820=:1263" Subject: [Isis-wg] Why ISIS is run on Data Link Layer?????? Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 05:33:40 -0700 (PDT) --0-1375780042-1066134820=:1263 Content-Type: text/plain; charset=us-ascii Hi All, I am just curious why ISIS is run on Data-Link Layer . As we run on Data-Link Layer we need to take of reliability by ISIS itself............If we use TCP, what kind of problem may arise in case of ISIS......... because then TCP will take care of reliability???? TIA --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search --0-1375780042-1066134820=:1263 Content-Type: text/html; charset=us-ascii
Hi All,
I am just curious why ISIS is run on Data-Link Layer . As we run on Data-Link Layer we need to take of reliability by ISIS itself............If we use TCP, what kind of problem may arise in case of ISIS......... because then TCP will take care of reliability????
 
TIA

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search --0-1375780042-1066134820=:1263-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Oct 14 09:33:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08720 for ; Tue, 14 Oct 2003 09:33:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PIL-0005wd-FM; Tue, 14 Oct 2003 09:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9PIH-0005wR-Iz for isis-wg@optimus.ietf.org; Tue, 14 Oct 2003 09:32:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08693 for ; Tue, 14 Oct 2003 09:32:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9PIF-0002Yf-00 for isis-wg@ietf.org; Tue, 14 Oct 2003 09:32:55 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A9PIE-0002YM-00 for isis-wg@ietf.org; Tue, 14 Oct 2003 09:32:55 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2003 06:32:29 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9EDWFpb008772; Tue, 14 Oct 2003 09:32:21 -0400 (EDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-337.cisco.com [10.82.225.81]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQN09249; Tue, 14 Oct 2003 06:32:14 -0700 (PDT) Message-Id: <4.3.2.7.2.20031014090005.021c7590@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Nob , isis-wg@ietf.org From: Jeff Learman Subject: Re: [Isis-wg] Why ISIS is run on Data Link Layer?????? In-Reply-To: <20031014123340.1775.qmail@web40606.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_394617690==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 14 Oct 2003 09:31:10 -0400 --=====================_394617690==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:33 AM 10/14/2003, Nob wrote: >I am just curious why ISIS is run on Data-Link Layer . As we run on >Data-Link Layer we need to take of reliability by ISIS >itself............If we use TCP, what kind of problem may arise in case of >ISIS......... because then TCP will take care of reliability???? I can't say with authority since I wasn't there at the time, but I can make a few observations off the top of my head. ISIS builds the routing information. TCP relies on IP, which relies on the routing information. It's a reasonable layering of design. If ISIS then relied on TCP, there would be a circularity problem. More on this later, when I talk about OSPF's use of IP. Actually, instead of TCP it would have used TP4, the OSI connection- oriented transport used over CLNP, since ISIS was designed for OSI CLNP, not IP. It's a testament to the extensibility of the protocol that it works so well for IP. It's also a good thing that we don't have to implement TP4 to do ISIS! Furthermore, the kind of reliability that is required is a multicast reliability, and there were no reliable transport multicast protocols in the late eighties, when the protocol was designed. The fact that the nodes to which the information is distributed are the very routers relaying the information makes it possible to use an extremely efficient protocol for disseminating the data and keeping it reliable. ISIS is extremely efficient on bandwidth usage and highly scalable as a result. I don't believe a transport level protocol could possibly work as well. Note that even with transport reliability, ISIS would have additional reliability requirements that wouldn't be met by TCP or TP4, having to do with the reliability of the source of information itself, and therefore would have to have additional reliability rules anyway. (E.g., the seemingly over-complex rules concerning sequence numbers and wraparound -- these were driven by an actual case in the Arpanet.) OSPF doesn't use TCP, by the way. It does use IP though, and that does make it easier to adapt to a new link layer. When ISIS was defined, there was no clear definition of broadcast CLNP that would have allowed its use the way IP can easily be used on a broadcast link to talk to all neighbors. So the committee would have had to solve that problem first. As it turns out, that issue never was worked out in any standardized way to the best of my knowledge. One of the advantages of OSI addressing is that the subnetwork does not have a network layer address. (A CLNP node doesn't need multiple network addresses simply because it lives on multiple subnetworks, leading to a number of advantages.) However, that advantage makes it hard to work out network addressing issues when the intent is to broadcast on a particular local subnet. If ISIS were designed today and didn't need to support CLNP, we might be tempted to use IP rather than the link directly. That would make adoption of new network protocols (and multiple network protocols) more difficult, but we tend to add new link protocols more often than network protocols ;) Regards, Jeff > >TIA > > >Do you Yahoo!? >The >New Yahoo! Shopping - with improved product search --=====================_394617690==_.ALT Content-Type: text/html; charset="us-ascii" At 08:33 AM 10/14/2003, Nob wrote:
I am just curious why ISIS is run on Data-Link Layer . As we run on Data-Link Layer we need to take of reliability by ISIS itself............If we use TCP, what kind of problem may arise in case of ISIS......... because then TCP will take care of reliability????

I can't say with authority since I wasn't there at the time, but I
can make a few observations off the top of my head.

ISIS builds the routing information.  TCP relies on IP, which relies
on the routing information.  It's a reasonable layering of design.
If ISIS then relied on TCP, there would be a circularity problem.
More on this later, when I talk about OSPF's use of IP.

Actually, instead of TCP it would have used TP4, the OSI connection-
oriented transport used over CLNP, since ISIS was designed for OSI
CLNP, not IP.  It's a testament to the extensibility of the protocol
that it works so well for IP.  It's also a good thing that we don't
have to implement TP4 to do ISIS!

Furthermore, the kind of reliability that is required is a multicast
reliability, and there were no reliable transport multicast protocols
in the late eighties, when the protocol was designed.

The fact that the nodes to which the information is distributed are
the very routers relaying the information makes it possible to use
an extremely efficient protocol for disseminating the data and keeping
it reliable.  ISIS is extremely efficient on bandwidth usage and highly
scalable as a result.  I don't believe a transport level protocol
could possibly work as well.

Note that even with transport reliability, ISIS would have additional
reliability requirements that wouldn't be met by TCP or TP4, having to
do with the reliability of the source of information itself, and
therefore would have to have additional reliability rules anyway.
(E.g., the seemingly over-complex rules concerning sequence numbers
and wraparound -- these were driven by an actual case in the Arpanet.)

OSPF doesn't use TCP, by the way.  It does use IP though, and that does
make it easier to adapt to a new link layer.  When ISIS was defined,
there was no clear definition of broadcast CLNP that would have allowed
its use the way IP can easily be used on a broadcast link to talk to
all neighbors.  So the committee would have had to solve that problem
first.

As it turns out, that issue never was worked out in any standardized way
to the best of my knowledge.  One of the advantages of OSI addressing is
that the subnetwork does not have a network layer address.  (A CLNP node
doesn't need multiple network addresses simply because it lives on multiple
subnetworks, leading to a number of advantages.)  However, that advantage
makes it hard to work out network addressing issues when the intent
is to broadcast on a particular local subnet.

If ISIS were designed today and didn't need to support CLNP, we might
be tempted to use IP rather than the link directly.  That would make
adoption of new network protocols (and multiple network protocols)
more difficult, but we tend to add new link protocols more often than
network protocols ;)

Regards,
Jeff

 
TIA


Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
--=====================_394617690==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Oct 15 04:15:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20023 for ; Wed, 15 Oct 2003 04:15:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9goA-00036N-Uq; Wed, 15 Oct 2003 04:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9go1-000362-Nh for isis-wg@optimus.ietf.org; Wed, 15 Oct 2003 04:14:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19973 for ; Wed, 15 Oct 2003 04:14:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9gny-00012Z-00 for isis-wg@ietf.org; Wed, 15 Oct 2003 04:14:50 -0400 Received: from [203.197.140.35] (helo=fsnt.future.futsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A9gnw-000120-00 for isis-wg@ietf.org; Wed, 15 Oct 2003 04:14:49 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Wed, 15 Oct 2003 13:48:18 +0530 Received: from selvarajr (selvarajr.future.futsoft.com [10.6.4.12]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h9F8DCT11968; Wed, 15 Oct 2003 13:43:12 +0530 Reply-To: From: "SelvarajR" To: "'Nob'" , Subject: RE: [Isis-wg] Why ISIS is run on Data Link Layer?????? Message-ID: <001f01c392f4$d84b60c0$0c04060a@future.futsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C39322.F2039CC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <20031014123340.1775.qmail@web40606.mail.yahoo.com> Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Oct 2003 13:47:58 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C39322.F2039CC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The book "Interconnections: Bridges and Routers" by Radia Pearlmann may give u a better answer. -----Original Message----- From: isis-wg-admin@ietf.org [mailto:isis-wg-admin@ietf.org]On Behalf Of Nob Sent: Tuesday, 14 October 2003 6:04 PM To: isis-wg@ietf.org Subject: [Isis-wg] Why ISIS is run on Data Link Layer?????? Hi All, I am just curious why ISIS is run on Data-Link Layer . As we run on Data-Link Layer we need to take of reliability by ISIS itself............If we use TCP, what kind of problem may arise in case of ISIS......... because then TCP will take care of reliability???? TIA ---------------------------------------------------------------------------- -- Do you Yahoo!? The New Yahoo! Shopping - with improved product search *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0020_01C39322.F2039CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The book "Interconnections: Bridg= es and=20 Routers" by Radia Pearlmann may give u a better=20 answer.
-----Original Message-----
From: isis-wg-admin@ietf.or= g=20 [mailto:isis-wg-admin@ietf.org]On Behalf Of Nob
Sent:=20 Tuesday, 14 October 2003 6:04 PM
To:=20 isis-wg@ietf.org
Subject: [Isis-wg] Why ISIS is run on Data Lin= k=20 Layer??????

Hi All,
I am just curious why ISIS is run on Data-Link Layer . As we run on= Data-Link Layer we need to take of reliability by ISIS itself...........= .If we=20 use TCP, what kind of problem may arise in case of ISIS......... bec= ause=20 then TCP will take care of reliability????
 
TIA

Do you Yahoo!?
The=20 New Yahoo! Shopping - with improved product=20 search

***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
------=_NextPart_000_0020_01C39322.F2039CC0-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Oct 17 15:36:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18687 for ; Fri, 17 Oct 2003 15:36:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaOH-0006NK-SG; Fri, 17 Oct 2003 15:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaNf-0006H2-2N for isis-wg@optimus.ietf.org; Fri, 17 Oct 2003 15:35:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18336; Fri, 17 Oct 2003 15:35:13 -0400 (EDT) Message-Id: <200310171935.PAA18336@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-18.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 17 Oct 2003 15:35:12 -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 Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-18.txt Pages : 12 Date : 2003-10-17 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-18.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-gmpls-extensions-18.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-gmpls-extensions-18.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: <2003-10-17124050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-17124050.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Oct 23 12:38:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05891 for ; Thu, 23 Oct 2003 12:38:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiTJ-00042n-RG; Thu, 23 Oct 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiSs-0003s2-Mh for isis-wg@optimus.ietf.org; Thu, 23 Oct 2003 12:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05796 for ; Thu, 23 Oct 2003 12:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACiSr-0004Pa-00 for isis-wg@ietf.org; Thu, 23 Oct 2003 12:37:33 -0400 Received: from spy13.spymac.com ([62.241.51.113]) by ietf-mx with esmtp (Exim 4.12) id 1ACiSq-0004P9-00 for isis-wg@ietf.org; Thu, 23 Oct 2003 12:37:32 -0400 Received: from spy13.spymac.com (localhost [127.0.0.1]) by spy13.spymac.com (Postfix) with ESMTP id 9D15A4240D6; Thu, 23 Oct 2003 10:37:19 -0600 (MDT) Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Saravana Kumar To: isis-wg@ietf.org Reply-To: sarav_k@spymac.com Content-Type: text/plain X-Mailer: AtMail Corp 3.5 - http://webbasedemail.com/ X-Uidl: 1066927039204233494 X-Origin: 203.197.168.166 Message-Id: <20031023163719.9D15A4240D6@spy13.spymac.com> Content-Transfer-Encoding: binary Subject: [Isis-wg] calculating Ipv4/Ipv6 routes in a single-topology heterogenous network Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 23 Oct 2003 10:37:19 -0600 (MDT) Content-Transfer-Encoding: binary Dear All, I would like to calrify some of my assumptions/doubts regarding the calculation Ipv4/Ipv6 routes in a single- topology heterogenous network supporting a mixture of Ipv4 and Ipv6 links. Consider the following (single-toplogy) network, all the 3 routers RTA, RTB, RTC can support ISIS for both Ipv4 and Ipv6. RTA is connected to RTB through a ipv4 only link and is connected to RTC through a ipv6 only link. -- 1.1.1.1/24 / ----- RTB / \ / -- 1:1::/64 v4/v6 /v4 RTX------- RTA \v6 \ -- 2.2.2.2/24 \ / ----- RTC \ -- 2:2::/64 Even though RTB advertises both Ipv4 and Ipv6 prefixes, i would assume that RTA should learn only the Ipv4 prefixes advertised by RTB since it does not know the Ipv6 nexthop address that it should use to reach RTB. Similarly RTA should learn only the Ipv6 prefixes advertised by RTC. Whereas RTX which is connected to RTA through a link that supports both Ipv4 and Ipv6 would learn all the prefixes advertised by RTB and RTC (even though its obvious that it can never reach some of the prefixes that it learnt). I would like to know whether my assuption of this behaviour is correct or not... Thanks, Sarav _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Oct 24 06:57:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25311 for ; Fri, 24 Oct 2003 06:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzct-000430-D1; Fri, 24 Oct 2003 06:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACzc7-0003rk-OB for isis-wg@optimus.ietf.org; Fri, 24 Oct 2003 06:56:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25219 for ; Fri, 24 Oct 2003 06:56:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACzc3-0001WF-00 for isis-wg@ietf.org; Fri, 24 Oct 2003 06:56:11 -0400 Received: from web86210.mail.ukl.yahoo.com ([217.12.12.85]) by ietf-mx with smtp (Exim 4.12) id 1ACzc2-0001V8-00 for isis-wg@ietf.org; Fri, 24 Oct 2003 06:56:10 -0400 Message-ID: <20031024105538.28799.qmail@web86210.mail.ukl.yahoo.com> Received: from [149.254.120.136] by web86210.mail.ukl.yahoo.com via HTTP; Fri, 24 Oct 2003 11:55:38 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: christian_tena@yahoo.co.uk Subject: Re: [Isis-wg] calculating Ipv4/Ipv6 routes in a single-topology heterogenous network To: sarav_k@spymac.com, isis-wg@ietf.org In-Reply-To: <20031023163719.9D15A4240D6@spy13.spymac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Oct 2003 11:55:38 +0100 (BST) Content-Transfer-Encoding: 8bit According to strict RFC 1195 all of the prefixes (both IPv4 and IPv6) will be flooded throughout the area. IS-IS forms links based on whether IS-IS can get over the link or not and form an adjacency. Strict RFC 1195 considers that if IS-IS can get over the link, then so can IPv4, IPv6 and CLNP. It assumes that if a type of packet is present in the area (or level-2 subdomain), that all routers can forward it. RTA will therefore attempt to forward both IPv4 and IPv6 packets to both RTB and RTC. If for some reason the packets cannot actually get through then they are just dumped and you have a blackhole. For this reason we have the topological rules of RFC 1195. Basically if IPv4 is routed anywhere in the area then all routers and links must support it. The same would be true for IPv6. One way to fix this particular type of scenario is the automatic encapsulation draft; however this appears to be getting no support at this time, and so (to my great regret) I can't see it surviving in the IETF. Folks here seem to prefer running multi-topology (MT). However, I can't quite see why you would have a "link" between two dual routers that would support IS-IS and IPv4 but not IPv6, or IS-IS and IPv6 but not IPv4. Another way to fix this is to split the network into separate IPv4 and IPv6 topologies, either by putting them in separate areas or MTs, and then I suppose running GRE tunnels to get IPv4 and IS-IS over the IPv6 only bit and IPv6 and IS-IS over the IPv4 bit, or something like that. The routers will then need to be able to run two instances of IS-IS. Philip --- Saravana Kumar wrote: > Dear All, > > I would like to calrify some of my > assumptions/doubts regarding the calculation > Ipv4/Ipv6 routes in a single- > topology heterogenous network supporting a mixture > of Ipv4 and Ipv6 links. > > Consider the following (single-toplogy) network, all > the 3 routers RTA, RTB, RTC can support ISIS for > both > Ipv4 and Ipv6. RTA is connected to RTB through a > ipv4 only link and is connected to RTC through a > ipv6 only > link. > > > -- 1.1.1.1/24 > / > ----- RTB > / \ > / -- 1:1::/64 > v4/v6 /v4 > RTX------- RTA > \v6 > \ -- 2.2.2.2/24 > \ / > ----- RTC > \ > -- 2:2::/64 > > Even though RTB advertises both Ipv4 and Ipv6 > prefixes, i would assume that RTA should learn only > the Ipv4 > prefixes advertised by RTB since it does not know > the Ipv6 nexthop address that it should use to reach > RTB. > Similarly RTA should learn only the Ipv6 prefixes > advertised by RTC. > > Whereas RTX which is connected to RTA through a link > that supports both Ipv4 and Ipv6 would learn all the > > prefixes advertised by RTB and RTC (even though its > obvious that it can never reach some of the prefixes > that > it learnt). > > I would like to know whether my assuption of this > behaviour is correct or not... > > Thanks, > Sarav > > > > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Oct 24 13:55:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20263 for ; Fri, 24 Oct 2003 13:55:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD69O-0001s4-BR; Fri, 24 Oct 2003 13:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD68R-0001hT-4P for isis-wg@optimus.ietf.org; Fri, 24 Oct 2003 13:54:03 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20211 for ; Fri, 24 Oct 2003 13:53:52 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AD5r2-0000IC-7n; Fri, 24 Oct 2003 13:36:04 -0400 X-test-idtracker: no To: IETF-Announce :; Cc: isis-wg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Subject: [Isis-wg] Last Call: 'Recommendations for Interoperable IP Networks using IS-IS' to Informational RFC Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 24 Oct 2003 13:36:04 -0400 The IESG has received a request from the IS-IS for IP Internets WG to consider the following documents: - 'Recommendations for Interoperable IP Networks using IS-IS ' as an Informational RFC - 'Recommendations for Interoperable Networks using IS-IS ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-07. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isis-ip-interoperable-01.txt http://www.ietf.org/internet-drafts/draft-ietf-isis-iso-interoperable-01.txt _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Oct 27 01:01:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14209 for ; Mon, 27 Oct 2003 01:01:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE0R4-0007zh-0q; Mon, 27 Oct 2003 01:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE0QL-0007ul-Lt for isis-wg@optimus.ietf.org; Mon, 27 Oct 2003 01:00:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14147 for ; Mon, 27 Oct 2003 01:00:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE0QI-0006xq-00 for isis-wg@ietf.org; Mon, 27 Oct 2003 01:00:14 -0500 Received: from spy13.spymac.com ([62.241.51.113]) by ietf-mx with esmtp (Exim 4.12) id 1AE0QI-0006xm-00 for isis-wg@ietf.org; Mon, 27 Oct 2003 01:00:14 -0500 Received: from spy13.spymac.com (localhost [127.0.0.1]) by spy13.spymac.com (Postfix) with ESMTP id E4BD94240D9; Sun, 26 Oct 2003 23:00:10 -0700 (MST) Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Saravana Kumar To: Philip Christian Subject: Re: [Isis-wg] calculating Ipv4/Ipv6 routes in a single-topology heterogenous network Reply-To: sarav_k@spymac.com Content-Type: text/plain X-Mailer: AtMail Corp 3.5 - http://webbasedemail.com/ X-Uidl: 2003102410553828799qmailweb86210mailuklyahoocom X-Origin: 203.197.168.166 Cc: isis-wg@ietf.org Message-Id: <20031027060010.E4BD94240D9@spy13.spymac.com> Content-Transfer-Encoding: binary Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 26 Oct 2003 23:00:10 -0700 (MST) Content-Transfer-Encoding: binary Philip , > >RTA will therefore attempt to forward both IPv4 and >IPv6 packets to both RTB and RTC. > So what you are saying is that if ISIS encounters some Ipv6 prefixes over a "Ipv4 only" link (and vice versa) it should just accept them and add those prefixes to its forwarding tables and advertise them in its LSPs (if its a L1L2 router), even though it knows that those prefixes cannot be reached over that particular link. Currently we are not doing this and guess im gonna have to change the behaviour. > >However, I can't quite see why you would have a "link" >between two dual routers that would support IS-IS and >IPv4 but not IPv6, or IS-IS and IPv6 but not IPv4. > Well our product is gonna go for testing soon and im pretty sure that the test team would get a kick out of trying topoligies like that. So am just trying to find the "right" answers to their questions. Thanks, Sarav On Fri, 24 Oct 2003 11:55 , Philip Christian sent: >According to strict RFC 1195 all of the prefixes (both >IPv4 and IPv6) will be flooded throughout the area. >IS-IS forms links based on whether IS-IS can get over >the link or not and form an adjacency. Strict RFC >1195 considers that if IS-IS can get over the link, >then so can IPv4, IPv6 and CLNP. It assumes that if a >type of packet is present in the area (or level-2 >subdomain), that all routers can forward it. > >RTA will therefore attempt to forward both IPv4 and >IPv6 packets to both RTB and RTC. > >If for some reason the packets cannot actually get >through then they are just dumped and you have a >blackhole. > >For this reason we have the topological rules of RFC >1195. Basically if IPv4 is routed anywhere in the area >then all routers and links must support it. The same >would be true for IPv6. > >One way to fix this particular type of scenario is the >automatic encapsulation draft; however this appears to >be getting no support at this time, and so (to my >great regret) I can't see it surviving in the IETF. >Folks here seem to prefer running multi-topology (MT). > >However, I can't quite see why you would have a "link" >between two dual routers that would support IS-IS and >IPv4 but not IPv6, or IS-IS and IPv6 but not IPv4. > >Another way to fix this is to split the network into >separate IPv4 and IPv6 topologies, either by putting >them in separate areas or MTs, and then I suppose >running GRE tunnels to get IPv4 and IS-IS over the >IPv6 only bit and IPv6 and IS-IS over the IPv4 bit, or >something like that. The routers will then need to be >able to run two instances of IS-IS. > >Philip > > --- Saravana Kumar sarav_k@spymac.com> wrote: > Dear >All, >> >> I would like to calrify some of my >> assumptions/doubts regarding the calculation >> Ipv4/Ipv6 routes in a single- >> topology heterogenous network supporting a mixture >> of Ipv4 and Ipv6 links. >> >> Consider the following (single-toplogy) network, all >> the 3 routers RTA, RTB, RTC can support ISIS for >> both >> Ipv4 and Ipv6. RTA is connected to RTB through a >> ipv4 only link and is connected to RTC through a >> ipv6 only >> link. >> >> >> -- 1.1.1.1/24 >> / >> ----- RTB >> / \ >> / -- 1:1::/64 >> v4/v6 /v4 >> RTX------- RTA >> \v6 >> \ -- 2.2.2.2/24 >> \ / >> ----- RTC >> \ >> -- 2:2::/64 >> >> Even though RTB advertises both Ipv4 and Ipv6 >> prefixes, i would assume that RTA should learn only >> the Ipv4 >> prefixes advertised by RTB since it does not know >> the Ipv6 nexthop address that it should use to reach >> RTB. >> Similarly RTA should learn only the Ipv6 prefixes >> advertised by RTC. >> >> Whereas RTX which is connected to RTA through a link >> that supports both Ipv4 and Ipv6 would learn all the >> >> prefixes advertised by RTB and RTC (even though its >> obvious that it can never reach some of the prefixes >> that >> it learnt). >> >> I would like to know whether my assuption of this >> behaviour is correct or not... >> >> Thanks, >> Sarav >> >> >> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www1.ietf.org/mailman/listinfo/isis-wg > >________________________________________________________________________ >Want to chat instantly with your online friends? Get the FREE Yahoo! >Messenger http://mail.messenger.yahoo.co.uk > >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Oct 28 09:17:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21752 for ; Tue, 28 Oct 2003 09:17:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUdf-00014W-CR; Tue, 28 Oct 2003 09:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUd1-00010j-As for isis-wg@optimus.ietf.org; Tue, 28 Oct 2003 09:15:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21453; Tue, 28 Oct 2003 09:15:11 -0500 (EST) Message-Id: <200310281415.JAA21453@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-19.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 28 Oct 2003 09:15:11 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-isis-gmpls-extensions-19.txt Pages : 12 Date : 2003-10-27 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.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-gmpls-extensions-19.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-gmpls-extensions-19.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: <2003-10-28093451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28093451.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg