From isis-wg-admin@ietf.org Tue Jul 1 10:56:53 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 KAA03523 for ; Tue, 1 Jul 2003 10:56:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMY5-0001xO-L5; Tue, 01 Jul 2003 10:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XMXX-0001we-FN for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 10:55:28 -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 KAA03471 for ; Tue, 1 Jul 2003 10:55:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XMXU-0005KI-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 10:55:24 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19XMXE-0005JN-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 10:55:09 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h61EplE26834; Tue, 1 Jul 2003 16:51:47 +0200 From: Hannes Gredler To: Naiming Shen Cc: prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? Message-ID: <20030701145147.GA26819@juniper.net> References: <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030630171756.00401A4E48A@prattle.redback.com> User-Agent: Mutt/1.3.28i 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, 1 Jul 2003 16:51:47 +0200 On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: | this draft is the isis part of the IGP capability, please review | and comment, thanks. | | http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt nice work - any idea why the capability bits are aligned in units of 32bits ? - wouldn't it make more sense [and be in the good spirit of IS-IS] to have variable packing on byte boundaries ? /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 15:05: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 PAA11602 for ; Tue, 1 Jul 2003 15:05: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 19XQGP-0001UK-Iy; Tue, 01 Jul 2003 14:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQFT-0001Rw-Ga for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 14:53:03 -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 OAA09488 for ; Tue, 1 Jul 2003 14:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XPTW-0006hK-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 14:03:30 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19XPTV-0006gl-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 14:03:29 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h61I0gr28229; Tue, 1 Jul 2003 20:00:42 +0200 From: Hannes Gredler To: Naiming Shen Cc: prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? Message-ID: <20030701180042.GA28208@juniper.net> References: <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030630171756.00401A4E48A@prattle.redback.com> User-Agent: Mutt/1.3.28i 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, 1 Jul 2003 20:00:42 +0200 On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: | folks, | | this draft is the isis part of the IGP capability, please review | and comment, thanks. | | http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt naiming, when you talk about capabilities in the draft what is really meant ? actual capabilities or potential capabilies ? when does a router has to set a bit ? - e.g. if capability X has been configured or there is in general support for capability X in the current loaded SW; /hannes --- 4.3 Reserved IS-IS Router Capability Bits We have assigned some pre-determined bits to the first capability flag. Bit Capabilities 0-3 Reserved 4 IS-IS graceful restart capable [4] 5 IS-IS and BGP blackhole avoidance capable [6] 6 IS-IS wide metric processing capable [3] 7 IS-IS short metric processing capable [1] 8 IS-IS hmac-md5 authentication capable [5] 9 IS-IS Traffic Engineering support [3] 10 IS-IS point-to-point over LAN [7] 11 IS-IS Path Computation Server discovery [10] 12 M-ISIS capable [8] 13 IS-IS IPv6 capable [9] 14-31 For future assignments --- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 15:31:39 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 PAA13762 for ; Tue, 1 Jul 2003 15:31:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQm1-0003Re-0Y; Tue, 01 Jul 2003 15:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XQkN-0003PU-2o for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 15:25: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 PAA13435 for ; Tue, 1 Jul 2003 15:24:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XQkB-0007S0-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 15:24:47 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19XQkA-0007Rj-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 15:24:46 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61JOCIn027094; Tue, 1 Jul 2003 12:24:13 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-20.cisco.com [10.82.224.20]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFO61598; Tue, 1 Jul 2003 12:24:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hannes Gredler From: Jeff Learman Subject: Re: [Isis-wg] Agenda for Vienna ? Cc: Naiming Shen , prz@xebeo.com, stefano previdi , isis-wg@ietf.org In-Reply-To: <20030701180042.GA28208@juniper.net> References: <20030630171756.00401A4E48A@prattle.redback.com> <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 01 Jul 2003 15:21:10 -0400 Presumably it's functions that are enabled. A protocol doesn't need to say what a router could do if configured differently, just what it's prepared and able to do right now. I suppose that could be made clear in the text. At 02:00 PM 7/1/2003, Hannes Gredler wrote: >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: >| folks, >| >| this draft is the isis part of the IGP capability, please review >| and comment, thanks. >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt > >naiming, > >when you talk about capabilities in the draft what is really meant ? > actual capabilities or potential capabilies ? > > when does a router has to set a bit ? - e.g. if capability X has > been configured or there is in general support for capability X > in the current loaded SW; > >/hannes > >--- > >4.3 Reserved IS-IS Router Capability Bits > > We have assigned some pre-determined bits to the first capability > flag. > > Bit Capabilities > > 0-3 Reserved > 4 IS-IS graceful restart capable [4] > 5 IS-IS and BGP blackhole avoidance capable [6] > 6 IS-IS wide metric processing capable [3] > 7 IS-IS short metric processing capable [1] > 8 IS-IS hmac-md5 authentication capable [5] > 9 IS-IS Traffic Engineering support [3] > 10 IS-IS point-to-point over LAN [7] > 11 IS-IS Path Computation Server discovery [10] > 12 M-ISIS capable [8] > 13 IS-IS IPv6 capable [9] > 14-31 For future assignments > >--- > > > >_______________________________________________ >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 Jul 1 20:08:52 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 UAA21835 for ; Tue, 1 Jul 2003 20:08:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XVAH-0006hZ-Hq; Tue, 01 Jul 2003 20:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XV9U-0006Tc-1V for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 20:07:12 -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 UAA21798 for ; Tue, 1 Jul 2003 20:07:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XV9S-0002om-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 20:07:10 -0400 Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XV9R-0002oL-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 20:07:09 -0400 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h61NwuT22567; Tue, 1 Jul 2003 16:58:56 -0700 (PDT) From: Shankar Vemulapalli To: naiming@redback.com, Jeff Learman cc: Hannes Gredler , prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-Reply-To: <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> Message-ID: References: <20030630171756.00401A4E48A@prattle.redback.com> <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 1 Jul 2003 16:58:56 -0700 (PDT) Hi Naiming & Co - I am not sure on the scope of the "Capability-TLV" - Because, there are some other capabilities that can be included in the capability-TLV in addition to what is mentioned in the draft. For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send the dyn-hostname information. TLV 240 [p2p 3-Way Handshake] is also another capability of the rtr. So, my question is, what criteria we determine to put in to say that the router is capable of doing so & so ? Or - are we OK to add the above two to the existing list ? Also, "Refernces" section can be updated with the latest info. For ex.: [6] is RFC 3277 Just my rumblings.. Thanks, /Shankar At 3:21pm 07/01/03 -0400, Jeff Learman wrote: > > Presumably it's functions that are enabled. A protocol doesn't > need to say what a router could do if configured differently, > just what it's prepared and able to do right now. > > I suppose that could be made clear in the text. > > At 02:00 PM 7/1/2003, Hannes Gredler wrote: > >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: > >| folks, > >| > >| this draft is the isis part of the IGP capability, please review > >| and comment, thanks. > >| > >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt > > > >naiming, > > > >when you talk about capabilities in the draft what is really meant ? > > actual capabilities or potential capabilies ? > > > > when does a router has to set a bit ? - e.g. if capability X has > > been configured or there is in general support for capability X > > in the current loaded SW; > > > >/hannes > > > >--- > > > >4.3 Reserved IS-IS Router Capability Bits > > > > We have assigned some pre-determined bits to the first capability > > flag. > > > > Bit Capabilities > > > > 0-3 Reserved > > 4 IS-IS graceful restart capable [4] > > 5 IS-IS and BGP blackhole avoidance capable [6] > > 6 IS-IS wide metric processing capable [3] > > 7 IS-IS short metric processing capable [1] > > 8 IS-IS hmac-md5 authentication capable [5] > > 9 IS-IS Traffic Engineering support [3] > > 10 IS-IS point-to-point over LAN [7] > > 11 IS-IS Path Computation Server discovery [10] > > 12 M-ISIS capable [8] > > 13 IS-IS IPv6 capable [9] > > 14-31 For future assignments > > > >--- > > > > > > > >_______________________________________________ > >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 > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 21:56:41 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 VAA24468 for ; Tue, 1 Jul 2003 21:56:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XWqn-00018E-CX; Tue, 01 Jul 2003 21:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XWqP-00017t-Py for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 21:55:38 -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 VAA24434 for ; Tue, 1 Jul 2003 21:55:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XWqM-00046d-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 21:55:34 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19XWqM-00046a-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 21:55:34 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 6715880D1EA; Tue, 1 Jul 2003 18:55:29 -0700 (PDT) To: "Jonnala, Nagi" Cc: "'acee@redback.com'" , "'rahul@redback.com'" , "'sshaffer@genuity.com'" , "'jpv@cisco.com'" , isis-wg@ietf.org In-reply-to: Mail from "Jonnala, Nagi" dated Tue, 01 Jul 2003 05:08:12 EDT From: Naiming Shen Message-Id: <20030702015529.6715880D1EA@prattle.redback.com> Subject: [Isis-wg] Re: Comments on Extensions to IS-IS for Advertising Optional Router Capabilities 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, 01 Jul 2003 18:55:29 -0700 Nagi, thanks for the comments, some replies inline. ] Naiming & all, ] ] I have a couple of questions on the draft. ] ] 1) As you mentioned, this feature can be used in MPLS-TE environment (or) by ] the Network management (or) for some other informational purposes. ] ] Having said that, Router-ID may not be available (if TE extensions are not ] implemented) in some implementations. How do we solve that? Shouldn't we ] consider System-ID as the unique identity? ] I think Router-ID is something very simple to implement, does not need to do it along with TE extensions. For this capability extension purpose, it only needs to be an unique 32bits number in the IGP domain. For example, it could use the "IP Interface Address" number in the LSP. But since the router-id is such a useful thing, I would recommend anyone implements this draft to use the "real" router id of the router or the virtual router. This extension came up first with the troubleshooting in mind, and if the router-id is a routable one, it would be useful in operation with an IP address. ] 2) I think advertising the router capabilities do create security concerns. ] For example, if I advertise I don't have HMAC-MD5 capability, then an ] intruder can aim at that specific system. Well, there is some truth to that. But If someone can read my LSPs, then they also can see if my LSP uses HMAC-MD5 or not. If they are sitting on the same LAN, then they can read the other packets and figure that out. ] Infact, one can create a list of ] IS-IS nodes which has/hasn't what capability? ] We hope the operators will do that, and find out any misconfiguration or software mismatch in the network using this capability besides some functional applications. ] Do you consider address those issues in Security Considerations section? ] ] 3) Also there are some widely implemented drafts that deserve mention in the ] Router Capability TLV. For example, three way handshake capability is ] missing and there are some other capabilities too. This draft didn't mention three way handshake as a capability. Also this draft does not mean to be inclusively list all the capabilities, just something we thought could be useful to list with the capability extension. thanks. ] ] Thanks ] Nagi. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 22:03:31 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 WAA24663 for ; Tue, 1 Jul 2003 22:03:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XWxY-0001MO-Qm; Tue, 01 Jul 2003 22:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XWxH-0001M8-Pc for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 22:02: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 WAA24646 for ; Tue, 1 Jul 2003 22:02:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XWxE-0004DV-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 22:02:40 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19XWxE-0004DS-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 22:02:40 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id C2C329890C1; Tue, 1 Jul 2003 19:02:39 -0700 (PDT) To: Hannes Gredler Cc: prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-reply-to: Mail from Hannes Gredler dated Tue, 01 Jul 2003 16:51:47 +0200 <20030701145147.GA26819@juniper.net> From: Naiming Shen Message-Id: <20030702020239.C2C329890C1@prattle.redback.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: Tue, 01 Jul 2003 19:02:39 -0700 Hannes, ] On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: ] ] | this draft is the isis part of the IGP capability, please review ] | and comment, thanks. ] | ] | http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt ] ] nice work - any idea why the capability bits are aligned in units ] of 32bits ? - wouldn't it make more sense [and be in the good spirit ] of IS-IS] to have variable packing on byte boundaries ? thanks. this picture, Figure 1, must be done by a more OSPF oriented person;-) but the TLV itself is not really aligned with 32bits, there is two bytes type/length in front of the TLV. This capability flag is chosen to be 32bits I think is to align with OSPF's choice(used to be in the same draft), but it's also a nice number to start with. We didn't intentionally to have this TLV to be 32bits aligned. thanks. ] ] /hannes ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 22:14:36 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 WAA24926 for ; Tue, 1 Jul 2003 22:14:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX8C-0001zw-SB; Tue, 01 Jul 2003 22:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XX7E-0001zH-OW for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 22:13:00 -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 WAA24908 for ; Tue, 1 Jul 2003 22:12:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XX7B-0004KU-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 22:12:57 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19XX7B-0004KR-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 22:12:57 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 7A5B53CEAA2; Tue, 1 Jul 2003 19:12:57 -0700 (PDT) To: Hannes Gredler Cc: prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-reply-to: Mail from Hannes Gredler dated Tue, 01 Jul 2003 20:00:42 +0200 <20030701180042.GA28208@juniper.net> From: Naiming Shen Message-Id: <20030702021257.7A5B53CEAA2@prattle.redback.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: Tue, 01 Jul 2003 19:12:57 -0700 Hannes, ] ] when you talk about capabilities in the draft what is really meant ? ] actual capabilities or potential capabilies ? ] ] when does a router has to set a bit ? - e.g. if capability X has ] been configured or there is in general support for capability X ] in the current loaded SW; agree with Jeff's comment. the draft meant to say the current implemented capabilities to be announced, unless the configuration disables them. this is in section 4: If this TLV is included in the LSP, the router SHOULD set all the defined bits corresponding to the capabilities which the software supports, unless they are explicitly configured off. thanks. ] ] /hannes ] ] --- ] ] 4.3 Reserved IS-IS Router Capability Bits ] ] We have assigned some pre-determined bits to the first capability ] flag. ] ] Bit Capabilities ] ] 0-3 Reserved ] 4 IS-IS graceful restart capable [4] ] 5 IS-IS and BGP blackhole avoidance capable [6] ] 6 IS-IS wide metric processing capable [3] ] 7 IS-IS short metric processing capable [1] ] 8 IS-IS hmac-md5 authentication capable [5] ] 9 IS-IS Traffic Engineering support [3] ] 10 IS-IS point-to-point over LAN [7] ] 11 IS-IS Path Computation Server discovery [10] ] 12 M-ISIS capable [8] ] 13 IS-IS IPv6 capable [9] ] 14-31 For future assignments ] ] --- ] ] ] ] _______________________________________________ ] Isis-wg mailing list ] Isis-wg@ietf.org ] https://www1.ietf.org/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 22:26:32 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 WAA25106 for ; Tue, 1 Jul 2003 22:26:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XXJp-0002A2-Jr; Tue, 01 Jul 2003 22:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XXJo-00029r-BZ for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 22:26:00 -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 WAA25096 for ; Tue, 1 Jul 2003 22:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XXJl-0004Q5-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 22:25:57 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19XXJk-0004Q2-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 22:25:56 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id D9509299A04; Tue, 1 Jul 2003 19:25:56 -0700 (PDT) To: Shankar Vemulapalli Cc: Jeff Learman , Hannes Gredler , prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-reply-to: Mail from Shankar Vemulapalli dated Tue, 01 Jul 2003 16:58:56 PDT From: Naiming Shen Message-Id: <20030702022556.D9509299A04@prattle.redback.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: Tue, 01 Jul 2003 19:25:56 -0700 Hi Shankar, ] Hi Naiming & Co - ] ] I am not sure on the scope of the "Capability-TLV" - ] Because, there are some other capabilities that can be included ] in the capability-TLV in addition to what is mentioned in the draft. ] ] For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send ] the dyn-hostname information. ] TLV 240 [p2p 3-Way Handshake] is also another capability of ] the rtr. ] For those two, I think the initial thinking was that, the Dyn-hostname is flooded everywhere, one can easily see it, and the 3way handshake is such a basic thing for p2p, we assumed it didn't need to cost a bit. But they can be added if folks think so. I guess Nagi was asking the similar thing in another email, and this draft is not meant to be inclusive on those features. We can add the existing one in as people agree, and with new features being developed later, people can include a new capability bit in their document with ietf consensus. ] So, my question is, what criteria we determine to put in to say that the ] router is capable of doing so & so ? ] Or - are we OK to add the above two to the existing list ? ] ] Also, "Refernces" section can be updated with the latest info. ] For ex.: [6] is RFC 3277 sure. thanks. ] ] Just my rumblings.. ] ] Thanks, ] ] ] /Shankar ] ] At 3:21pm 07/01/03 -0400, Jeff Learman wrote: ] > ] > Presumably it's functions that are enabled. A protocol doesn't ] > need to say what a router could do if configured differently, ] > just what it's prepared and able to do right now. ] > ] > I suppose that could be made clear in the text. ] > ] > At 02:00 PM 7/1/2003, Hannes Gredler wrote: ] > >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: ] > >| folks, ] > >| ] > >| this draft is the isis part of the IGP capability, please review ] > >| and comment, thanks. ] > >| ] > >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt ] > > ] > >naiming, ] > > ] > >when you talk about capabilities in the draft what is really meant ? ] > > actual capabilities or potential capabilies ? ] > > ] > > when does a router has to set a bit ? - e.g. if capability X has ] > > been configured or there is in general support for capability X ] > > in the current loaded SW; ] > > ] > >/hannes ] > > ] > >--- ] > > ] > >4.3 Reserved IS-IS Router Capability Bits ] > > ] > > We have assigned some pre-determined bits to the first capability ] > > flag. ] > > ] > > Bit Capabilities ] > > ] > > 0-3 Reserved ] > > 4 IS-IS graceful restart capable [4] ] > > 5 IS-IS and BGP blackhole avoidance capable [6] ] > > 6 IS-IS wide metric processing capable [3] ] > > 7 IS-IS short metric processing capable [1] ] > > 8 IS-IS hmac-md5 authentication capable [5] ] > > 9 IS-IS Traffic Engineering support [3] ] > > 10 IS-IS point-to-point over LAN [7] ] > > 11 IS-IS Path Computation Server discovery [10] ] > > 12 M-ISIS capable [8] ] > > 13 IS-IS IPv6 capable [9] ] > > 14-31 For future assignments ] > > ] > >--- ] > > ] > > ] > > ] > >_______________________________________________ ] > >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 ] > - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 23:30:41 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 XAA26159 for ; Tue, 1 Jul 2003 23:30:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XYJl-0003Y5-PL; Tue, 01 Jul 2003 23:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XYJU-0003XM-5k for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 23:29:44 -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 XAA26135 for ; Tue, 1 Jul 2003 23:29:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XYJS-0004pV-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 23:29:42 -0400 Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XYJR-0004pR-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 23:29:41 -0400 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h623LYT25325; Tue, 1 Jul 2003 20:21:34 -0700 (PDT) From: Shankar Vemulapalli To: Naiming Shen cc: Jeff Learman , Hannes Gredler , prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-Reply-To: <20030702022556.D9509299A04@prattle.redback.com> Message-ID: References: <20030702022556.D9509299A04@prattle.redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 1 Jul 2003 20:21:34 -0700 (PDT) Hi Naiming - Thanks for getting back. Agree with your reasoning below - But if we apply the reasoning to the capabilities mentioned in the draft - bit [7] for ISIS-short metric is as you know is the default in every possible implementation :-) So, we as well can spare this bit for some other capability ? Just a thought - /Shankar At 7:25pm 07/01/03 -0700, Naiming Shen wrote: > > Hi Shankar, > > ] Hi Naiming & Co - > ] > ] I am not sure on the scope of the "Capability-TLV" - > ] Because, there are some other capabilities that can be included > ] in the capability-TLV in addition to what is mentioned in the draft. > ] > ] For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send > ] the dyn-hostname information. > ] TLV 240 [p2p 3-Way Handshake] is also another capability of > ] the rtr. > ] > > For those two, I think the initial thinking was that, the Dyn-hostname > is flooded everywhere, one can easily see it, and the 3way handshake > is such a basic thing for p2p, we assumed it didn't need to cost a bit. > But they can be added if folks think so. > > I guess Nagi was asking the similar thing in another email, and this > draft is not meant to be inclusive on those features. We can add the > existing one in as people agree, and with new features being developed later, > people can include a new capability bit in their document with ietf > consensus. > > ] So, my question is, what criteria we determine to put in to say that the > ] router is capable of doing so & so ? > ] Or - are we OK to add the above two to the existing list ? > ] > ] Also, "Refernces" section can be updated with the latest info. > ] For ex.: [6] is RFC 3277 > > sure. thanks. > > ] > ] Just my rumblings.. > ] > ] Thanks, > ] > ] > ] /Shankar > ] > ] At 3:21pm 07/01/03 -0400, Jeff Learman wrote: > ] > > ] > Presumably it's functions that are enabled. A protocol doesn't > ] > need to say what a router could do if configured differently, > ] > just what it's prepared and able to do right now. > ] > > ] > I suppose that could be made clear in the text. > ] > > ] > At 02:00 PM 7/1/2003, Hannes Gredler wrote: > ] > >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: > ] > >| folks, > ] > >| > ] > >| this draft is the isis part of the IGP capability, please review > ] > >| and comment, thanks. > ] > >| > ] > >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt > ] > > > ] > >naiming, > ] > > > ] > >when you talk about capabilities in the draft what is really meant ? > ] > > actual capabilities or potential capabilies ? > ] > > > ] > > when does a router has to set a bit ? - e.g. if capability X has > ] > > been configured or there is in general support for capability X > ] > > in the current loaded SW; > ] > > > ] > >/hannes > ] > > > ] > >--- > ] > > > ] > >4.3 Reserved IS-IS Router Capability Bits > ] > > > ] > > We have assigned some pre-determined bits to the first capability > ] > > flag. > ] > > > ] > > Bit Capabilities > ] > > > ] > > 0-3 Reserved > ] > > 4 IS-IS graceful restart capable [4] > ] > > 5 IS-IS and BGP blackhole avoidance capable [6] > ] > > 6 IS-IS wide metric processing capable [3] > ] > > 7 IS-IS short metric processing capable [1] > ] > > 8 IS-IS hmac-md5 authentication capable [5] > ] > > 9 IS-IS Traffic Engineering support [3] > ] > > 10 IS-IS point-to-point over LAN [7] > ] > > 11 IS-IS Path Computation Server discovery [10] > ] > > 12 M-ISIS capable [8] > ] > > 13 IS-IS IPv6 capable [9] > ] > > 14-31 For future assignments > ] > > > ] > >--- > ] > > > ] > > > ] > > > ] > >_______________________________________________ > ] > >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 > ] > > > - Naiming > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 1 23:42:34 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 XAA26633 for ; Tue, 1 Jul 2003 23:42:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XYVN-00046N-65; Tue, 01 Jul 2003 23:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XYUP-00045p-3U for isis-wg@optimus.ietf.org; Tue, 01 Jul 2003 23:41:01 -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 XAA26592 for ; Tue, 1 Jul 2003 23:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XYUN-0004xy-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 23:40:59 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19XYUM-0004xv-00 for isis-wg@ietf.org; Tue, 01 Jul 2003 23:40:58 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id C2DE8566D08; Tue, 1 Jul 2003 20:40:58 -0700 (PDT) To: Shankar Vemulapalli Cc: Naiming Shen , Jeff Learman , Hannes Gredler , prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] Agenda for Vienna ? In-reply-to: Mail from Shankar Vemulapalli dated Tue, 01 Jul 2003 20:21:34 PDT From: Naiming Shen Message-Id: <20030702034058.C2DE8566D08@prattle.redback.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: Tue, 01 Jul 2003 20:40:58 -0700 Hi Shankar, ] Hi Naiming - ] ] Thanks for getting back. ] ] Agree with your reasoning below - But if we apply the reasoning to the ] capabilities mentioned in the draft - bit [7] for ISIS-short metric ] is as you know is the default in every possible implementation :-) ] For this particular one, the original draft didn't have that. Until one day I spent lots of hours on one particular problem and couldn't easily figure out what went wrong. It turned out the "metric style" default was changed from being "short" to "wide". Thus I was thinking it actually was useful to put the "short metric" as the capability in, it would be nice in the future to have software to detect there is someone on the network is using a different style than me and give out a warning message. thanks. ] So, we as well can spare this bit for some other capability ? ] ] Just a thought - ] ] ] /Shankar ] ] At 7:25pm 07/01/03 -0700, Naiming Shen wrote: ] > ] > Hi Shankar, ] > ] > ] Hi Naiming & Co - ] > ] ] > ] I am not sure on the scope of the "Capability-TLV" - ] > ] Because, there are some other capabilities that can be included ] > ] in the capability-TLV in addition to what is mentioned in the draft. ] > ] ] > ] For ex.: TLV 137 [dyn-hostname] is a capability of the rtr to send ] > ] the dyn-hostname information. ] > ] TLV 240 [p2p 3-Way Handshake] is also another capability of ] > ] the rtr. ] > ] ] > ] > For those two, I think the initial thinking was that, the Dyn-hostname ] > is flooded everywhere, one can easily see it, and the 3way handshake ] > is such a basic thing for p2p, we assumed it didn't need to cost a bit. ] > But they can be added if folks think so. ] > ] > I guess Nagi was asking the similar thing in another email, and this ] > draft is not meant to be inclusive on those features. We can add the ] > existing one in as people agree, and with new features being developed lat er, ] > people can include a new capability bit in their document with ietf ] > consensus. ] > ] > ] So, my question is, what criteria we determine to put in to say that th e ] > ] router is capable of doing so & so ? ] > ] Or - are we OK to add the above two to the existing list ? ] > ] ] > ] Also, "Refernces" section can be updated with the latest info. ] > ] For ex.: [6] is RFC 3277 ] > ] > sure. thanks. ] > ] > ] ] > ] Just my rumblings.. ] > ] ] > ] Thanks, ] > ] ] > ] ] > ] /Shankar ] > ] ] > ] At 3:21pm 07/01/03 -0400, Jeff Learman wrote: ] > ] > ] > ] > Presumably it's functions that are enabled. A protocol doesn't ] > ] > need to say what a router could do if configured differently, ] > ] > just what it's prepared and able to do right now. ] > ] > ] > ] > I suppose that could be made clear in the text. ] > ] > ] > ] > At 02:00 PM 7/1/2003, Hannes Gredler wrote: ] > ] > >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: ] > ] > >| folks, ] > ] > >| ] > ] > >| this draft is the isis part of the IGP capability, please review ] > ] > >| and comment, thanks. ] > ] > >| ] > ] > >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt ] > ] > > ] > ] > >naiming, ] > ] > > ] > ] > >when you talk about capabilities in the draft what is really meant ? ] > ] > > actual capabilities or potential capabilies ? ] > ] > > ] > ] > > when does a router has to set a bit ? - e.g. if capability X has ] > ] > > been configured or there is in general support for capability X ] > ] > > in the current loaded SW; ] > ] > > ] > ] > >/hannes ] > ] > > ] > ] > >--- ] > ] > > ] > ] > >4.3 Reserved IS-IS Router Capability Bits ] > ] > > ] > ] > > We have assigned some pre-determined bits to the first capability ] > ] > > flag. ] > ] > > ] > ] > > Bit Capabilities ] > ] > > ] > ] > > 0-3 Reserved ] > ] > > 4 IS-IS graceful restart capable [4] ] > ] > > 5 IS-IS and BGP blackhole avoidance capable [6] ] > ] > > 6 IS-IS wide metric processing capable [3] ] > ] > > 7 IS-IS short metric processing capable [1] ] > ] > > 8 IS-IS hmac-md5 authentication capable [5] ] > ] > > 9 IS-IS Traffic Engineering support [3] ] > ] > > 10 IS-IS point-to-point over LAN [7] ] > ] > > 11 IS-IS Path Computation Server discovery [10] ] > ] > > 12 M-ISIS capable [8] ] > ] > > 13 IS-IS IPv6 capable [9] ] > ] > > 14-31 For future assignments ] > ] > > ] > ] > >--- ] > ] > > ] > ] > > ] > ] > > ] > ] > >_______________________________________________ ] > ] > >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 ] > ] > ] > ] > - Naiming ] > - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 01:33:49 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 BAA28333 for ; Wed, 2 Jul 2003 01:33:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaEn-0006VJ-Hh; Wed, 02 Jul 2003 01: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 19XaEZ-0006V1-Le for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 01:32:47 -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 BAA28311 for ; Wed, 2 Jul 2003 01:32:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XaEW-0005sL-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 01:32:44 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19XaEV-0005rp-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 01:32:43 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h625UXK29925; Wed, 2 Jul 2003 07:30:33 +0200 From: Hannes Gredler To: Jeff Learman Cc: Naiming Shen , prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt Message-ID: <20030702053033.GA29892@juniper.net> References: <20030630171756.00401A4E48A@prattle.redback.com> <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> User-Agent: Mutt/1.3.28i 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, 2 Jul 2003 07:30:33 +0200 jeff, changed subject - On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: | | Presumably it's functions that are enabled. A protocol doesn't | need to say what a router could do if configured differently, | just what it's prepared and able to do right now. hmmm don't agree - that brings us back to the question what is the objective of the draft ? i read between the lines that it was intended as quick view what the IS-IS SW can do and whats enabled; the network administrator should have the choice to a. upgrade the software or b. turn feature X on for doing that IMHO you need two subTLVs/bitvectors 1. one displaying the SW capabilities 2. one displaying whats actually configured i agree that 2. is largely redundant becasue one can look at the TLV list of a specific node to see what is turned on; or in other words: what information does the capability vector as-is provide that cannot be gathered from the TLV list ? [beside link-local things like ptp-IIH over LANs, graceful restart etc.] /hannes | I suppose that could be made clear in the text. | | At 02:00 PM 7/1/2003, Hannes Gredler wrote: | >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: | >| folks, | >| | >| this draft is the isis part of the IGP capability, please review | >| and comment, thanks. | >| | >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt | > | >naiming, | > | >when you talk about capabilities in the draft what is really meant ? | > actual capabilities or potential capabilies ? | > | > when does a router has to set a bit ? - e.g. if capability X has | > been configured or there is in general support for capability X | > in the current loaded SW; | > | >/hannes | > | >--- | > | >4.3 Reserved IS-IS Router Capability Bits | > | > We have assigned some pre-determined bits to the first capability | > flag. | > | > Bit Capabilities | > | > 0-3 Reserved | > 4 IS-IS graceful restart capable [4] | > 5 IS-IS and BGP blackhole avoidance capable [6] | > 6 IS-IS wide metric processing capable [3] | > 7 IS-IS short metric processing capable [1] | > 8 IS-IS hmac-md5 authentication capable [5] | > 9 IS-IS Traffic Engineering support [3] | > 10 IS-IS point-to-point over LAN [7] | > 11 IS-IS Path Computation Server discovery [10] | > 12 M-ISIS capable [8] | > 13 IS-IS IPv6 capable [9] | > 14-31 For future assignments _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 01:49:37 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 BAA28667 for ; Wed, 2 Jul 2003 01:49:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaUH-00073z-DW; Wed, 02 Jul 2003 01:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XaTg-00073M-BY for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 01:48:24 -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 BAA28652 for ; Wed, 2 Jul 2003 01:48:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XaTd-000646-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 01:48:21 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XaTc-00063l-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 01:48:20 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h625lmf0014857; Tue, 1 Jul 2003 22:47:49 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-20.cisco.com [10.82.224.20]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFP94328; Tue, 1 Jul 2003 22:47:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702013832.0207dd00@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Hannes Gredler From: Jeff Learman Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt Cc: Naiming Shen , prz@xebeo.com, stefano previdi , isis-wg@ietf.org In-Reply-To: <20030702053033.GA29892@juniper.net> References: <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> <20030630171756.00401A4E48A@prattle.redback.com> <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 02 Jul 2003 01:41:22 -0400 I think we want to know what a router IS DOING. We should rely on product documentation to find out what it is capable of being configured to do and how to do so. Or is this the "marketing protocol" ;) Jeff At 01:30 AM 7/2/2003, Hannes Gredler wrote: >jeff, > >changed subject - > >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: >| >| Presumably it's functions that are enabled. A protocol doesn't >| need to say what a router could do if configured differently, >| just what it's prepared and able to do right now. > >hmmm don't agree - that brings us back to the question what >is the objective of the draft ? i read between the lines that >it was intended as quick view what the IS-IS SW can do and whats >enabled; > >the network administrator should have the choice to > > a. upgrade the software or > b. turn feature X on > >for doing that IMHO you need two subTLVs/bitvectors > > 1. one displaying the SW capabilities > 2. one displaying whats actually configured > >i agree that 2. is largely redundant becasue one can >look at the TLV list of a specific node to see what >is turned on; > >or in other words: what information does the >capability vector as-is provide that cannot >be gathered from the TLV list ? [beside link-local >things like ptp-IIH over LANs, graceful restart etc.] > >/hannes > >| I suppose that could be made clear in the text. >| >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: >| >| folks, >| >| >| >| this draft is the isis part of the IGP capability, please review >| >| and comment, thanks. >| >| >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt >| > >| >naiming, >| > >| >when you talk about capabilities in the draft what is really meant ? >| > actual capabilities or potential capabilies ? >| > >| > when does a router has to set a bit ? - e.g. if capability X has >| > been configured or there is in general support for capability X >| > in the current loaded SW; >| > >| >/hannes >| > >| >--- >| > >| >4.3 Reserved IS-IS Router Capability Bits >| > >| > We have assigned some pre-determined bits to the first capability >| > flag. >| > >| > Bit Capabilities >| > >| > 0-3 Reserved >| > 4 IS-IS graceful restart capable [4] >| > 5 IS-IS and BGP blackhole avoidance capable [6] >| > 6 IS-IS wide metric processing capable [3] >| > 7 IS-IS short metric processing capable [1] >| > 8 IS-IS hmac-md5 authentication capable [5] >| > 9 IS-IS Traffic Engineering support [3] >| > 10 IS-IS point-to-point over LAN [7] >| > 11 IS-IS Path Computation Server discovery [10] >| > 12 M-ISIS capable [8] >| > 13 IS-IS IPv6 capable [9] >| > 14-31 For future assignments _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 02:11:39 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 CAA10512 for ; Wed, 2 Jul 2003 02:11:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xapa-0008KK-Bc; Wed, 02 Jul 2003 02:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xaog-0008Cn-K2 for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 02:10:06 -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 CAA09364 for ; Wed, 2 Jul 2003 02:10:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xaoc-0006DI-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 02:10:02 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19Xaob-0006D8-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 02:10:01 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h6267sx30279; Wed, 2 Jul 2003 08:07:54 +0200 From: Hannes Gredler To: Jeff Learman Cc: Naiming Shen , prz@xebeo.com, stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt Message-ID: <20030702060754.GA30173@juniper.net> References: <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> <20030630171756.00401A4E48A@prattle.redback.com> <3F00275A.9080807@xebeo.com> <20030630171756.00401A4E48A@prattle.redback.com> <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> <4.3.2.7.2.20030702013832.0207dd00@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030702013832.0207dd00@dingdong.cisco.com> User-Agent: Mutt/1.3.28i 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, 2 Jul 2003 08:07:54 +0200 On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote: | | I think we want to know what a router IS DOING. We should | rely on product documentation to find out what it is capable of | being configured to do and how to do so. Or is this the "marketing | protocol" ;) well if this would be the "marketing proto" then we would need probably to dedicate a few fragments ... wrt what the router IS doing ? - i still got no answer to my original question: what information does the capability vector as-is provide that cannot be gathered from the TLV list of the LSP? [beside link-local things like ptp-IIH over LANs, graceful restart etc.] --- also there may be some need to spend more bits as some of the features being listed in the draft may have a asymmetric nature; i.e. a router does not actively send a certain TLV but may be capable of processing this TLV on receipt; ... sort/wide metric and the completetely wild [i.e. very vendor has its own] transition methods are a good example; /hannes | Jeff | | At 01:30 AM 7/2/2003, Hannes Gredler wrote: | >jeff, | > | >changed subject - | > | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: | >| | >| Presumably it's functions that are enabled. A protocol doesn't | >| need to say what a router could do if configured differently, | >| just what it's prepared and able to do right now. | > | >hmmm don't agree - that brings us back to the question what | >is the objective of the draft ? i read between the lines that | >it was intended as quick view what the IS-IS SW can do and whats | >enabled; | > | >the network administrator should have the choice to | > | > a. upgrade the software or | > b. turn feature X on | > | >for doing that IMHO you need two subTLVs/bitvectors | > | > 1. one displaying the SW capabilities | > 2. one displaying whats actually configured | > | >i agree that 2. is largely redundant becasue one can | >look at the TLV list of a specific node to see what | >is turned on; | > | >or in other words: what information does the | >capability vector as-is provide that cannot | >be gathered from the TLV list ? [beside link-local | >things like ptp-IIH over LANs, graceful restart etc.] | > | >/hannes | > | >| I suppose that could be made clear in the text. | >| | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: | >| >| folks, | >| >| | >| >| this draft is the isis part of the IGP capability, please review | >| >| and comment, thanks. | >| >| | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt | >| > | >| >naiming, | >| > | >| >when you talk about capabilities in the draft what is really meant ? | >| > actual capabilities or potential capabilies ? | >| > | >| > when does a router has to set a bit ? - e.g. if capability X has | >| > been configured or there is in general support for capability X | >| > in the current loaded SW; | >| > | >| >/hannes | >| > | >| >--- | >| > | >| >4.3 Reserved IS-IS Router Capability Bits | >| > | >| > We have assigned some pre-determined bits to the first capability | >| > flag. | >| > | >| > Bit Capabilities | >| > | >| > 0-3 Reserved | >| > 4 IS-IS graceful restart capable [4] | >| > 5 IS-IS and BGP blackhole avoidance capable [6] | >| > 6 IS-IS wide metric processing capable [3] | >| > 7 IS-IS short metric processing capable [1] | >| > 8 IS-IS hmac-md5 authentication capable [5] | >| > 9 IS-IS Traffic Engineering support [3] | >| > 10 IS-IS point-to-point over LAN [7] | >| > 11 IS-IS Path Computation Server discovery [10] | >| > 12 M-ISIS capable [8] | >| > 13 IS-IS IPv6 capable [9] | >| > 14-31 For future assignments _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 02:23:34 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 CAA19233 for ; Wed, 2 Jul 2003 02:23:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xb1B-0000WL-Fu; Wed, 02 Jul 2003 02:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xb0B-0000Vm-VO for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 02:22:00 -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 CAA17490 for ; Wed, 2 Jul 2003 02:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xb08-0006KJ-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 02:21:56 -0400 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19Xb07-0006Jy-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 02:21:55 -0400 Received: from there (ams-clip-vpn-dhcp4182.cisco.com [10.61.80.85]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with SMTP id h626Dgp13823; Wed, 2 Jul 2003 08:13:45 +0200 (CEST) Message-Id: <200307020613.h626Dgp13823@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Hannes Gredler , Jeff Learman Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt X-Mailer: KMail [version 1.3.1] Cc: Naiming Shen , prz@xebeo.com, isis-wg@ietf.org References: <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> <4.3.2.7.2.20030702013832.0207dd00@dingdong.cisco.com> <20030702060754.GA30173@juniper.net> In-Reply-To: <20030702060754.GA30173@juniper.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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, 2 Jul 2003 08:13:27 +0200 Content-Transfer-Encoding: quoted-printable On Wednesday 02 July 2003 08:07, Hannes Gredler wrote: > On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote: > |=20 > | I think we want to know what a router IS DOING. We should > | rely on product documentation to find out what it is capable of > | being configured to do and how to do so. Or is this the "marketing > | protocol" ;) >=20 > well if this would be the "marketing proto" then we would need probably > to dedicate a few fragments ... >=20 > wrt what the router IS doing ? - i still got no answer > to my original question: >=20 > what information does the capability vector as-is provide that cannot > be gathered from the TLV list of the LSP? [beside link-local > things like ptp-IIH over LANs, graceful restart etc.] I agree. Note that the capabilities draft has been originally=20 written for propagating Traffic Engineering capabilities that=20 couldn't be inferred from the existance (or absence) of TE=20 sub TLV. The first capability defined was the PCS (Path=20 Computation Server) which tells that the box is capable to=20 compute path across area/domain boundaries (or something=20 similar to that, sorry I'm not a TE expert). Then, for reasnos I don't know, we added other capabilities=20 bits&flags but not sure it makes a lot of sense. s. >=20 >=20 > --- > also there may be some need to spend more bits as some of the features > being listed in the draft may have a asymmetric nature; i.e. > a router does not actively send a certain TLV but may be capable > of processing this TLV on receipt; ... sort/wide metric and the > completetely wild [i.e. very vendor has its own] transition methods > are a good example; >=20 >=20 > /hannes >=20 > | Jeff > |=20 > | At 01:30 AM 7/2/2003, Hannes Gredler wrote: > | >jeff, > | > > | >changed subject -=20 > | > > | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: > | >|=20 > | >| Presumably it's functions that are enabled. A protocol doesn't > | >| need to say what a router could do if configured differently, > | >| just what it's prepared and able to do right now. > | > > | >hmmm don't agree - that brings us back to the question what > | >is the objective of the draft ? i read between the lines that > | >it was intended as quick view what the IS-IS SW can do and whats > | >enabled; > | > > | >the network administrator should have the choice to > | > > | > a. upgrade the software or > | > b. turn feature X on > | > > | >for doing that IMHO you need two subTLVs/bitvectors > | > > | > 1. one displaying the SW capabilities > | > 2. one displaying whats actually configured > | > > | >i agree that 2. is largely redundant becasue one can > | >look at the TLV list of a specific node to see what > | >is turned on; > | > > | >or in other words: what information does the > | >capability vector as-is provide that cannot > | >be gathered from the TLV list ? [beside link-local > | >things like ptp-IIH over LANs, graceful restart etc.] > | > > | >/hannes > | > > | >| I suppose that could be made clear in the text. > | >|=20 > | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: > | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: > | >| >| folks, > | >| >|=20 > | >| >| this draft is the isis part of the IGP capability, please revie= w > | >| >| and comment, thanks. > | >| >|=20 > | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.= txt > | >| > > | >| >naiming, > | >| > > | >| >when you talk about capabilities in the draft what is really mean= t ? > | >| > actual capabilities or potential capabilies ? > | >| > > | >| > when does a router has to set a bit ? - e.g. if capability X ha= s > | >| > been configured or there is in general support for capability X > | >| > in the current loaded SW; > | >| > > | >| >/hannes > | >| > > | >| >--- > | >| > > | >| >4.3 Reserved IS-IS Router Capability Bits > | >| > > | >| > We have assigned some pre-determined bits to the first capabil= ity=20 > | >| > flag. > | >| > =20 > | >| > Bit Capabilities > | >| > =20 > | >| > 0-3 Reserved > | >| > 4 IS-IS graceful restart capable [4] > | >| > 5 IS-IS and BGP blackhole avoidance capable [6] > | >| > 6 IS-IS wide metric processing capable [3] > | >| > 7 IS-IS short metric processing capable [1] > | >| > 8 IS-IS hmac-md5 authentication capable [5] > | >| > 9 IS-IS Traffic Engineering support [3] > | >| > 10 IS-IS point-to-point over LAN [7] > | >| > 11 IS-IS Path Computation Server discovery [10] > | >| > 12 M-ISIS capable [8] > | >| > 13 IS-IS IPv6 capable [9] > | >| > 14-31 For future assignments >=20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 08:36:25 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 IAA12027 for ; Wed, 2 Jul 2003 08:36:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgpB-0006xw-BM; Wed, 02 Jul 2003 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XgoQ-0006wQ-MU for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 08:34:14 -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 IAA11689 for ; Wed, 2 Jul 2003 08:34:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XgoP-00047T-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 08:34:13 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19XgoO-00047O-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 08:34:12 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h6196hjE000576 for ; Tue, 1 Jul 2003 02:06:43 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h6186D7q022026 for ; Tue, 1 Jul 2003 03:06:14 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Jul 2003 05:06:20 -0400 Message-ID: From: "Jonnala, Nagi" To: "'Naiming Shen'" , "'acee@redback.com'" , "'rahul@redback.com'" , "'sshaffer@genuity.com'" , "'jpv@cisco.com'" Cc: isis-wg@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Comments on Extensions to IS-IS for Advertising Optional Router Capabilities 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, 1 Jul 2003 05:08:12 -0400 Naiming & all, I have a couple of questions on the draft. 1) As you mentioned, this feature can be used in MPLS-TE environment (or) by the Network management (or) for some other informational purposes. Having said that, Router-ID may not be available (if TE extensions are not implemented) in some implementations. How do we solve that? Shouldn't we consider System-ID as the unique identity? 2) I think advertising the router capabilities do create security concerns. For example, if I advertise I don't have HMAC-MD5 capability, then an intruder can aim at that specific system. Infact, one can create a list of IS-IS nodes which has/hasn't what capability? Do you consider address those issues in Security Considerations section? 3) Also there are some widely implemented drafts that deserve mention in the Router Capability TLV. For example, three way handshake capability is missing and there are some other capabilities too. Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 09:08:11 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 JAA14767 for ; Wed, 2 Jul 2003 09:08:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhK9-0007yi-U1; Wed, 02 Jul 2003 09:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhJT-0007wD-H8 for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 09:06: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 JAA14524 for ; Wed, 2 Jul 2003 09:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhJS-0005Du-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 09:06:18 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19XhJQ-0005Cr-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 09:06:17 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h62D5Rpr004463; Wed, 2 Jul 2003 06:05:30 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-20.cisco.com [10.82.224.20]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFQ79620; Wed, 2 Jul 2003 06:05:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702090043.020e69f8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Jonnala, Nagi" From: Jeff Learman Subject: Re: [Isis-wg] Comments on Extensions to IS-IS for Advertising Optional Router Capabilities Cc: "'Naiming Shen'" , "'acee@redback.com'" , "'rahul@redback.com'" , "'sshaffer@genuity.com'" , "'jpv@cisco.com'" , isis-wg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 02 Jul 2003 09:02:01 -0400 At 05:08 AM 7/1/2003, Jonnala, Nagi wrote: >1) As you mentioned, this feature can be used in MPLS-TE environment (or) by >the Network management (or) for some other informational purposes. > >Having said that, Router-ID may not be available (if TE extensions are not >implemented) in some implementations. How do we solve that? Shouldn't we >consider System-ID as the unique identity? Good point. I wondered about that. Note that the draft doesn't say the LDP router ID should be used. Is that necessary, or can any unique numbering scheme be used? If it's necessary to use the LDP Router ID for TE purposes, that should be made explicit. Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 09:54:39 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 JAA14768 for ; Wed, 2 Jul 2003 09:08: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 19XhK9-0007yE-9E; Wed, 02 Jul 2003 09:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XhJD-0007w1-7H for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 09:06:03 -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 JAA14504 for ; Wed, 2 Jul 2003 09:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XhJB-0005DE-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 09:06:01 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19XhJA-0005Cg-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 09:06:00 -0400 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h62D5Rpp004463; Wed, 2 Jul 2003 06:05:27 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-20.cisco.com [10.82.224.20]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFQ79614; Wed, 2 Jul 2003 06:05:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702085556.01fba9e8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: stefano previdi From: Jeff Learman Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt Cc: Hannes Gredler , Naiming Shen , prz@xebeo.com, isis-wg@ietf.org In-Reply-To: <200307020613.h626Dgp13823@strange-brew.cisco.com> References: <20030702060754.GA30173@juniper.net> <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> <4.3.2.7.2.20030702013832.0207dd00@dingdong.cisco.com> <20030702060754.GA30173@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 02 Jul 2003 09:04:57 -0400 I won't comment on all the items, but I'd think it would be useful to know whether a router is ignoring wide metrics, and you can't tell whether it's using them or not in its SPF calculation from looking at its TLVs, can you? However, the description for the item probably isn't clear enough for us to know whether "wide metric capable" means whether it would emit wide metrics or whether it would use them in calculations, so perhaps more text is in order there. Or perhaps I'm misremembering, and no router would ever emit wide metrics and yet disregard them in SPF. Regards, Jeff At 02:13 AM 7/2/2003, stefano previdi wrote: >On Wednesday 02 July 2003 08:07, Hannes Gredler wrote: >> On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote: >> | >> | I think we want to know what a router IS DOING. We should >> | rely on product documentation to find out what it is capable of >> | being configured to do and how to do so. Or is this the "marketing >> | protocol" ;) >> >> well if this would be the "marketing proto" then we would need probably >> to dedicate a few fragments ... >> >> wrt what the router IS doing ? - i still got no answer >> to my original question: >> >> what information does the capability vector as-is provide that cannot >> be gathered from the TLV list of the LSP? [beside link-local >> things like ptp-IIH over LANs, graceful restart etc.] > >I agree. Note that the capabilities draft has been originally >written for propagating Traffic Engineering capabilities that >couldn't be inferred from the existance (or absence) of TE >sub TLV. The first capability defined was the PCS (Path >Computation Server) which tells that the box is capable to >compute path across area/domain boundaries (or something >similar to that, sorry I'm not a TE expert). > >Then, for reasnos I don't know, we added other capabilities >bits&flags but not sure it makes a lot of sense. > >s. > >> >> >> --- >> also there may be some need to spend more bits as some of the features >> being listed in the draft may have a asymmetric nature; i.e. >> a router does not actively send a certain TLV but may be capable >> of processing this TLV on receipt; ... sort/wide metric and the >> completetely wild [i.e. very vendor has its own] transition methods >> are a good example; >> >> >> /hannes >> >> | Jeff >> | >> | At 01:30 AM 7/2/2003, Hannes Gredler wrote: >> | >jeff, >> | > >> | >changed subject - >> | > >> | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: >> | >| >> | >| Presumably it's functions that are enabled. A protocol doesn't >> | >| need to say what a router could do if configured differently, >> | >| just what it's prepared and able to do right now. >> | > >> | >hmmm don't agree - that brings us back to the question what >> | >is the objective of the draft ? i read between the lines that >> | >it was intended as quick view what the IS-IS SW can do and whats >> | >enabled; >> | > >> | >the network administrator should have the choice to >> | > >> | > a. upgrade the software or >> | > b. turn feature X on >> | > >> | >for doing that IMHO you need two subTLVs/bitvectors >> | > >> | > 1. one displaying the SW capabilities >> | > 2. one displaying whats actually configured >> | > >> | >i agree that 2. is largely redundant becasue one can >> | >look at the TLV list of a specific node to see what >> | >is turned on; >> | > >> | >or in other words: what information does the >> | >capability vector as-is provide that cannot >> | >be gathered from the TLV list ? [beside link-local >> | >things like ptp-IIH over LANs, graceful restart etc.] >> | > >> | >/hannes >> | > >> | >| I suppose that could be made clear in the text. >> | >| >> | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: >> | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: >> | >| >| folks, >> | >| >| >> | >| >| this draft is the isis part of the IGP capability, please review >> | >| >| and comment, thanks. >> | >| >| >> | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt >> | >| > >> | >| >naiming, >> | >| > >> | >| >when you talk about capabilities in the draft what is really meant ? >> | >| > actual capabilities or potential capabilies ? >> | >| > >> | >| > when does a router has to set a bit ? - e.g. if capability X has >> | >| > been configured or there is in general support for capability X >> | >| > in the current loaded SW; >> | >| > >> | >| >/hannes >> | >| > >> | >| >--- >> | >| > >> | >| >4.3 Reserved IS-IS Router Capability Bits >> | >| > >> | >| > We have assigned some pre-determined bits to the first capability >> | >| > flag. >> | >| > >> | >| > Bit Capabilities >> | >| > >> | >| > 0-3 Reserved >> | >| > 4 IS-IS graceful restart capable [4] >> | >| > 5 IS-IS and BGP blackhole avoidance capable [6] >> | >| > 6 IS-IS wide metric processing capable [3] >> | >| > 7 IS-IS short metric processing capable [1] >> | >| > 8 IS-IS hmac-md5 authentication capable [5] >> | >| > 9 IS-IS Traffic Engineering support [3] >> | >| > 10 IS-IS point-to-point over LAN [7] >> | >| > 11 IS-IS Path Computation Server discovery [10] >> | >| > 12 M-ISIS capable [8] >> | >| > 13 IS-IS IPv6 capable [9] >> | >| > 14-31 For future assignments >> > >_______________________________________________ >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 Wed Jul 2 15:49:07 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 PAA09569 for ; Wed, 2 Jul 2003 15:49:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnaD-0007Nw-K8; Wed, 02 Jul 2003 15:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XnZv-0007My-Sx for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 15:47: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 PAA09427 for ; Wed, 2 Jul 2003 15:47:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XnZs-0006Pa-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 15:47:40 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19XnZs-0006P8-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 15:47:40 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h62Jl7pp027768; Wed, 2 Jul 2003 12:47:07 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-147.cisco.com [128.107.163.147]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHR16587; Wed, 2 Jul 2003 12:39:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20030702115635.019a1090@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: stefano previdi From: Les Ginsberg Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt Cc: Hannes Gredler , Jeff Learman , Naiming Shen , prz@xebeo.com, isis-wg@ietf.org In-Reply-To: <200307020613.h626Dgp13823@strange-brew.cisco.com> References: <20030702060754.GA30173@juniper.net> <4.3.2.7.2.20030701151937.0203bee0@dingdong.cisco.com> <4.3.2.7.2.20030702013832.0207dd00@dingdong.cisco.com> <20030702060754.GA30173@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 02 Jul 2003 12:47:06 -0700 At 08:13 AM 7/2/2003 +0200, stefano previdi wrote: >On Wednesday 02 July 2003 08:07, Hannes Gredler wrote: > > On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote: > > | > > | I think we want to know what a router IS DOING. We should > > | rely on product documentation to find out what it is capable of > > | being configured to do and how to do so. Or is this the "marketing > > | protocol" ;) > > > > well if this would be the "marketing proto" then we would need probably > > to dedicate a few fragments ... > > > > wrt what the router IS doing ? - i still got no answer > > to my original question: > > > > what information does the capability vector as-is provide that cannot > > be gathered from the TLV list of the LSP? [beside link-local > > things like ptp-IIH over LANs, graceful restart etc.] > >I agree. Note that the capabilities draft has been originally >written for propagating Traffic Engineering capabilities that >couldn't be inferred from the existance (or absence) of TE >sub TLV. The first capability defined was the PCS (Path >Computation Server) which tells that the box is capable to >compute path across area/domain boundaries (or something >similar to that, sorry I'm not a TE expert). > >Then, for reasnos I don't know, we added other capabilities >bits&flags but not sure it makes a lot of sense. > >s. I also agree with Hannes/Stefano. Where the capabilities are clearly visible from TLVs sent by the originating system, putting a bit for them in the capabilities flag field simply raises the bizarre possibility that a system could advertise that it supports something but not send the matching TLVs. Which one do you believe? Who needs this problem? So, if we look at the current proposed list: 0-3 Reserved For what (BTW)??? 4 IS-IS graceful restart capable [4] Not needed. Restart TLV must always be included in IIHs if the capability is supported 5 IS-IS and BGP blackhole avoidance capable [6] OK 6 IS-IS wide metric processing capable [3] 7 IS-IS short metric processing capable [1] For these two, the capability is not needed since you can deduce that from the TLVs present, but you cannot always know what metrics are currently being used in the SPF. For example, the transition strategy suggested in draft-ietf-isis-ip-interoperable (Section 8.1) defines periods where a TLV may be sent but not used in the SPF. So these could more usefully be defined to indicate what is currently being used in the local system's SPF. Given that the capabilities TLV is meant to be leaked into other levels, this creates a problem in that the usage can differ for the same router at Level 1 and Level 2. I suppose this could be solved by adding two more bits and making the bits level specific. 8 IS-IS hmac-md5 authentication capable [5] Not needed. 9 IS-IS Traffic Engineering support [3] Not needed. 10 IS-IS point-to-point over LAN [7] ??? Maybe this is useful...but if one side supports this and another doesn't the adjacency won't come up. I don't think this is very hard to debug on any system with useful event logging, but maybe... 11 IS-IS Path Computation Server discovery [10] OK 12 M-ISIS capable [8] Not needed. 13 IS-IS IPv6 capable [9] Not needed. Some other comments: 1)The use of "router-id" to identify the source of this TLV may be OK - but it is a bit problematic as has been pointed by Nagi. It is conceivable that an implementation may support this draft but NOT support TE, in which case it might not have a Router ID. (Unlikely but conceivable.) More relevant to me is the fact that in other aspects of the protocol the source information is always identified by the systemID - here we seem to break that rule. But if we were to use systemID, we must be careful as well, because the fact that this TLV is to be leaked places additional requirements on the systemID i.e. that it be unique throughout the domain, which is a stronger requirement than ISO 10589 imposes. As a practical matter this may not be a significant issue, but would need to be explicitly stated. 2)Requiring the length field in a sub-TLV to be set to a multiple of 4 seems very non-IS-IS-like. 3)Requiring the capability flag sub-TLV (code 1) to be present in each instance of this TLV seems like a bad idea. From what I have seen of proposals for use of sub-TLVs of this TLV, it seems quite likely that a system will have to send multiple TLVs to advertise all of the sub-TLV information. There seems no need to repeat the capabilities flag sub-TLV each time. 4)Why do we need 29 bits of "Reserved Information Flag"?? This seems like an attempt to 32 bit align the contents of the TLV - which is futile. Les > > > > > > --- > > also there may be some need to spend more bits as some of the features > > being listed in the draft may have a asymmetric nature; i.e. > > a router does not actively send a certain TLV but may be capable > > of processing this TLV on receipt; ... sort/wide metric and the > > completetely wild [i.e. very vendor has its own] transition methods > > are a good example; > > > > > > /hannes > > > > | Jeff > > | > > | At 01:30 AM 7/2/2003, Hannes Gredler wrote: > > | >jeff, > > | > > > | >changed subject - > > | > > > | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: > > | >| > > | >| Presumably it's functions that are enabled. A protocol doesn't > > | >| need to say what a router could do if configured differently, > > | >| just what it's prepared and able to do right now. > > | > > > | >hmmm don't agree - that brings us back to the question what > > | >is the objective of the draft ? i read between the lines that > > | >it was intended as quick view what the IS-IS SW can do and whats > > | >enabled; > > | > > > | >the network administrator should have the choice to > > | > > > | > a. upgrade the software or > > | > b. turn feature X on > > | > > > | >for doing that IMHO you need two subTLVs/bitvectors > > | > > > | > 1. one displaying the SW capabilities > > | > 2. one displaying whats actually configured > > | > > > | >i agree that 2. is largely redundant becasue one can > > | >look at the TLV list of a specific node to see what > > | >is turned on; > > | > > > | >or in other words: what information does the > > | >capability vector as-is provide that cannot > > | >be gathered from the TLV list ? [beside link-local > > | >things like ptp-IIH over LANs, graceful restart etc.] > > | > > > | >/hannes > > | > > > | >| I suppose that could be made clear in the text. > > | >| > > | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: > > | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: > > | >| >| folks, > > | >| >| > > | >| >| this draft is the isis part of the IGP capability, please review > > | >| >| and comment, thanks. > > | >| >| > > | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.txt > > | >| > > > | >| >naiming, > > | >| > > > | >| >when you talk about capabilities in the draft what is really meant ? > > | >| > actual capabilities or potential capabilies ? > > | >| > > > | >| > when does a router has to set a bit ? - e.g. if capability X has > > | >| > been configured or there is in general support for capability X > > | >| > in the current loaded SW; > > | >| > > > | >| >/hannes > > | >| > > > | >| >--- > > | >| > > > | >| >4.3 Reserved IS-IS Router Capability Bits > > | >| > > > | >| > We have assigned some pre-determined bits to the first capability > > | >| > flag. > > | >| > > > | >| > Bit Capabilities > > | >| > > > | >| > 0-3 Reserved > > | >| > 4 IS-IS graceful restart capable [4] > > | >| > 5 IS-IS and BGP blackhole avoidance capable [6] > > | >| > 6 IS-IS wide metric processing capable [3] > > | >| > 7 IS-IS short metric processing capable [1] > > | >| > 8 IS-IS hmac-md5 authentication capable [5] > > | >| > 9 IS-IS Traffic Engineering support [3] > > | >| > 10 IS-IS point-to-point over LAN [7] > > | >| > 11 IS-IS Path Computation Server discovery [10] > > | >| > 12 M-ISIS capable [8] > > | >| > 13 IS-IS IPv6 capable [9] > > | >| > 14-31 For future assignments > > > >_______________________________________________ >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 Wed Jul 2 16:00:37 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 QAA10277 for ; Wed, 2 Jul 2003 16:00:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xnlp-0008Av-O4; Wed, 02 Jul 2003 16:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xnl4-00088r-Iq for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 15:59:14 -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 PAA10189 for ; Wed, 2 Jul 2003 15:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xnl1-0006e7-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 15:59:11 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19Xnkz-0006di-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 15:59:10 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , stefano previdi Cc: Hannes Gredler , Jeff Learman , Naiming Shen , prz@xebeo.com, isis-wg@ietf.org Subject: RE: [Isis-wg] draft-raggarwa-isis-cap-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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, 2 Jul 2003 15:58:08 -0400 > 4 IS-IS graceful restart capable [4] > > Not needed. Restart TLV must always be included in IIHs if > the capability is supported But the LSP has a network-wide scope, so anyone can see, even if they are not on the link. > 6 IS-IS wide metric processing capable [3] > 7 IS-IS short metric processing capable [1] > > For these two, the capability is not needed since you can > deduce that from the TLVs present I think this gets back to what these mean: I am sending these I could send these, if I wanted to I would know what to do if you sent them If think the bit means the last two, not the first, this would be helpful > 8 IS-IS hmac-md5 authentication capable [5] > > Not needed. This falls under both points above Could be using in IIH, wouldn't be seen off-link I might be able to use it, even if I'm not sending > 10 IS-IS point-to-point over LAN [7] > > ??? Maybe this is useful...but if one side supports this and another > doesn't the adjacency won't come up. I don't think this is > very hard to > debug on any system with useful event logging, but maybe... I agree that this is going to come down to looking at logs, but this is another place where remote inspection of TLVs might clue you in to an incompatibility. - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 18:27:51 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 SAA26590 for ; Wed, 2 Jul 2003 18:27:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xq45-0001gM-LB; Wed, 02 Jul 2003 18:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xq3H-0001fq-Go for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 18:26:11 -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 SAA26456 for ; Wed, 2 Jul 2003 18:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xq3C-0003Ti-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 18:26:06 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19Xq3B-0003Te-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 18:26:05 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 61A278FE6C3; Wed, 2 Jul 2003 15:26:02 -0700 (PDT) To: Les Ginsberg Cc: stefano previdi , Hannes Gredler , jparker@axiowave.com, Jeff Learman , prz@xebeo.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt In-reply-to: Mail from Les Ginsberg dated Wed, 02 Jul 2003 12:47:06 PDT <4.3.2.7.2.20030702115635.019a1090@mira-sjc5-3.cisco.com> From: Naiming Shen Message-Id: <20030702222602.61A278FE6C3@prattle.redback.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, 02 Jul 2003 15:26:02 -0700 Les, Stefano, Hannes and Jeffs, thanks for the good comments, a couple of things I want to mention about this capability TLV. - this TLV can be "flooded" over the entire IGP domain, not exactly like LSPs which is only confined in area/level. - one of the purposes of this TLV is for network troubleshooting, so even if there are ways to exmain the entire fragments of LSPs from one particular router to find answer, it still helps to list all of them in a well-known place and a show command can list them all together. I think this will be easier than to find a way to dump raw ISIS packets and search for one particular feature. - the capabilities of this TLV can be group into 3 categories, (1) for protocol functionality, such as the Path computation application for example; (2) for software to detect misconfig or mismatch automatically, for example, short/wide capability bits. We can specify here(not yet) if one supports short-only, short-and-wide or wide-only mode, we can announce them with those two bits. If any router in the area detect a mismatch(i only run wide-only, and someone in the area runs short-only), it can spit out a warning message. NOTICE, this is not for protocol use, protocol can still run as is, but it gives us a powerful auto-checking mechanism to detect errors during transtion. This may not just be short/wide application, other transitions later on, for example, diff IPv6 schemes which requires area wide coordination, we could use that; (3) informational. this is only for operators troubleshooting, rathar than ask them to have tcpdump on ISIS packets and search for TLVs, it allows a router to announce them explicitly in a well-known TLV(not to mention for non-LSP related things). Most of the routers now have a way to display system-id vs hostname using dynamic-hostname TLV, similarly they can later on have a command to display the router-id, with a list of capabilities. Certain things like IPv6 capability, it will be nice to know this router is capable of running IPv6 in the current version of software, but (maybe due to misconfig or something) none of the interfaces is configured with IPv6, then even you dump the packets, there is no indication of "IPv6 capability" of the router. - I do agree with most of you that, in the current draft, the meaning of each capability is unclear. We need to list each one of them(if they are needed) to define exactly the meaning of them, and how do people use them, the short/wide bit is a good example. People should comment on those and we'll include them in the next version. some comments inline, ] At 08:13 AM 7/2/2003 +0200, stefano previdi wrote: ] >On Wednesday 02 July 2003 08:07, Hannes Gredler wrote: ] > > On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote: ] > > | ] > > | I think we want to know what a router IS DOING. We should ] > > | rely on product documentation to find out what it is capable of ] > > | being configured to do and how to do so. Or is this the "marketing ] > > | protocol" ;) ] > > ] > > well if this would be the "marketing proto" then we would need probably ] > > to dedicate a few fragments ... ] > > ] > > wrt what the router IS doing ? - i still got no answer ] > > to my original question: ] > > ] > > what information does the capability vector as-is provide that cannot ] > > be gathered from the TLV list of the LSP? [beside link-local ] > > things like ptp-IIH over LANs, graceful restart etc.] ] > ] >I agree. Note that the capabilities draft has been originally ] >written for propagating Traffic Engineering capabilities that ] >couldn't be inferred from the existance (or absence) of TE ] >sub TLV. The first capability defined was the PCS (Path ] >Computation Server) which tells that the box is capable to ] >compute path across area/domain boundaries (or something ] >similar to that, sorry I'm not a TE expert). ] > ] >Then, for reasnos I don't know, we added other capabilities ] >bits&flags but not sure it makes a lot of sense. ] > ] >s. ] ] ] I also agree with Hannes/Stefano. Where the capabilities are clearly ] visible from TLVs sent by the originating system, putting a bit for them in ] the capabilities flag field simply raises the bizarre possibility that a ] system could advertise that it supports something but not send the matching ] TLVs. Which one do you believe? Who needs this problem? see above. ] ] So, if we look at the current proposed list: ] ] 0-3 Reserved ] ] For what (BTW)??? ] ] 4 IS-IS graceful restart capable [4] ] ] Not needed. Restart TLV must always be included in IIHs if the capability ] is supported ] ] 5 IS-IS and BGP blackhole avoidance capable [6] ] ] OK ] ] 6 IS-IS wide metric processing capable [3] ] 7 IS-IS short metric processing capable [1] ] ] For these two, the capability is not needed since you can deduce that from ] the TLVs present, but you cannot always know what metrics are currently ] being used in the SPF. For example, the transition strategy suggested in ] draft-ietf-isis-ip-interoperable (Section 8.1) defines periods where a TLV ] may be sent but not used in the SPF. So these could more usefully be ] defined to indicate what is currently being used in the local system's SPF. ] Given that the capabilities TLV is meant to be leaked into other levels, ] this creates a problem in that the usage can differ for the same router at ] Level 1 and Level 2. I suppose this could be solved by adding two more bits ] and making the bits level specific. ] ] 8 IS-IS hmac-md5 authentication capable [5] ] ] Not needed. ] ] 9 IS-IS Traffic Engineering support [3] ] ] Not needed. ] ] 10 IS-IS point-to-point over LAN [7] ] ] ??? Maybe this is useful...but if one side supports this and another ] doesn't the adjacency won't come up. I don't think this is very hard to ] debug on any system with useful event logging, but maybe... ] ] 11 IS-IS Path Computation Server discovery [10] ] ] OK ] ] 12 M-ISIS capable [8] ] ] Not needed. ] ] 13 IS-IS IPv6 capable [9] ] ] Not needed. we can discuss this and include more info on each bit, see above. ] ] ] Some other comments: ] ] 1)The use of "router-id" to identify the source of this TLV may be OK - but ] it is a bit problematic as has been pointed by Nagi. It is conceivable that ] an implementation may support this draft but NOT support TE, in which case ] it might not have a Router ID. (Unlikely but conceivable.) More relevant to ] me is the fact that in other aspects of the protocol the source information ] is always identified by the systemID - here we seem to break that rule. But ] if we were to use systemID, we must be careful as well, because the fact ] that this TLV is to be leaked places additional requirements on the ] systemID i.e. that it be unique throughout the domain, which is a stronger ] requirement than ISO 10589 imposes. As a practical matter this may not be a ] significant issue, but would need to be explicitly stated. Usually when a ISP running ISIS in the domain, they don't use the same IP address for their router-id/loopback0-address. It's a good idea anyway to define an unique IP address for each router in the domain. Even if the systemID is used instead of router-id, as you mentioned, this systemID does not need to be unique in the domain, and this TLV can be "flooded" over the entire domain, so what will be the result? the later one always overwrites the previous one even they are from different sources? So use router-id and require they be unique(from operation point of view) is important. ] ] 2)Requiring the length field in a sub-TLV to be set to a multiple of 4 ] seems very non-IS-IS-like. Only the capability flag sub-TLV, not the other sub-TLVs. But this is a minor issue, I don't have strong opinion on this. ] ] 3)Requiring the capability flag sub-TLV (code 1) to be present in each ] instance of this TLV seems like a bad idea. From what I have seen of ] proposals for use of sub-TLVs of this TLV, it seems quite likely that a ] system will have to send multiple TLVs to advertise all of the sub-TLV ] information. There seems no need to repeat the capabilities flag sub-TLV ] each time. each router suppose to advertise one TLV, but in the level boundary, a router can advertise one for itself and many for other. Still it needs to have this capability flag for each one of them. ] ] 4)Why do we need 29 bits of "Reserved Information Flag"?? This seems like ] an attempt to 32 bit align the contents of the TLV - which is futile. True, we can change this to one, two or three bytes instead, just to avoid the suspicion of OSPF blood contamination:-) thanks. ] ] Les ] ] ] > > ] > > ] > > --- ] > > also there may be some need to spend more bits as some of the features ] > > being listed in the draft may have a asymmetric nature; i.e. ] > > a router does not actively send a certain TLV but may be capable ] > > of processing this TLV on receipt; ... sort/wide metric and the ] > > completetely wild [i.e. very vendor has its own] transition methods ] > > are a good example; ] > > ] > > ] > > /hannes ] > > ] > > | Jeff ] > > | ] > > | At 01:30 AM 7/2/2003, Hannes Gredler wrote: ] > > | >jeff, ] > > | > ] > > | >changed subject - ] > > | > ] > > | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: ] > > | >| ] > > | >| Presumably it's functions that are enabled. A protocol doesn't ] > > | >| need to say what a router could do if configured differently, ] > > | >| just what it's prepared and able to do right now. ] > > | > ] > > | >hmmm don't agree - that brings us back to the question what ] > > | >is the objective of the draft ? i read between the lines that ] > > | >it was intended as quick view what the IS-IS SW can do and whats ] > > | >enabled; ] > > | > ] > > | >the network administrator should have the choice to ] > > | > ] > > | > a. upgrade the software or ] > > | > b. turn feature X on ] > > | > ] > > | >for doing that IMHO you need two subTLVs/bitvectors ] > > | > ] > > | > 1. one displaying the SW capabilities ] > > | > 2. one displaying whats actually configured ] > > | > ] > > | >i agree that 2. is largely redundant becasue one can ] > > | >look at the TLV list of a specific node to see what ] > > | >is turned on; ] > > | > ] > > | >or in other words: what information does the ] > > | >capability vector as-is provide that cannot ] > > | >be gathered from the TLV list ? [beside link-local ] > > | >things like ptp-IIH over LANs, graceful restart etc.] ] > > | > ] > > | >/hannes ] > > | > ] > > | >| I suppose that could be made clear in the text. ] > > | >| ] > > | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: ] > > | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: ] > > | >| >| folks, ] > > | >| >| ] > > | >| >| this draft is the isis part of the IGP capability, please review ] > > | >| >| and comment, thanks. ] > > | >| >| ] > > | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.t xt ] > > | >| > ] > > | >| >naiming, ] > > | >| > ] > > | >| >when you talk about capabilities in the draft what is really meant ? ] > > | >| > actual capabilities or potential capabilies ? ] > > | >| > ] > > | >| > when does a router has to set a bit ? - e.g. if capability X has ] > > | >| > been configured or there is in general support for capability X ] > > | >| > in the current loaded SW; ] > > | >| > ] > > | >| >/hannes ] > > | >| > ] > > | >| >--- ] > > | >| > ] > > | >| >4.3 Reserved IS-IS Router Capability Bits ] > > | >| > ] > > | >| > We have assigned some pre-determined bits to the first capabili ty ] > > | >| > flag. ] > > | >| > ] > > | >| > Bit Capabilities ] > > | >| > ] > > | >| > 0-3 Reserved ] > > | >| > 4 IS-IS graceful restart capable [4] ] > > | >| > 5 IS-IS and BGP blackhole avoidance capable [6] ] > > | >| > 6 IS-IS wide metric processing capable [3] ] > > | >| > 7 IS-IS short metric processing capable [1] ] > > | >| > 8 IS-IS hmac-md5 authentication capable [5] ] > > | >| > 9 IS-IS Traffic Engineering support [3] ] > > | >| > 10 IS-IS point-to-point over LAN [7] ] > > | >| > 11 IS-IS Path Computation Server discovery [10] ] > > | >| > 12 M-ISIS capable [8] ] > > | >| > 13 IS-IS IPv6 capable [9] ] > > | >| > 14-31 For future assignments ] > > ] > ] >_______________________________________________ ] >Isis-wg mailing list ] >Isis-wg@ietf.org ] >https://www1.ietf.org/mailman/listinfo/isis-wg ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 2 20:28:52 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 UAA05687 for ; Wed, 2 Jul 2003 20:28:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrxA-0005ld-OE; Wed, 02 Jul 2003 20:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XrwX-0005ik-OW for isis-wg@optimus.ietf.org; Wed, 02 Jul 2003 20:27:21 -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 UAA05437 for ; Wed, 2 Jul 2003 20:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XrwV-00074X-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 20:27:19 -0400 Received: from firestar.cisco.com ([171.68.227.75] helo=fire.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19XrwU-00073E-00 for isis-wg@ietf.org; Wed, 02 Jul 2003 20:27:18 -0400 Received: from sj-cse-138.cisco.com (sj-cse-138.cisco.com [171.69.98.126]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h630I7T09656; Wed, 2 Jul 2003 17:18:07 -0700 (PDT) From: Shankar Vemulapalli To: Naiming Shen cc: Les Ginsberg , stefano previdi , Hannes Gredler , jparker@axiowave.com, Jeff Learman , prz@xebeo.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-raggarwa-isis-cap-00.txt In-Reply-To: <20030702222602.61A278FE6C3@prattle.redback.com> Message-ID: References: <20030702222602.61A278FE6C3@prattle.redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 2 Jul 2003 17:18:06 -0700 (PDT) Hi Naiming - Some ideas/thoughts - a] Since most of the TLVs have a way to get identified to start with the information in the LSPs - may be we can include information in the Capability TLV for those which doesnt' have the TLVs - for. ex: ISIS & BGP Blackhole Avoidance. b] As you said below, may be increasing the size of the TLV to 2 or 3 bytes could be a better idea which may let include all the TLVs and c] It would be good idea to define the "scope" of the Capability TLV and also describe the reason why a TLV included vs not the other TLV in the draft. d] Or even specify which TLVs should be included as "Mandotory" vs the others. Thanks, /Shankar At 3:26pm 07/02/03 -0700, Naiming Shen wrote: > > > Les, Stefano, Hannes and Jeffs, > > > thanks for the good comments, a couple of things I want to mention > about this capability TLV. > > > - this TLV can be "flooded" over the entire IGP domain, not exactly > like LSPs which is only confined in area/level. > > - one of the purposes of this TLV is for network troubleshooting, so > even if there are ways to exmain the entire fragments of LSPs from > one particular router to find answer, it still helps to list > all of them in a well-known place and a show command can list them > all together. I think this will be easier than to find a way to > dump raw ISIS packets and search for one particular feature. > > - the capabilities of this TLV can be group into 3 categories, > (1) for protocol functionality, such as the Path computation > application for example; > (2) for software to detect misconfig or mismatch > automatically, for example, short/wide capability bits. We can > specify here(not yet) if one supports short-only, short-and-wide > or wide-only mode, we can announce them with those two bits. If > any router in the area detect a mismatch(i only run wide-only, > and someone in the area runs short-only), it can spit out a > warning message. NOTICE, this is not for protocol use, protocol > can still run as is, but it gives us a powerful auto-checking > mechanism to detect errors during transtion. This may not just > be short/wide application, other transitions later on, for example, > diff IPv6 schemes which requires area wide coordination, we could > use that; > (3) informational. this is only for operators troubleshooting, > rathar than ask them to have tcpdump on ISIS packets and > search for TLVs, it allows a router to announce them explicitly > in a well-known TLV(not to mention for non-LSP related things). > Most of the routers now have a way to display system-id vs hostname > using dynamic-hostname TLV, similarly they can > later on have a command to display the router-id, with a list of > capabilities. Certain things like IPv6 capability, it will be nice > to know this router is capable of running IPv6 in the current > version of software, but (maybe due to misconfig or something) none > of the interfaces is configured with IPv6, then even you dump the > packets, there is no indication of "IPv6 capability" of the router. > > - I do agree with most of you that, in the current draft, the meaning > of each capability is unclear. We need to list each one of them(if > they are needed) to define exactly the meaning of them, and how do > people use them, the short/wide bit is a good example. People should > comment on those and we'll include them in the next version. > > some comments inline, > > ] At 08:13 AM 7/2/2003 +0200, stefano previdi wrote: > ] >On Wednesday 02 July 2003 08:07, Hannes Gredler wrote: > ] > > On Wed, Jul 02, 2003 at 01:41:22AM -0400, Jeff Learman wrote: > ] > > | > ] > > | I think we want to know what a router IS DOING. We should > ] > > | rely on product documentation to find out what it is capable of > ] > > | being configured to do and how to do so. Or is this the "marketing > ] > > | protocol" ;) > ] > > > ] > > well if this would be the "marketing proto" then we would need probably > ] > > to dedicate a few fragments ... > ] > > > ] > > wrt what the router IS doing ? - i still got no answer > ] > > to my original question: > ] > > > ] > > what information does the capability vector as-is provide that cannot > ] > > be gathered from the TLV list of the LSP? [beside link-local > ] > > things like ptp-IIH over LANs, graceful restart etc.] > ] > > ] >I agree. Note that the capabilities draft has been originally > ] >written for propagating Traffic Engineering capabilities that > ] >couldn't be inferred from the existance (or absence) of TE > ] >sub TLV. The first capability defined was the PCS (Path > ] >Computation Server) which tells that the box is capable to > ] >compute path across area/domain boundaries (or something > ] >similar to that, sorry I'm not a TE expert). > ] > > ] >Then, for reasnos I don't know, we added other capabilities > ] >bits&flags but not sure it makes a lot of sense. > ] > > ] >s. > ] > ] > ] I also agree with Hannes/Stefano. Where the capabilities are clearly > ] visible from TLVs sent by the originating system, putting a bit for them in > ] the capabilities flag field simply raises the bizarre possibility that a > ] system could advertise that it supports something but not send the matching > ] TLVs. Which one do you believe? Who needs this problem? > > see above. > > ] > ] So, if we look at the current proposed list: > ] > ] 0-3 Reserved > ] > ] For what (BTW)??? > ] > ] 4 IS-IS graceful restart capable [4] > ] > ] Not needed. Restart TLV must always be included in IIHs if the capability > ] is supported > ] > ] 5 IS-IS and BGP blackhole avoidance capable [6] > ] > ] OK > ] > ] 6 IS-IS wide metric processing capable [3] > ] 7 IS-IS short metric processing capable [1] > ] > ] For these two, the capability is not needed since you can deduce that from > ] the TLVs present, but you cannot always know what metrics are currently > ] being used in the SPF. For example, the transition strategy suggested in > ] draft-ietf-isis-ip-interoperable (Section 8.1) defines periods where a TLV > ] may be sent but not used in the SPF. So these could more usefully be > ] defined to indicate what is currently being used in the local system's SPF. > ] Given that the capabilities TLV is meant to be leaked into other levels, > ] this creates a problem in that the usage can differ for the same router at > ] Level 1 and Level 2. I suppose this could be solved by adding two more bits > ] and making the bits level specific. > ] > ] 8 IS-IS hmac-md5 authentication capable [5] > ] > ] Not needed. > ] > ] 9 IS-IS Traffic Engineering support [3] > ] > ] Not needed. > ] > ] 10 IS-IS point-to-point over LAN [7] > ] > ] ??? Maybe this is useful...but if one side supports this and another > ] doesn't the adjacency won't come up. I don't think this is very hard to > ] debug on any system with useful event logging, but maybe... > ] > ] 11 IS-IS Path Computation Server discovery [10] > ] > ] OK > ] > ] 12 M-ISIS capable [8] > ] > ] Not needed. > ] > ] 13 IS-IS IPv6 capable [9] > ] > ] Not needed. > > we can discuss this and include more info on each bit, see above. > > ] > ] > ] Some other comments: > ] > ] 1)The use of "router-id" to identify the source of this TLV may be OK - but > ] it is a bit problematic as has been pointed by Nagi. It is conceivable that > ] an implementation may support this draft but NOT support TE, in which case > ] it might not have a Router ID. (Unlikely but conceivable.) More relevant to > ] me is the fact that in other aspects of the protocol the source information > ] is always identified by the systemID - here we seem to break that rule. But > ] if we were to use systemID, we must be careful as well, because the fact > ] that this TLV is to be leaked places additional requirements on the > ] systemID i.e. that it be unique throughout the domain, which is a stronger > ] requirement than ISO 10589 imposes. As a practical matter this may not be a > ] significant issue, but would need to be explicitly stated. > > Usually when a ISP running ISIS in the domain, they don't use the same > IP address for their router-id/loopback0-address. It's a good idea anyway > to define an unique IP address for each router in the domain. Even if > the systemID is used instead of router-id, as you mentioned, this systemID > does not need to be unique in the domain, and this TLV can be "flooded" > over the entire domain, so what will be the result? the later one always > overwrites the previous one even they are from different sources? So use > router-id and require they be unique(from operation point of view) is > important. > > ] > ] 2)Requiring the length field in a sub-TLV to be set to a multiple of 4 > ] seems very non-IS-IS-like. > > Only the capability flag sub-TLV, not the other sub-TLVs. But this is > a minor issue, I don't have strong opinion on this. > > ] > ] 3)Requiring the capability flag sub-TLV (code 1) to be present in each > ] instance of this TLV seems like a bad idea. From what I have seen of > ] proposals for use of sub-TLVs of this TLV, it seems quite likely that a > ] system will have to send multiple TLVs to advertise all of the sub-TLV > ] information. There seems no need to repeat the capabilities flag sub-TLV > ] each time. > > each router suppose to advertise one TLV, but in the level boundary, a > router can advertise one for itself and many for other. Still it needs > to have this capability flag for each one of them. > > ] > ] 4)Why do we need 29 bits of "Reserved Information Flag"?? This seems like > ] an attempt to 32 bit align the contents of the TLV - which is futile. > > True, we can change this to one, two or three bytes instead, just to > avoid the suspicion of OSPF blood contamination:-) > > thanks. > > ] > ] Les > ] > ] > ] > > > ] > > > ] > > --- > ] > > also there may be some need to spend more bits as some of the features > ] > > being listed in the draft may have a asymmetric nature; i.e. > ] > > a router does not actively send a certain TLV but may be capable > ] > > of processing this TLV on receipt; ... sort/wide metric and the > ] > > completetely wild [i.e. very vendor has its own] transition methods > ] > > are a good example; > ] > > > ] > > > ] > > /hannes > ] > > > ] > > | Jeff > ] > > | > ] > > | At 01:30 AM 7/2/2003, Hannes Gredler wrote: > ] > > | >jeff, > ] > > | > > ] > > | >changed subject - > ] > > | > > ] > > | >On Tue, Jul 01, 2003 at 03:21:10PM -0400, Jeff Learman wrote: > ] > > | >| > ] > > | >| Presumably it's functions that are enabled. A protocol doesn't > ] > > | >| need to say what a router could do if configured differently, > ] > > | >| just what it's prepared and able to do right now. > ] > > | > > ] > > | >hmmm don't agree - that brings us back to the question what > ] > > | >is the objective of the draft ? i read between the lines that > ] > > | >it was intended as quick view what the IS-IS SW can do and whats > ] > > | >enabled; > ] > > | > > ] > > | >the network administrator should have the choice to > ] > > | > > ] > > | > a. upgrade the software or > ] > > | > b. turn feature X on > ] > > | > > ] > > | >for doing that IMHO you need two subTLVs/bitvectors > ] > > | > > ] > > | > 1. one displaying the SW capabilities > ] > > | > 2. one displaying whats actually configured > ] > > | > > ] > > | >i agree that 2. is largely redundant becasue one can > ] > > | >look at the TLV list of a specific node to see what > ] > > | >is turned on; > ] > > | > > ] > > | >or in other words: what information does the > ] > > | >capability vector as-is provide that cannot > ] > > | >be gathered from the TLV list ? [beside link-local > ] > > | >things like ptp-IIH over LANs, graceful restart etc.] > ] > > | > > ] > > | >/hannes > ] > > | > > ] > > | >| I suppose that could be made clear in the text. > ] > > | >| > ] > > | >| At 02:00 PM 7/1/2003, Hannes Gredler wrote: > ] > > | >| >On Mon, Jun 30, 2003 at 10:17:55AM -0700, Naiming Shen wrote: > ] > > | >| >| folks, > ] > > | >| >| > ] > > | >| >| this draft is the isis part of the IGP capability, please review > ] > > | >| >| and comment, thanks. > ] > > | >| >| > ] > > | >| >| http://www.ietf.org/internet-drafts/draft-raggarwa-isis-cap-00.t > xt > ] > > | >| > > ] > > | >| >naiming, > ] > > | >| > > ] > > | >| >when you talk about capabilities in the draft what is really meant > ? > ] > > | >| > actual capabilities or potential capabilies ? > ] > > | >| > > ] > > | >| > when does a router has to set a bit ? - e.g. if capability X has > ] > > | >| > been configured or there is in general support for capability X > ] > > | >| > in the current loaded SW; > ] > > | >| > > ] > > | >| >/hannes > ] > > | >| > > ] > > | >| >--- > ] > > | >| > > ] > > | >| >4.3 Reserved IS-IS Router Capability Bits > ] > > | >| > > ] > > | >| > We have assigned some pre-determined bits to the first capabili > ty > ] > > | >| > flag. > ] > > | >| > > ] > > | >| > Bit Capabilities > ] > > | >| > > ] > > | >| > 0-3 Reserved > ] > > | >| > 4 IS-IS graceful restart capable [4] > ] > > | >| > 5 IS-IS and BGP blackhole avoidance capable [6] > ] > > | >| > 6 IS-IS wide metric processing capable [3] > ] > > | >| > 7 IS-IS short metric processing capable [1] > ] > > | >| > 8 IS-IS hmac-md5 authentication capable [5] > ] > > | >| > 9 IS-IS Traffic Engineering support [3] > ] > > | >| > 10 IS-IS point-to-point over LAN [7] > ] > > | >| > 11 IS-IS Path Computation Server discovery [10] > ] > > | >| > 12 M-ISIS capable [8] > ] > > | >| > 13 IS-IS IPv6 capable [9] > ] > > | >| > 14-31 For future assignments > ] > > > ] > > ] >_______________________________________________ > ] >Isis-wg mailing list > ] >Isis-wg@ietf.org > ] >https://www1.ietf.org/mailman/listinfo/isis-wg > ] > > - Naiming > > _______________________________________________ > 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 Wed Jul 9 13:56:04 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 NAA12100 for ; Wed, 9 Jul 2003 13:56:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJ9g-0008Hg-NY; Wed, 09 Jul 2003 13:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJ8n-0008Fu-Od for isis-wg@optimus.ietf.org; Wed, 09 Jul 2003 13:54:05 -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 NAA12031 for ; Wed, 9 Jul 2003 13:54:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJ8k-0001HY-00 for isis-wg@ietf.org; Wed, 09 Jul 2003 13:54:02 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19aJ8j-0001H2-00 for isis-wg@ietf.org; Wed, 09 Jul 2003 13:54:02 -0400 Message-ID: From: Jeff Parker To: "'Les Ginsberg'" , "'mshand@cisco.com'" Cc: "ISIS-WG (E-mail)" Subject: [Isis-wg] draft-ietf-isis-restart-03.txt - RA and CSNP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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, 9 Jul 2003 13:53:14 -0400 Mike & Les - Wondering about the interaction between the RA Hello and CSNPs on LAN I'm looking at draft-ietf-isis-restart-03.txt, page 4, section 4.3.1. You suggest that an assisting IS first send an RA hello, and then decide if it should send CSNPs. What is the purpose of the RA without CSNPs? Is this to deal with the possibility that the assisting IS makes the wrong decision, and does not send the CSNPs when everyone else thinks it should? Or, to look at it from the other side: Must the restarting IS wait for a CSNP set from a peer who sends an RA, or will any full set of CSNPs do? - jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 9 15:32:49 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 PAA17180 for ; Wed, 9 Jul 2003 15:32:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKfZ-00067x-Jm; Wed, 09 Jul 2003 15:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aKen-00067T-PS for isis-wg@optimus.ietf.org; Wed, 09 Jul 2003 15:31: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 PAA17129 for ; Wed, 9 Jul 2003 15:31:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aKem-0002ID-00 for isis-wg@ietf.org; Wed, 09 Jul 2003 15:31:12 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aKel-0002Hx-00 for isis-wg@ietf.org; Wed, 09 Jul 2003 15:31:11 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 09 Jul 2003 12:28:35 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h69JUdrm025897; Wed, 9 Jul 2003 12:30:39 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-155.cisco.com [128.107.163.155]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHV62503; Wed, 9 Jul 2003 12:20:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20030709121858.018fecd0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jeff Parker From: Les Ginsberg Subject: Re: [Isis-wg] draft-ietf-isis-restart-03.txt - RA and CSNP Cc: "'mshand@cisco.com'" , "ISIS-WG (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 09 Jul 2003 12:30:38 -0700 At 01:53 PM 7/9/2003 -0400, Jeff Parker wrote: >Mike & Les - > Wondering about the interaction between the RA Hello and CSNPs on >LAN > I'm looking at draft-ietf-isis-restart-03.txt, page 4, section >4.3.1. > > You suggest that an assisting IS first send an RA hello, and then >decide if it should send CSNPs. What is the purpose of the RA without >CSNPs? Is this to deal with the possibility that the assisting IS makes the >wrong decision, and does not send the CSNPs when everyone else thinks it >should? The purpose of the RA is independent of whether the sender will also send CSNPs or not. Receipt of an IIH/RA by the restarting router is used to determine - based on the remaining hold time - how long before the adjacency will go down. This is used to adjust the upper bound for T3 - which determines when we would begin to flood our own LSPs w OL bit set. Section 4.4.1.1 says on page 11: "If the timer T3 expires before all the T2 timers have expired or been cancelled, this indicates that the synchronization process is taking longer than minimum holding time of the neighbors. The router's own LSP(s) for levels which have not yet completed their first SPF computation are then flooded with the overload bit set to indicate that the router's LSPDB is not yet synchronized (and other routers should therefore not compute routes through this router). Normal operation of the update process resumes and the local forwarding tables are updated." >Or, to look at it from the other side: > Must the restarting IS wait for a CSNP set from a peer who sends an >RA, or will any full set of CSNPs do? This is an interesting point. Receipt of a full set of CSNPs is on a per interface basis. Clearly a set of CSNPs must come from a single source - and they should NOT come from a router which is itself restarting since that router does not yet have a full set of LSPs. Of the set of candidates on the LAN, it does not really matter which of the eligible routers sends the CSNPs - though we expect that the algorithm defined in 4.2.1c will result in only one router on the LAN sending CSNPs. Version 4 of the draft will have some language clarifying this point. Inasmuch as we missed the deadline for draft submission, the new version will become available shortly after the upcoming meeting. Les >- jeff parker _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jul 10 04:36:55 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 EAA22604 for ; Thu, 10 Jul 2003 04: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 19aWuJ-0002pA-BN; Thu, 10 Jul 2003 04:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aWu8-0002of-Eg for isis-wg@optimus.ietf.org; Thu, 10 Jul 2003 04:35:52 -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 EAA22531 for ; Thu, 10 Jul 2003 04:35:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aWu5-0000aF-00 for isis-wg@ietf.org; Thu, 10 Jul 2003 04:35:49 -0400 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19aWu4-0000a1-00 for isis-wg@ietf.org; Thu, 10 Jul 2003 04:35:49 -0400 Received: (qmail 17639 invoked from network); 10 Jul 2003 08:35:17 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.102) by lxmail.nj.us.utstar.com with SMTP; 10 Jul 2003 08:35:17 -0000 Message-ID: <3F0D24D5.4080206@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: isis-wg@ietf.org X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Vienna agenda 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, 10 Jul 2003 10:33:25 +0200 Content-Transfer-Encoding: 7bit Draft Status 5 mins Tony ISIS Capabilites 15 mins Rahul, Naiming ? --- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jul 17 19:17:57 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 TAA26583 for ; Thu, 17 Jul 2003 19:17:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHzg-0004Yw-Dz; Thu, 17 Jul 2003 19:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dHzZ-0004Yl-Ia for isis-wg@optimus.ietf.org; Thu, 17 Jul 2003 19:16: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 TAA26537; Thu, 17 Jul 2003 19:16:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dHzX-0002Di-00; Thu, 17 Jul 2003 19:16:51 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19dHzM-0002DQ-00; Thu, 17 Jul 2003 19:16:40 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h6HNFnJ23072; Thu, 17 Jul 2003 16:15:49 -0700 (PDT) Message-Id: <200307172315.h6HNFnJ23072@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, isis-wg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Subject: [Isis-wg] RFC 3567 on Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication 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, 17 Jul 2003 16:15:49 -0700 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3567 Title: Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication Author(s): T. Li, R. Atkinson Status: Informational Date: July 2003 Mailbox: tli@procket.net, rja@extremenetworks.com Pages: 6 Characters: 13467 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-isis-hmac-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3567.txt This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. This document is a product of IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030717160930.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3567 --OtherAccess Content-Type: Message/External-body; name="rfc3567.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030717160930.RFC@RFC-EDITOR.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 Sat Jul 19 17:11: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 RAA22781 for ; Sat, 19 Jul 2003 17:11: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 19dyyr-0002eQ-NO; Sat, 19 Jul 2003 17:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dmDh-0007A3-7T for isis-wg@optimus.ietf.org; Sat, 19 Jul 2003 03:33:29 -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 DAA07914 for ; Sat, 19 Jul 2003 03:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dmDe-0007Sq-00 for isis-wg@ietf.org; Sat, 19 Jul 2003 03:33:26 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19dmDT-0007SS-00 for isis-wg@ietf.org; Sat, 19 Jul 2003 03:33:16 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6J7WKA26578; Sat, 19 Jul 2003 10:32:20 +0300 From: Pekka Savola To: isis-wg@ietf.org cc: randy@psg.com, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Isis-wg] Feedback on IS-IS Automatic Encapsulation 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: Sat, 19 Jul 2003 10:32:20 +0300 (EEST) Hi, I was asked to review the IS-IS Automatic Encapsulation document. Overall, the specification is of very high quality one seldom gets to review (thanks!), but I do not think this is architecturally or operationally the right way to solve the problem. Therefore I do not recommend on continuing with the work. subtantive comments ------------------- 1) area of applicability. It is not clear what the real applicability of this technique is; or rather, it is easy to guess one: being able to implement automatic IPv6-over-IPv4 tunneling mechanism in a routing protocol (similar have been proposed for OSPF, and for BGP multiple times) so that it would be possible to avoid upgrading some of the routers to handle dual protocols. The operational community and v6ops working group has been very hesitant about techniques like these, and as of yet, the v6ops working group has not been able to determine any real use cases for techniques like this. If asked at any point (with current knowledge), the v6ops working group would not recommend specifying or publishing this mechanism. Instead of real deployment of dual-stack networks, we add more code to the routers, and add hacks/features which add significantly to the complexity of the code and the network. Note that the multiple topology IS-IS specification would probably satisfy the requirements of partial IPv4/IPv6 deployment in a simpler manner, if really necessary. As an aside, we run an IPv4/IPv6 backbone, use IS-IS as our IPv6 routing protocol, and haven't had *any* need for even multiple-topology IS-IS (and I'm not sure if even that is needed). In short, I do not believe this work should be continued. 2) operational requirements. There is always a desire to be able to manage and maintain the interfaces of routers. In particular, it is a strict requirement to know of things such as packet/byte counts, error counts, etc. -- using a command-line interface as well as other management tools such as SNMP. As far as I know, the document does not take stance on this at all. The probable implementation technique is probably some kind of generic tunneling mechanism pseudo-interface which includes all of this information. In this particular case, it might also be desirable to be able to see between which intermediate systems automatic tunnels have been built, how much traffic has been passed through them etc. This is to be able to see whether the implementation is working as expected, i.e. encapsulating towards directions it should, and not encapsulating to those directions it should not. It is worth considering whether this is something to mention in the specification. 3) a doubt about specification. I note that the pseudocode for Dijkstra's new algorithm appears quite complex and is 4 pages long. I note that there is a possibility of IPR claims on this subject. This may or may not be a significant drawback for the specification and implementation. 4) two significant technical worries about the specification. An IS that also supports manually configured tunnels will need to check that a packet has not arrived over a manual tunnel in the normal way before discarding it. ==> no way to check that for certain, because there could be a configured (GRE) tunnel between the two systems (without IS-IS being run over one) as it is. Encapsulated packets should never arrive from any source other than another IS in the same level-1 area or level-2 subdomain, and this MAY then be used as the basis of a security filter. ==> how do you know if the source address correspons to the address of another IS? Note that nowhere does it specify which source address to use when encapsulating a packet, only that it must equal to the identity of the IS (whatever that means). ==> note that in general, automatic tunneling techniques have been considered as a rather dubious area of work, security-wise. Luckily enough, this specification luckily describes some mechanisms to mitigate this threat. editorial --------- ==> as the length is more than 15 pages, a table-of-contents is required ==> the abstract has references (disallowed), and is too long; perhaps the distinction between an abstract/introduction is not clear. The IETF is advised of potential intellectual property rights in regard to some or all of the specification contained in this document. For more information consult the online list for notices and/or updates. ==> this should be removed and moved to a full-flegded IPR Statement at the end, before the Copyright Notice section; like: Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 2.Introduction ==> s/2./2. / (and similar elsewhere) 3.The automatic encapsulation mechanism. ==> s/mechanism./mechanism/ (similar everywhere) ==> the title should be written like: "The Automatic Encapsulation Mechanism" 7.1 Injection of IP and CLNP packets into the network An IS that employs automatic encapsulation is required to unencapsulate any incoming packet that is of a an advertised encapsulation mode, and forward the contents. ==> s/of a/of/ ==> still a bit unclear, maybe change s/that is of/that uses/ ? 8.References ==> references need to split to normative/informative -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Jul 19 20:15:38 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 UAA26406 for ; Sat, 19 Jul 2003 20:15:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19e1qv-0006YA-EI; Sat, 19 Jul 2003 20:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19e1q2-0006XC-F0 for isis-wg@optimus.ietf.org; Sat, 19 Jul 2003 20:14:06 -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 UAA26381 for ; Sat, 19 Jul 2003 20:14:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19e1q0-0005HC-00 for isis-wg@ietf.org; Sat, 19 Jul 2003 20:14:04 -0400 Received: from web21503.mail.yahoo.com ([66.163.169.14]) by ietf-mx with smtp (Exim 4.12) id 19e1pp-0005Gz-00 for isis-wg@ietf.org; Sat, 19 Jul 2003 20:13:53 -0400 Message-ID: <20030720001328.91783.qmail@web21503.mail.yahoo.com> Received: from [80.194.90.59] by web21503.mail.yahoo.com via HTTP; Sun, 20 Jul 2003 01:13:28 BST From: =?iso-8859-1?q?Philip=20Christian?= Reply-To: christian_tena@yahoo.co.uk Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation To: pekkas@netcore.fi, isis-wg@ietf.org 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: Sun, 20 Jul 2003 01:13:28 +0100 (BST) Content-Transfer-Encoding: 8bit I always felt that automatic encapsulation might be of less practical use in the Internet than in the context in which it was thought of, and that is in SDH/SONET DCN networks. Most Internet routers (more probably all) are reasonably easily upgradable, and operators probably don't mind taking a router out of service for a while in order to upgrade it to IPv6. The only slight problem that they have is that because of IS-IS topological restrictions they shouldn't really forward any IPv6 traffic in the level-1 area or level-2 subdomain until all of the routers have been upgraded, unless they use something like MT. One slight advantage might be to tunnel v6 over v4 to get past routers that have hardware forwarding of v4 but software forwarding for v6, another (compared with 6to4) is that there is no one explicit gateway. With automatic encap one can have as many tunnelling gateways as one wishes and let IS-IS choose one. SDH/SONET networks are different. Some SDH/SONET ADMs are twenty years old, and only forward CLNP, and will most likely never be able to forward IP. Moreover, restarting or rebooting one of these boxes that has live traffic on it is simply out of the question. One solution is to use manually configured RFC 3147 tunnels in order to run IP traffic through these old ADMs. Most likely many vendors will offer this option. The problem with manual tunnels is that in order to achieve any redundancy one has to run a routing protocol inside the tunnel. The D1-D3 overhead channel in SDH/SONET is only 192kbps. Moreover many of the older ADMs may not even be able to forward 192kbps. One popular ADM can only forward about 128kbps before it runs out of processing power. This means that if one runs more than about 10 or 12 tunnels, each with an adjacency maintained inside it, then one can very quickly run out of bandwidth just because of all the hellos and LSPs/LSAs. Each time the topology changes the LSPs/LSAs get flooded down all interfaces and all tunnels, and if there are 10 tunnels then that is a lot of packets (well more than 192kbps anyway). Pretty soon adjacencies in the tunnels fail causing more topology change and eventual complete instability. Automatic encapsulation solves this problem because there are no tunnel "interfaces" as such, and only one adjacency to maintain, which is the original IS-IS one. The other beauty of automatic encapsulation is that the tunnels don't need to be configured, and then configured again for redundancy. They just happen automatically. For this reason I expect automatic encapsulation to become quite popular amongst SHD/SONET vendors. It is really an answer to their backward compatibility and support issues, as they can provide IP management to their new ADMs without needing to upgrade the old ones, in a scalable and reliable way and without a lot of configuration needed. This stuff is already out there in ITU-T G.7712 and it will happen. The question may be simply whether and how to document it in the IETF. I accept many of the comments in your e-mail, however I feel that the comments on the pseudo code are not fair. Pseudo code of Dijkstra's algorithm already appears in ISO 10589 and in RFC 1195, and is already about four pages long in those documents. The changes made compared with the pseudo code in RFC 1195 really only amount to a few lines. Secondly I have not seen any OSPF or BGB proposal that has been progressed quite to this level of functionality or usefulness. I really don't believe that this can be done with OSPF as IPv4 is so imbedded in OSPFv2 and IPv6 so imbedded in OSPFv3. This approach works in IS-IS only because IS-IS all about discribing topology independantly of network layer protocols. I have little knowledge of BGP. Philip Christian On 19 Jul 2003 at 10:32, Pekka Savola wrote: > Hi, > > I was asked to review the IS-IS Automatic Encapsulation document. > > Overall, the specification is of very high quality one seldom gets to review > (thanks!), but I do not think this is architecturally or operationally the > right way to solve the problem. Therefore I do not recommend on continuing > with the work. > > subtantive comments > ------------------- > > 1) area of applicability. > > It is not clear what the real applicability of this technique is; or rather, > it is easy to guess one: being able to implement automatic IPv6-over-IPv4 > tunneling mechanism in a routing protocol (similar have been proposed for > OSPF, and for BGP multiple times) so that it would be possible to avoid > upgrading some of the routers to handle dual protocols. > > The operational community and v6ops working group has been very hesitant > about techniques like these, and as of yet, the v6ops working group has not > been able to determine any real use cases for techniques like this. If > asked at any point (with current knowledge), the v6ops working group would > not recommend specifying or publishing this mechanism. > > Instead of real deployment of dual-stack networks, > we add more code to the routers, and add hacks/features > which add significantly to the complexity of the code and the network. > > Note that the multiple topology IS-IS specification would probably satisfy > the requirements of partial IPv4/IPv6 deployment in a simpler manner, if > really necessary. As an aside, we run an IPv4/IPv6 backbone, use IS-IS as > our IPv6 routing protocol, and haven't had *any* need for even > multiple-topology IS-IS (and I'm not sure if even that is needed). > > In short, I do not believe this work should be continued. > > 2) operational requirements. > > There is always a desire to be able to manage > and maintain the interfaces of routers. In particular, it is a strict > requirement to know of things such as packet/byte counts, error counts, etc. > -- using a command-line interface as well as other management tools such as > SNMP. > > As far as I know, the document does not take stance on this at all. The > probable implementation technique is probably some kind of generic > tunneling mechanism pseudo-interface which includes all of this information. > In this particular case, it might also be desirable to be able to see > between which intermediate systems automatic tunnels have been built, how > much traffic has been passed through them etc. This is to be able to see > whether the implementation is working as expected, i.e. encapsulating > towards directions it should, and not encapsulating to those directions it > should not. > > It is worth considering whether this is something to mention in the > specification. > > 3) a doubt about specification. > > I note that the pseudocode for Dijkstra's new algorithm appears quite > complex and is 4 pages long. > > I note that there is a possibility of IPR claims on this subject. This may > or may not be a significant drawback for the specification and > implementation. > > 4) two significant technical worries about the specification. > > An IS that also supports manually configured tunnels will need to > check that a packet has not arrived over a manual tunnel in the > normal way before discarding it. > > ==> no way to check that for certain, because there could be a configured > (GRE) tunnel between the two systems (without IS-IS being run over one) as > it is. > > Encapsulated packets should never arrive from any source other > than another IS in the same level-1 area or level-2 subdomain, > and this MAY then be used as the basis of a security filter. > > ==> how do you know if the source address correspons to the address of > another IS? Note that nowhere does it specify which source address to use > when encapsulating a packet, only that it must equal to the identity of the > IS (whatever that means). > > ==> note that in general, automatic tunneling techniques have been > considered as a rather dubious area of work, security-wise. Luckily enough, > this specification luckily describes some mechanisms to mitigate this > threat. > > > > > editorial > --------- > > ==> as the length is more than 15 pages, a table-of-contents is required > > ==> the abstract has references (disallowed), and is too long; perhaps the > distinction between an abstract/introduction is not clear. > > The IETF is advised of potential intellectual property rights in > regard to some or all of the specification contained in this > document. For more information consult the online list for notices > and/or updates. > > ==> this should be removed and moved to a full-flegded IPR Statement at the > end, before the Copyright Notice section; like: > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > intellectual property or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; neither does it represent that it > has made any effort to identify any such rights. Information on the > IETF's procedures with respect to rights in standards-track and > standards-related documentation can be found in BCP-11. Copies of > claims of rights made available for publication and any assurances of > licenses to be made available, or the result of an attempt made to > obtain a general license or permission for the use of such > proprietary rights by implementors or users of this specification can > be obtained from the IETF Secretariat. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights which may cover technology that may be required to practice > this standard. Please address the information to the IETF Executive > Director. > > > 2.Introduction > > ==> s/2./2. / (and similar elsewhere) > > 3.The automatic encapsulation mechanism. > > ==> s/mechanism./mechanism/ (similar everywhere) > ==> the title should be written like: "The Automatic Encapsulation > Mechanism" > > 7.1 Injection of IP and CLNP packets into the network > > An IS that employs automatic encapsulation is required to > unencapsulate any incoming packet that is of a an advertised > encapsulation mode, and forward the contents. > > ==> s/of a/of/ > ==> still a bit unclear, maybe change s/that is of/that uses/ ? > > 8.References > > ==> references need to split to normative/informative > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > _______________________________________________ > 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://uk.messenger.yahoo.com/ _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jul 21 11:13:50 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 LAA00389 for ; Mon, 21 Jul 2003 11:13:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecLT-0000J5-QI; Mon, 21 Jul 2003 11:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecKj-0000IP-2U for isis-wg@optimus.ietf.org; Mon, 21 Jul 2003 11:12: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 LAA00337 for ; Mon, 21 Jul 2003 11:12:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecKi-0003er-00 for isis-wg@ietf.org; Mon, 21 Jul 2003 11:12:12 -0400 Received: from kanfw1.ottawa.alcatel.ca ([192.75.23.69] helo=kanmx1.ca.alcatel.com) by ietf-mx with smtp (Exim 4.12) id 19ecKX-0003eh-00 for isis-wg@ietf.org; Mon, 21 Jul 2003 11:12:01 -0400 Received: (qmail 17781 invoked from network); 21 Jul 2003 15:22:09 -0000 Received: from unknown (HELO alcatel.com) (138.120.105.195) by kanmx1.ca.alcatel.com with SMTP; 21 Jul 2003 15:22:09 -0000 Message-ID: <3F1C02A8.671315CE@alcatel.com> From: Myles Dear Organization: Alcatel Canada X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Some concerns with draft standard IS-IS MIB 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, 21 Jul 2003 11:11:36 -0400 Content-Transfer-Encoding: 7bit We are implementing the IS-IS protocol on a switch, and want to allow managers to retrieve the list of configured NET addresses on the node. We noticed that the current draft IS-IS MIB defines isisManAreaAddrTable as "not-accessible". Why was this table defined as "not-accessible"? Furthermore, the type OSINSAddress states that it can be used to represent a Network Entity Title. The object isisManAreaAddr (which has type OSINSAddress) is defined to only carry the area address. There is an inconsistency here, since the NET of course carries both the area address and the system ID. Thanks, _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jul 21 11:52:35 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 LAA01413 for ; Mon, 21 Jul 2003 11:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecxF-0001sf-5j; Mon, 21 Jul 2003 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ecwn-0001ro-R9 for isis-wg@optimus.ietf.org; Mon, 21 Jul 2003 11:51:33 -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 LAA01331 for ; Mon, 21 Jul 2003 11:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ecwm-0003z9-00 for isis-wg@ietf.org; Mon, 21 Jul 2003 11:51:32 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19ecwb-0003z0-00 for isis-wg@ietf.org; Mon, 21 Jul 2003 11:51:21 -0400 Message-ID: From: Jeff Parker To: "'Myles Dear'" , isis-wg@ietf.org Subject: RE: [Isis-wg] Some concerns with draft standard IS-IS MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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, 21 Jul 2003 11:50:12 -0400 Myles - I will take a look at the text describing a NET. "not-accessible" is a term that is used by the SNMP community for indices. The term is confusing when you first encounter it, but does not prevent you from seeing the values. You may want to take a look at Perkin's "Understanding SNMP MIBs" for a explanation of the reasoning behind the term. - jeff parker - axiowave networks > -----Original Message----- > From: Myles Dear [mailto:Myles.Dear@alcatel.com] > Sent: Monday, July 21, 2003 11:12 AM > To: isis-wg@ietf.org > Subject: [Isis-wg] Some concerns with draft standard IS-IS MIB > > > We are implementing the IS-IS protocol on a switch, and want to allow > managers to retrieve the list of configured NET addresses on the node. > We noticed that the current draft IS-IS MIB defines > isisManAreaAddrTable > as "not-accessible". Why was this table defined as "not-accessible"? > > Furthermore, the type OSINSAddress states that it can be used to > represent a > Network Entity Title. > The object isisManAreaAddr (which has type OSINSAddress) is defined to > only carry the area address. > > There is an inconsistency here, since the NET of course > carries both the > area address and the system ID. > > Thanks, > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jul 21 12:48:35 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 MAA03278 for ; Mon, 21 Jul 2003 12:48: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 19edpR-0004DM-2t; Mon, 21 Jul 2003 12:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19edoW-0004D3-OD for isis-wg@optimus.ietf.org; Mon, 21 Jul 2003 12:47:04 -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 MAA03206 for ; Mon, 21 Jul 2003 12:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19edoV-0004T3-00 for isis-wg@ietf.org; Mon, 21 Jul 2003 12:47:03 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19edoK-0004Si-00 for isis-wg@ietf.org; Mon, 21 Jul 2003 12:46:52 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2003 09:52:16 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6LGkFuD007771; Mon, 21 Jul 2003 09:46:15 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (rtp-vpn1-256.cisco.com [10.82.225.0]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHV50168; Mon, 21 Jul 2003 09:46:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20030721120249.020d0ed0@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "'Myles Dear'" From: Jeff Learman Subject: RE: [Isis-wg] Some concerns with draft standard IS-IS MIB Cc: isis-wg@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 21 Jul 2003 12:17:27 -0400 At 11:50 AM 7/21/2003, Jeff Parker wrote: >> There is an inconsistency here, since the NET of course >> carries both the area address and the system ID. And the N-Selector, don't forget, which should be a single octet of zero. Also, be wary of playing "mix and match" with manual area addresses and system IDs and expecting all implementations to work the same if you try to use these addresses to send data. ISO standards specifically forbid anyone outside the network layer to play "mix and match" with address parts. A conformant implementation may or may not respond when sent data to an NSAP that consists of an area ID plus system ID plus valid NSEL for Transport on that system. If you're using the NET to address for addressing PDUs to be decapsulated, the rules may be different. I believe there are specific rules for addressing CLNP PDUs encapsulated in CLNP for the purpose of partition repair -- you'd need to check ISO 10589, I don't remember off the top of my head. There also may be specific requirements for addressing (and what addresses a system must accept) in Philip's document for auto-encapsulation. Other than that, I don't know of any specific requirements for addressing the network layer itself, and playing mix-and-match isn't guaranteed to work. It probably will, and it's more likely than addressing Transport, but just be forewarned. Jeff >> >> Thanks, >> _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 22 19:25:04 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 TAA00649 for ; Tue, 22 Jul 2003 19:25:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f6UD-00058e-Bn; Tue, 22 Jul 2003 19:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f6Tn-00058E-NR for isis-wg@optimus.ietf.org; Tue, 22 Jul 2003 19:23:35 -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 TAA00631 for ; Tue, 22 Jul 2003 19:23:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f6Tm-0000CY-00 for isis-wg@ietf.org; Tue, 22 Jul 2003 19:23:34 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19f6Tb-0000CQ-00 for isis-wg@ietf.org; Tue, 22 Jul 2003 19:23:23 -0400 Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id A69CF33BAAC; Tue, 22 Jul 2003 16:21:13 -0700 (PDT) Message-ID: <3F1DC6E9.E3761564@redback.com> From: Albert Tian X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: isis-wg@ietf.org, randy@psg.com, zinin@psg.com Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 22 Jul 2003 16:21:13 -0700 Content-Transfer-Encoding: 7bit Hi, Pekka, Pekka Savola wrote: [snip] > Note that the multiple topology IS-IS specification would probably satisfy > the requirements of partial IPv4/IPv6 deployment in a simpler manner, if > really necessary. As an aside, we run an IPv4/IPv6 backbone, use IS-IS as > our IPv6 routing protocol, and haven't had *any* need for even > multiple-topology IS-IS (and I'm not sure if even that is needed). Just a quick comment on your side note. Using the single-topology ipv6 ( as opposed to multi-topology ipv6 ), you need a flag day to upgrade all your routers and turn it on on all interfaces. Using multi-topology gives you more control regarding to which protocol goes where and allows you to roll out ipv6 incrementally. For a sizable network, these flexibilities will probably generate some demand for MT. Cheers, Albert _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 22 19:31:40 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 TAA00824 for ; Tue, 22 Jul 2003 19:31:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f6az-0005Hq-Ko; Tue, 22 Jul 2003 19:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f6aL-0005HK-9C for isis-wg@optimus.ietf.org; Tue, 22 Jul 2003 19:30:21 -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 TAA00784 for ; Tue, 22 Jul 2003 19:30:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f6aJ-0000FE-00 for isis-wg@ietf.org; Tue, 22 Jul 2003 19:30:19 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19f6a8-0000EP-00 for isis-wg@ietf.org; Tue, 22 Jul 2003 19:30:08 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 1A7BE23C77; Tue, 22 Jul 2003 16:31:49 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6MNTHYB022442; Tue, 22 Jul 2003 16:29:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Feedback on IS-IS Automatic Encapsulation Message-ID: Thread-Topic: [Isis-wg] Feedback on IS-IS Automatic Encapsulation Thread-Index: AcNQqJ+xVBPQOXV0QD2ufWSNjhVh7wAACudQ From: "Tony Li" To: "Albert Tian" , "Pekka Savola" Cc: , , Content-Transfer-Encoding: quoted-printable 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, 22 Jul 2003 16:29:17 -0700 Content-Transfer-Encoding: quoted-printable Strictly speaking, that's not necessarily true. As long as your IPv6 topology is convex, you should be fine. Obviously, you want to migrate to having all routers within an area running the same L3 protocols for management simplicity. The real question that we need to discuss is whether the need for topological flexibility outweighs the complexity. Tony | -----Original Message----- | From: Albert Tian [mailto:tian@redback.com]=20 | Sent: Tuesday, July 22, 2003 4:21 PM | To: Pekka Savola | Cc: isis-wg@ietf.org; randy@psg.com; zinin@psg.com | Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation | =20 | =20 | Hi, Pekka, | =20 | Pekka Savola wrote: | =20 | [snip] | =20 | > Note that the multiple topology IS-IS specification=20 | would probably satisfy | > the requirements of partial IPv4/IPv6 deployment in a=20 | simpler manner, if | > really necessary. As an aside, we run an IPv4/IPv6=20 | backbone, use IS-IS as | > our IPv6 routing protocol, and haven't had *any* need for even | > multiple-topology IS-IS (and I'm not sure if even that=20 | is needed). | =20 | Just a quick comment on your side note.=20 | =20 | Using the single-topology ipv6 ( as opposed to=20 | multi-topology ipv6 ), you need a | flag day to upgrade all your routers and turn it on on all=20 | interfaces. Using | multi-topology gives you more control regarding to which=20 | protocol goes where and | allows you to roll out ipv6 incrementally. For a sizable=20 | network, these | flexibilities will probably generate some demand for MT. | =20 | Cheers, | =20 | Albert | =20 | _______________________________________________ | Isis-wg mailing list | Isis-wg@ietf.org | https://www1.ietf.org/mailman/listinfo/isis-wg | _______________________________________________ | Isis-wg-external mailing list | Isis-wg-external@mailist.procket.com | http://mailist.procket.com/mailman/listinfo/isis-wg-external | =20 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 22 20:31:45 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 UAA01779 for ; Tue, 22 Jul 2003 20:31:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7X3-00073o-NO; Tue, 22 Jul 2003 20:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7Wm-00073J-UA for isis-wg@optimus.ietf.org; Tue, 22 Jul 2003 20:30:45 -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 UAA01751 for ; Tue, 22 Jul 2003 20:30:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f7Wk-0000Wd-00 for isis-wg@ietf.org; Tue, 22 Jul 2003 20:30:42 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19f7WZ-0000WN-00 for isis-wg@ietf.org; Tue, 22 Jul 2003 20:30:31 -0400 Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id E43CF145365; Tue, 22 Jul 2003 17:28:27 -0700 (PDT) Message-ID: <3F1DD6AB.59936BD6@redback.com> From: Albert Tian X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li Cc: Pekka Savola , isis-wg@ietf.org, randy@psg.com, zinin@psg.com Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 22 Jul 2003 17:28:27 -0700 Content-Transfer-Encoding: 7bit Hi, Tony, Tony Li wrote: > > Strictly speaking, that's not necessarily true. As long as your > IPv6 topology is convex, you should be fine. That I agree. > Obviously, you want to > migrate to having all routers within an area running the same L3 > protocols > for management simplicity. Ture. If you've decided to roll out ipv6 on all your nodes, you might as well do it in one shot. But there may also be cases where people want to try on selective sites and see. > > The real question that we need to discuss is whether the need for > topological flexibility outweighs the complexity. Also there is the traffic engineering flexibility. MT allows seperate metric and requires seperate spf for v4 and v6. The need will vary from operator to operator. My guess is that there will always a percentage of the spectrum that will say yes. The question is what percentage. Thanks, Albert > > Tony > > | -----Original Message----- > | From: Albert Tian [mailto:tian@redback.com] > | Sent: Tuesday, July 22, 2003 4:21 PM > | To: Pekka Savola > | Cc: isis-wg@ietf.org; randy@psg.com; zinin@psg.com > | Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation > | > | > | Hi, Pekka, > | > | Pekka Savola wrote: > | > | [snip] > | > | > Note that the multiple topology IS-IS specification > | would probably satisfy > | > the requirements of partial IPv4/IPv6 deployment in a > | simpler manner, if > | > really necessary. As an aside, we run an IPv4/IPv6 > | backbone, use IS-IS as > | > our IPv6 routing protocol, and haven't had *any* need for even > | > multiple-topology IS-IS (and I'm not sure if even that > | is needed). > | > | Just a quick comment on your side note. > | > | Using the single-topology ipv6 ( as opposed to > | multi-topology ipv6 ), you need a > | flag day to upgrade all your routers and turn it on on all > | interfaces. Using > | multi-topology gives you more control regarding to which > | protocol goes where and > | allows you to roll out ipv6 incrementally. For a sizable > | network, these > | flexibilities will probably generate some demand for MT. > | > | Cheers, > | > | Albert > | > | _______________________________________________ > | Isis-wg mailing list > | Isis-wg@ietf.org > | https://www1.ietf.org/mailman/listinfo/isis-wg > | _______________________________________________ > | Isis-wg-external mailing list > | Isis-wg-external@mailist.procket.com > | http://mailist.procket.com/mailman/listinfo/isis-wg-external > | _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 02:28:40 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 CAA29579 for ; Wed, 23 Jul 2003 02:28:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fD6W-0002Ul-NQ; Wed, 23 Jul 2003 02:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fD5m-0002S8-4E for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 02:27:14 -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 CAA29037 for ; Wed, 23 Jul 2003 02:27:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fD5i-0002Bj-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 02:27:10 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19fD5W-00029w-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 02:26:58 -0400 Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id 40F9372FAEF; Tue, 22 Jul 2003 23:21:28 -0700 (PDT) Message-ID: <3F1E2968.24357ABF@redback.com> From: Albert Tian X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Tony Li , isis-wg@ietf.org, randy@psg.com, zinin@psg.com Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 22 Jul 2003 23:21:28 -0700 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > Hi, > > I changed to subject as we turned to speaking of MT IS-IS.. which is fine > :-) > > On Tue, 22 Jul 2003, Tony Li wrote: > > Strictly speaking, that's not necessarily true. As long as your IPv6 > > topology is convex, you should be fine. Obviously, you want to migrate > > to having all routers within an area running the same L3 protocols for > > management simplicity. > > My point exactly. > > We've avoided the pain here, and some other operational networks I've been > talking about have upgraded their core by keeping it convex. Their core > is still only partially upgraded by the way. I'm supprised to hear this ... they must be really good at topology :-) One question here -- consider the nodes and the links that form the boundary of your convex, how can you gurantee that when any of them fails the backup route would fall inside your boundary? Thanks, Albert > > My belief that this is not really the case. Ops folks just *don't* roll > out new features to every box during a night (well some might, and in some > cases it might be warranted, but it's rather rare). People deploy it in a > few places, watch out for a couple of weeks for the first bugs to show up, > work on finding solutions to those, start expanding etc. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 03:23:35 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 DAA04385 for ; Wed, 23 Jul 2003 03:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDxl-00054m-H3; Wed, 23 Jul 2003 03:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDnA-0004hG-75 for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 03:12:04 -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 DAA04131 for ; Wed, 23 Jul 2003 03:12:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDn7-0002Vx-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 03:12:01 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDmw-0002VZ-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 03:11:51 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6N7Ape15684; Wed, 23 Jul 2003 10:10:51 +0300 From: Pekka Savola To: Albert Tian cc: Tony Li , , , Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-Reply-To: <3F1E2968.24357ABF@redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 23 Jul 2003 10:10:51 +0300 (EEST) On Tue, 22 Jul 2003, Albert Tian wrote: > > I changed to subject as we turned to speaking of MT IS-IS.. which is fine > > :-) > > > > On Tue, 22 Jul 2003, Tony Li wrote: > > > Strictly speaking, that's not necessarily true. As long as your IPv6 > > > topology is convex, you should be fine. Obviously, you want to migrate > > > to having all routers within an area running the same L3 protocols for > > > management simplicity. > > > > My point exactly. > > > > We've avoided the pain here, and some other operational networks I've been > > talking about have upgraded their core by keeping it convex. Their core > > is still only partially upgraded by the way. > > I'm supprised to hear this ... they must be really good at topology :-) Yep :-) > One question here -- consider the nodes and the links that form the > boundary of your convex, how can you gurantee that when any of them > fails the backup route would fall inside your boundary? The costs have been assigned so that any failure of one link or node will still stay convex (AFAIR). If multiple nodes go kaboom, it may not necessarily be the case anymore, but that's typically beyond the scope of redundancy requirements. ... I'm sure that in the general case keeping your topology convex for extended periods of time and having to also consider backup routes will give you headaches -- which is why I think there are basically three possibilities/stages to the IPv6 IGP introduction: - having separate IGP's for v4 and v6; we use OSPF for v4 and IS-IS for v6 so we don't have any problems. (Avoids all the problems of the "v6 kick-start phase".) Could be the other way too, now that OSPFv3 is rather widely supported. - testing IS-IS for v4 and v6 is rather straightforward with a small number or nodes (2-3 or the like). Such topologies may be more easily be kept convex. This decision give enough confidence for "no-go" or "go and deploy everywhere" -decision. - deploying IS-IS for v4 and v6 everywhere; typically done after the previous point. You don't have to worry about backup connectivity, but keeping the topology convex while expanding your convex area is desirable. As all you have to do is to enable IS-IS for v6 (you can deploy IP addresses, new software, etc. beforehand), this is a very quick operation and could also be done (in some cases) during a short maintenance window. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 03:24:32 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 DAA04471 for ; Wed, 23 Jul 2003 03:24:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDyj-0005EJ-6l; Wed, 23 Jul 2003 03:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDy6-0005DC-Fg for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 03:23:22 -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 DAA04376 for ; Wed, 23 Jul 2003 03:23:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fDy4-0002cM-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 03:23:20 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19fDxt-0002bv-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 03:23:09 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 3C49934490; Wed, 23 Jul 2003 00:22:09 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6N7MJYB008385; Wed, 23 Jul 2003 00:22:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Message-ID: Thread-Topic: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Thread-Index: AcNQ6ZQ+e6hObMwHTi+JQ9NEkhX1SQAAViUA From: "Tony Li" To: "Pekka Savola" , "Albert Tian" Cc: , , Content-Transfer-Encoding: quoted-printable 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, 23 Jul 2003 00:22:19 -0700 Content-Transfer-Encoding: quoted-printable Another alternative that I would expect to see is a 'pilot' deployment of a protocol in a very limited fashion. During this pilot, the reliability of v6 would not be part of an SLA, so the packet losses resulting from concavity would not be=20 catastrophic. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 04:11:27 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 DAA04384 for ; Wed, 23 Jul 2003 03:23:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fDxl-00054b-0K; Wed, 23 Jul 2003 03:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fCXX-0008E0-B0 for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 01:51:51 -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 BAA06360 for ; Wed, 23 Jul 2003 01:51:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fCXU-0001zT-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 01:51:48 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx with esmtp (Exim 4.12) id 19fCXJ-0001ye-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 01:51:37 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6N5oXZ14617; Wed, 23 Jul 2003 08:50:34 +0300 From: Pekka Savola To: Tony Li cc: Albert Tian , , , Subject: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS Automatic Encapsulation] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 23 Jul 2003 08:50:33 +0300 (EEST) Hi, I changed to subject as we turned to speaking of MT IS-IS.. which is fine :-) On Tue, 22 Jul 2003, Tony Li wrote: > Strictly speaking, that's not necessarily true. As long as your IPv6 > topology is convex, you should be fine. Obviously, you want to migrate > to having all routers within an area running the same L3 protocols for > management simplicity. My point exactly. We've avoided the pain here, and some other operational networks I've been talking about have upgraded their core by keeping it convex. Their core is still only partially upgraded by the way. My belief that this is not really the case. Ops folks just *don't* roll out new features to every box during a night (well some might, and in some cases it might be warranted, but it's rather rare). People deploy it in a few places, watch out for a couple of weeks for the first bugs to show up, work on finding solutions to those, start expanding etc. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 04:30:42 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 EAA05801 for ; Wed, 23 Jul 2003 04:30:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fF0c-0007v9-Gz; Wed, 23 Jul 2003 04:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fF03-0007uG-2G for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 04:29:27 -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 EAA05747 for ; Wed, 23 Jul 2003 04:29:23 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fEzz-000356-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:29:23 -0400 Received: from smtp101.mail.sc5.yahoo.com ([216.136.174.139]) by ietf-mx with smtp (Exim 4.12) id 19fEzp-00034p-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:29:13 -0400 Received: from wireless09.one2one.net (HELO pchristi) (christian?tena@149.254.200.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jul 2003 08:28:49 -0000 To: Pekka Savola , Albert Tian MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk CC: isis-wg@ietf.org Message-ID: <3F1E56E4.31703.FEE0D@localhost> Priority: normal In-reply-to: References: <3F1E2968.24357ABF@redback.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 23 Jul 2003 09:35:32 +0100 Content-Transfer-Encoding: 7BIT what is a "convex" topology ? Philip _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 04:42: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 EAA06107 for ; Wed, 23 Jul 2003 04:42: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 19fFCE-0000Jc-GB; Wed, 23 Jul 2003 04:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFC0-0000GJ-Ha for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 04:41:50 -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 EAA06083 for ; Wed, 23 Jul 2003 04:41:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fFBx-0003E5-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:41:45 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19fFBm-0003Dh-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:41:34 -0400 Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id 6473138B549; Wed, 23 Jul 2003 01:41:13 -0700 (PDT) Message-ID: <3F1E4A29.9A62FC1F@redback.com> From: Albert Tian X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Tony Li , isis-wg@ietf.org, randy@psg.com, zinin@psg.com Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 23 Jul 2003 01:41:13 -0700 Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Wed, 23 Jul 2003, Tony Li wrote: > > Another alternative that I would expect to see is a 'pilot' > > deployment of a protocol in a very limited fashion. During > > this pilot, the reliability of v6 would not be part of an > > SLA, so the packet losses resulting from concavity would not be > > catastrophic. > > Very true. > > Note that you should also take care not to include v6-only (or boxes which > should be mainly for v6, as seems to be common in ISPs' IPv6 deployments) > boxes in the network -- to avoid the possible issue of routing _v4_ > through those _v6_ boxes. > > In any sane network, this should not be an issue due to the very high link > costs assigned to links to such routers, though. So we all agree that maintaining convexity while considering the failure cases is very difficult, correct? I actually do not think the failproof solution can be easily calculated without special tools. Also because this requires tweaking the link cost, it would disturb the carefully engineered v4 traffic pattern, which is undesirable(this is another example showing the limitation of sharing the cost between v4 and v6). The situation will be even worse if the pilot involves more than one phase and it requires you to expand the convex once or more. Given all the above, relaxing the SLA seems to be the only solution. Still there may be troubleshooting issues. If the pilot lasts for extended period of time, various failure cases are bound to happen. When it happens, the situation will be quite undebugable IMHO. Changing a cost or shutting down an interface may break your convexity, and it may be hard to find the causality. (Guess vendors need to add the "concave detector" in the spf then). Also in somecases the pilot may be driven by where your first v6 costumers are so the convex may not come in handy(say you want to enable 3 sites but the trangle pretty much covers all your network). In short, my point is that the convex has its limitations when used as a generic transitional strategy. my 2c, Cheers, Albert > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 04:45: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 EAA06211 for ; Wed, 23 Jul 2003 04:45: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 19fFF6-0000T0-Kn; Wed, 23 Jul 2003 04:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFEX-0000SO-HZ for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 04:44:25 -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 EAA06171 for ; Wed, 23 Jul 2003 04:44:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fFEU-0003G9-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:44:22 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19fFEJ-0003G4-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:44:12 -0400 Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id D09D338B551; Wed, 23 Jul 2003 01:44:07 -0700 (PDT) Message-ID: <3F1E4AD7.956BC9C1@redback.com> From: Albert Tian X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: christian_tena@yahoo.co.uk Cc: Pekka Savola , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: <3F1E2968.24357ABF@redback.com> <3F1E56E4.31703.FEE0D@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 23 Jul 2003 01:44:07 -0700 Content-Transfer-Encoding: 7bit christian_tena@yahoo.co.uk wrote: > > what is a "convex" topology ? I think this means the path between any two nodes on a topology lies completely within the topology. Thanks, Albert > > Philip > > _______________________________________________ > 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 Wed Jul 23 04:51:32 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 EAA06319 for ; Wed, 23 Jul 2003 04:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFKv-0000gR-6o; Wed, 23 Jul 2003 04:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fFKG-0000co-Fo for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 04:50:20 -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 EAA06295 for ; Wed, 23 Jul 2003 04:50:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fFKD-0003K9-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:50:17 -0400 Received: from protactinium.btinternet.com ([194.73.73.176]) by ietf-mx with esmtp (Exim 4.12) id 19fFK2-0003Js-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 04:50:06 -0400 Received: from dial81-135-53-8.in-addr.btopenworld.com ([81.135.53.8] helo=aislingds.com) by protactinium.btinternet.com with esmtp (Exim 3.22 #23) id 19fFJe-00014R-00; Wed, 23 Jul 2003 09:49:43 +0100 Message-ID: <3F1E4C23.3020404@aislingds.com> From: Paul Fee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: christian_tena@yahoo.co.uk CC: Pekka Savola , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: <3F1E2968.24357ABF@redback.com> <3F1E56E4.31703.FEE0D@localhost> In-Reply-To: <3F1E56E4.31703.FEE0D@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 23 Jul 2003 09:49:39 +0100 Content-Transfer-Encoding: 7bit Philip, It sounds like it's one which is totally self enclosed. So if someone mentions that the dual IPv6/IPv4 portion of their network is convex, then that means that IPv6 packets would never be sent outside the IPv6/IPv4 part of the network, hence avoiding packet loss in the IPv4 only part of the network. A convex topology will be an island, but an island will not necessarily be convex. For example if the island has "arms" which extend from the core and routes are based only on metric and not on protocol type. Then routes may be chosen which go between arms, sending packets from one part of the island to another but breaking outside the boundary of the island. A convex topology allows the topology rules of RFC 1195 to be broken in a calculated way to avoid packet loss. -- Paul Fee Aisling Design Services Ltd. Tel: +44 (0)28 90811003 Mobile: +44 (0)7890 486204 Web: http://www.aislingds.com E-mail: mailto:paul.fee@aislingds.com christian_tena@yahoo.co.uk wrote: > what is a "convex" topology ? > > Philip > > _______________________________________________ > 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 Wed Jul 23 06:09:39 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 GAA07337 for ; Wed, 23 Jul 2003 06:09:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fGYP-00035n-EU; Wed, 23 Jul 2003 06:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fGXZ-00035Q-TN for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 06:08:09 -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 GAA07307 for ; Wed, 23 Jul 2003 06:08:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fGXW-0003fk-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 06:08:06 -0400 Received: from tower.partan.com ([198.6.255.248]) by ietf-mx with esmtp (Exim 4.12) id 19fGXG-0003ej-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 06:07:50 -0400 Received: from tower.partan.com (localhost.partan.com [127.0.0.1]) by tower.partan.com (8.12.6p2/8.12.6) with ESMTP id h6NA5xT1072398; Wed, 23 Jul 2003 06:05:59 -0400 (EDT) (envelope-from asp@tower.partan.com) Received: (from asp@localhost) by tower.partan.com (8.12.6p2/8.12.6/Submit) id h6NA5xq5072395; Wed, 23 Jul 2003 06:05:59 -0400 (EDT) (envelope-from asp) From: Andrew Partan To: Albert Tian Cc: isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Message-ID: <20030723100559.GA72347@partan.com> References: <3F1E2968.24357ABF@redback.com> <3F1E56E4.31703.FEE0D@localhost> <3F1E4AD7.956BC9C1@redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1E4AD7.956BC9C1@redback.com> User-Agent: Mutt/1.4.1i 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, 23 Jul 2003 06:05:59 -0400 On Wed, Jul 23, 2003 at 01:44:07AM -0700, Albert Tian wrote: > > what is a "convex" topology ? > > I think this means the path between any two nodes on a topology > lies completely within the topology. Which turns out to be difficult in practice. You need the multi-topology stuff. Then all you need is a conneted path & things work. If you have to have working software on supported hardware even on just a convex topology before things work, you may never get there. --asp _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 13:10:39 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 NAA20003 for ; Wed, 23 Jul 2003 13:10:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fN7p-0003uy-9e; Wed, 23 Jul 2003 13:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fN6u-0003tf-Rk for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 13:09:04 -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 NAA19954 for ; Wed, 23 Jul 2003 13:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fN6s-0006CF-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 13:09:02 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19fN6i-0006C0-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 13:08:52 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8FA7B23C4E; Wed, 23 Jul 2003 10:09:52 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6NH7oYB019534; Wed, 23 Jul 2003 10:08:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Message-ID: Thread-Topic: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Thread-Index: AcNRApitzMbpxiFdQIevZsM/Y1sydQAOin0Q From: "Tony Li" To: "Andrew Partan" , "Albert Tian" Cc: Content-Transfer-Encoding: quoted-printable 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, 23 Jul 2003 10:07:50 -0700 Content-Transfer-Encoding: quoted-printable | Which turns out to be difficult in practice. You need the | multi-topology stuff. Then all you need is a conneted=20 | path & things | work. If you have to have working software on supported hardware | even on just a convex topology before things work, you may never | get there. Andrew, Is the full-blown complexity of the MT stuff necessary? Do we=20 really need to worry about X forming an adajacnecy with Y and=20 the full set of protocol interactions? If this has to work, we may also never get there. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 23 15:16:38 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 PAA25626 for ; Wed, 23 Jul 2003 15:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5m-0001JG-1J; Wed, 23 Jul 2003 15:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fP5G-0001IB-Ec for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 15:15:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25387; Wed, 23 Jul 2003 15:15:27 -0400 (EDT) Message-Id: <200307231915.PAA25387@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-restart-04.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: Wed, 23 Jul 2003 15:15:27 -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 : Restart signaling for IS-IS Author(s) : M. Shand, L. Ginsberg Filename : draft-ietf-isis-restart-04.txt Pages : 17 Date : 2003-7-23 The IS-IS routing protocol (RFC 1195 [2], ISO/IEC 10589 [3]) is a link state intra-domain routing protocol. Normally, when an IS-IS router is restarted, temporary disruption of routing occurs due to events in both the restarting router and the neighbors of the restarting router. The router which has been restarted computes its own routes before achieving database synchronization with its neighbors. The results of this computation are likely to be non-convergent with the routes computed by other routers in the area/domain. Neighbors of the restarting router detect the restart event and cycle their adjacencies with the restarting router through the down state. The cycling of the adjacency state causes the neighbors to regenerate their LSPs describing the adjacency concerned. This in turn causes temporary disruption of routes passing through the restarting router. In certain scenarios the temporary disruption of the routes is highly undesirable. This draft describes mechanisms to avoid or minimize the disruption due to both of these causes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-04.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-restart-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-restart-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-23151154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-restart-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-restart-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23151154.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 Wed Jul 23 16:02: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 QAA00095 for ; Wed, 23 Jul 2003 16:02: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 19fPoG-0003Wt-Ca; Wed, 23 Jul 2003 16:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fPnf-0003WQ-A9 for isis-wg@optimus.ietf.org; Wed, 23 Jul 2003 16:01:23 -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 QAA29915 for ; Wed, 23 Jul 2003 16:01:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fPnd-0000BL-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 16:01:21 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19fPnR-00009l-00 for isis-wg@ietf.org; Wed, 23 Jul 2003 16:01:10 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6NK0Xpp016212 for ; Wed, 23 Jul 2003 13:00:33 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-72.cisco.com [128.107.163.72]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIH12902; Wed, 23 Jul 2003 12:54:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20030723125725.01a3f590@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@ietf.org From: Les Ginsberg Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-restart-04.txt In-Reply-To: <200307231915.PAA25387@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 23 Jul 2003 13:00:32 -0700 Folks - The version of the draft which is posted at the URL below is NOT the latest text. I am working with IETF to straighten this out. In the interim I suggest you simply ignore this announcement. My apologies for any confusion. Les At 03:15 PM 7/23/2003 -0400, Internet-Drafts@ietf.org wrote: >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 : Restart signaling for IS-IS > Author(s) : M. Shand, L. Ginsberg > Filename : draft-ietf-isis-restart-04.txt > Pages : 17 > Date : 2003-7-23 > >The IS-IS routing protocol (RFC 1195 [2], ISO/IEC 10589 [3]) is a >link state intra-domain routing protocol. Normally, when an IS-IS >router is restarted, temporary disruption of routing occurs due to >events in both the restarting router and the neighbors of the >restarting router. >The router which has been restarted computes its own routes before >achieving database synchronization with its neighbors. The results >of this computation are likely to be non-convergent with the routes >computed by other routers in the area/domain. >Neighbors of the restarting router detect the restart event and >cycle their adjacencies with the restarting router through the down >state. The cycling of the adjacency state causes the neighbors to >regenerate their LSPs describing the adjacency concerned. This in >turn causes temporary disruption of routes passing through the >restarting router. >In certain scenarios the temporary disruption of the routes is >highly undesirable. This draft describes mechanisms to avoid or >minimize the disruption due to both of these causes. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-04.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-restart-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-isis-restart-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-7-23151154.I-D@ietf.org> _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sat Jul 26 07:43: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 HAA04206 for ; Sat, 26 Jul 2003 07:43: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 19gNS1-0000bZ-BY; Sat, 26 Jul 2003 07:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gNRM-0000aW-PN for isis-wg@optimus.ietf.org; Sat, 26 Jul 2003 07:42:20 -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 HAA04184 for ; Sat, 26 Jul 2003 07:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gNRM-0007Z5-00 for isis-wg@ietf.org; Sat, 26 Jul 2003 07:42:20 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19gNRK-0007Yc-00 for isis-wg@ietf.org; Sat, 26 Jul 2003 07:42:19 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h6QBfLp12785; Sat, 26 Jul 2003 13:41:21 +0200 From: Hannes Gredler To: Tony Li Cc: Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Message-ID: <20030726114120.GA12753@juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i 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: Sat, 26 Jul 2003 13:41:21 +0200 On Wed, Jul 23, 2003 at 10:07:50AM -0700, Tony Li wrote: | | | | Which turns out to be difficult in practice. You need the | | multi-topology stuff. Then all you need is a conneted | | path & things | | work. If you have to have working software on supported hardware | | even on just a convex topology before things work, you may never | | get there. | | | Andrew, | | Is the full-blown complexity of the MT stuff necessary? Do we | really need to worry about X forming an adajacnecy with Y and | the full set of protocol interactions? | | If this has to work, we may also never get there. all, given that some customers have already made their mind that they do 1. not want a parallel v6 controlplane [neither MT nor self- restriction to convex topologies] but rather 2. re-use the exisiting v4 control-plane and 3. use a unified tranport [=MPLS] for connecting the v6 clouds together the discussion is IMHO obsolete - actually here we have a nice example how MPLS can make things overall much simpler; i know the v6 bigots do not like that take, but i am afraid in the next years to come there won't be any 6-only networks; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Sun Jul 27 18:05:42 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 SAA26062 for ; Sun, 27 Jul 2003 18:05:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gtdU-0001DY-Sy; Sun, 27 Jul 2003 18:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gtcc-0001D9-ID for isis-wg@optimus.ietf.org; Sun, 27 Jul 2003 18:04:06 -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 SAA25891 for ; Sun, 27 Jul 2003 18:04:01 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gtcZ-0000OQ-00 for isis-wg@ietf.org; Sun, 27 Jul 2003 18:04:03 -0400 Received: from smtp101.mail.sc5.yahoo.com ([216.136.174.139]) by ietf-mx with smtp (Exim 4.12) id 19gtcY-0000ON-00 for isis-wg@ietf.org; Sun, 27 Jul 2003 18:04:02 -0400 Received: from pc-80-194-90-59-hy.blueyonder.co.uk (HELO pchristi) (christian?tena@80.194.90.59 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Jul 2003 22:04:01 -0000 To: pekkas@netcore.fi, isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: [Isis-wg] Feedback on IS-IS Automatic Encapsulation Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F245BFB.18913.10EA90@localhost> Priority: normal In-reply-to: <20030720001328.91783.qmail@web21503.mail.yahoo.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 27 Jul 2003 23:10:51 +0100 Content-Transfer-Encoding: 7BIT Pekka, Do you accept what I said about the usefulness of autoencap in SONET/SDH DCN networks ? If one accepts that this is going to get implemented by the ITU-T folks, how do you think that the IETF ISIS WG should handle it ? Philip On 20 Jul 2003 at 1:13, Philip Christian wrote: > I always felt that automatic encapsulation might be of > less practical use in the Internet > than in the context in which it was thought of, and > that is in SDH/SONET DCN > networks. > > Most Internet routers (more probably all) are > reasonably easily upgradable, and > operators probably don't mind taking a router out of > service for a while in order to > upgrade it to IPv6. The only slight problem that they > have is that because of IS-IS > topological restrictions they shouldn't really forward > any IPv6 traffic in the level-1 area or > level-2 subdomain until all of the routers have been > upgraded, unless they use > something like MT. > > One slight advantage might be to tunnel v6 over v4 to > get past routers that have > hardware forwarding of v4 but software forwarding for > v6, another (compared with 6to4) > is that there is no one explicit gateway. With > automatic encap one can have as many > tunnelling gateways as one wishes and let IS-IS choose > one. > > SDH/SONET networks are different. Some SDH/SONET ADMs > are twenty years old, > and only forward CLNP, and will most likely never be > able to forward IP. Moreover, > restarting or rebooting one of these boxes that has > live traffic on it is simply out of the > question. > > One solution is to use manually configured RFC 3147 > tunnels in order to run IP traffic > through these old ADMs. Most likely many vendors will > offer this option. The problem > with manual tunnels is that in order to achieve any > redundancy one has to run a routing > protocol inside the tunnel. > > The D1-D3 overhead channel in SDH/SONET is only > 192kbps. Moreover many of the > older ADMs may not even be able to forward 192kbps. > One popular ADM can only > forward about 128kbps before it runs out of processing > power. > > This means that if one runs more than about 10 or 12 > tunnels, each with an adjacency > maintained inside it, then one can very quickly run > out of bandwidth just because of all > the hellos and LSPs/LSAs. Each time the topology > changes the LSPs/LSAs get flooded > down all interfaces and all tunnels, and if there are > 10 tunnels then that is a lot of > packets (well more than 192kbps anyway). Pretty soon > adjacencies in the tunnels fail > causing more topology change and eventual complete > instability. > > Automatic encapsulation solves this problem because > there are no tunnel "interfaces" > as such, and only one adjacency to maintain, which is > the original IS-IS one. > > The other beauty of automatic encapsulation is that > the tunnels don't need to be > configured, and then configured again for redundancy. > They just happen automatically. > > For this reason I expect automatic encapsulation to > become quite popular amongst > SHD/SONET vendors. It is really an answer to their > backward compatibility and support > issues, as they can provide IP management to their new > ADMs without needing to > upgrade the old ones, in a scalable and reliable way > and without a lot of configuration > needed. > > This stuff is already out there in ITU-T G.7712 and it > will happen. The question may be > simply whether and how to document it in the IETF. > > I accept many of the comments in your e-mail, however > I feel that the comments on the > pseudo code are not fair. Pseudo code of Dijkstra's > algorithm already appears in ISO > 10589 and in RFC 1195, and is already about four > pages long in those documents. > The changes made compared with the pseudo code in RFC > 1195 really only amount to > a few lines. > > Secondly I have not seen any OSPF or BGB proposal that > has been progressed quite to > this level of functionality or usefulness. I really > don't believe that this can be done with > OSPF as IPv4 is so imbedded in OSPFv2 and IPv6 so > imbedded in OSPFv3. This > approach works in IS-IS only because IS-IS all about > discribing topology independantly > of network layer protocols. I have little knowledge > of BGP. > > Philip Christian > > On 19 Jul 2003 at 10:32, Pekka Savola wrote: > > > Hi, > > > > I was asked to review the IS-IS Automatic > Encapsulation document. > > > > Overall, the specification is of very high quality > one seldom gets to review > > (thanks!), but I do not think this is > architecturally or operationally the > > right way to solve the problem. Therefore I do not > recommend on continuing > > with the work. > > > > subtantive comments > > ------------------- > > > > 1) area of applicability. > > > > It is not clear what the real applicability of this > technique is; or rather, > > it is easy to guess one: being able to implement > automatic IPv6-over-IPv4 > > tunneling mechanism in a routing protocol (similar > have been proposed for > > OSPF, and for BGP multiple times) so that it would > be possible to avoid > > upgrading some of the routers to handle dual > protocols. > > > > The operational community and v6ops working group > has been very hesitant > > about techniques like these, and as of yet, the > v6ops working group has not > > been able to determine any real use cases for > techniques like this. If > > asked at any point (with current knowledge), the > v6ops working group would > > not recommend specifying or publishing this > mechanism. > > > > Instead of real deployment of dual-stack networks, > > we add more code to the routers, and add > hacks/features > > which add significantly to the complexity of the > code and the network. > > > > Note that the multiple topology IS-IS specification > would probably satisfy > > the requirements of partial IPv4/IPv6 deployment in > a simpler manner, if > > really necessary. As an aside, we run an IPv4/IPv6 > backbone, use IS-IS as > > our IPv6 routing protocol, and haven't had *any* > need for even > > multiple-topology IS-IS (and I'm not sure if even > that is needed). > > > > In short, I do not believe this work should be > continued. > > > > 2) operational requirements. > > > > There is always a desire to be able to manage > > and maintain the interfaces of routers. In > particular, it is a strict > > requirement to know of things such as packet/byte > counts, error counts, etc. > > -- using a command-line interface as well as other > management tools such as > > SNMP. > > > > As far as I know, the document does not take stance > on this at all. The > > probable implementation technique is probably some > kind of generic > > tunneling mechanism pseudo-interface which includes > all of this information. > > In this particular case, it might also be desirable > to be able to see > > between which intermediate systems automatic tunnels > have been built, how > > much traffic has been passed through them etc. This > is to be able to see > > whether the implementation is working as expected, > i.e. encapsulating > > towards directions it should, and not encapsulating > to those directions it > > should not. > > > > It is worth considering whether this is something to > mention in the > > specification. > > > > 3) a doubt about specification. > > > > I note that the pseudocode for Dijkstra's new > algorithm appears quite > > complex and is 4 pages long. > > > > I note that there is a possibility of IPR claims on > this subject. This may > > or may not be a significant drawback for the > specification and > > implementation. > > > > 4) two significant technical worries about the > specification. > > > > An IS that also supports manually configured > tunnels will need to > > check that a packet has not arrived over a manual > tunnel in the > > normal way before discarding it. > > > > ==> no way to check that for certain, because there > could be a configured > > (GRE) tunnel between the two systems (without IS-IS > being run over one) as > > it is. > > > > Encapsulated packets should never arrive from > any source other > > than another IS in the same level-1 area or > level-2 subdomain, > > and this MAY then be used as the basis of a > security filter. > > > > ==> how do you know if the source address correspons > to the address of > > another IS? Note that nowhere does it specify which > source address to use > > when encapsulating a packet, only that it must equal > to the identity of the > > IS (whatever that means). > > > > ==> note that in general, automatic tunneling > techniques have been > > considered as a rather dubious area of work, > security-wise. Luckily enough, > > this specification luckily describes some mechanisms > to mitigate this > > threat. > > > > > > > > > > editorial > > --------- > > > > ==> as the length is more than 15 pages, a > table-of-contents is required > > > > ==> the abstract has references (disallowed), and is > too long; perhaps the > > distinction between an abstract/introduction is not > clear. > > > > The IETF is advised of potential intellectual > property rights in > > regard to some or all of the specification > contained in this > > document. For more information consult the online > list for notices > > and/or updates. > > > > ==> this should be removed and moved to a > full-flegded IPR Statement at the > > end, before the Copyright Notice section; like: > > > > Intellectual Property Statement > > > > The IETF takes no position regarding the validity > or scope of any > > intellectual property or other rights that might > be claimed to > > pertain to the implementation or use of the > technology described in > > this document or the extent to which any license > under such rights > > might or might not be available; neither does it > represent that it > > has made any effort to identify any such rights. > Information on the > > IETF's procedures with respect to rights in > standards-track and > > standards-related documentation can be found in > BCP-11. Copies of > > claims of rights made available for publication > and any assurances of > > licenses to be made available, or the result of > an attempt made to > > obtain a general license or permission for the > use of such > > proprietary rights by implementors or users of > this specification can > > be obtained from the IETF Secretariat. > > > > The IETF invites any interested party to bring to > its attention any > > copyrights, patents or patent applications, or > other proprietary > > rights which may cover technology that may be > required to practice > > this standard. Please address the information to > the IETF Executive > > Director. > > > > > > 2.Introduction > > > > ==> s/2./2. / (and similar elsewhere) > > > > 3.The automatic encapsulation mechanism. > > > > ==> s/mechanism./mechanism/ (similar everywhere) > > ==> the title should be written like: "The Automatic > Encapsulation > > Mechanism" > > > > 7.1 Injection of IP and CLNP packets into the > network > > > > An IS that employs automatic encapsulation is > required to > > unencapsulate any incoming packet that is of a > an advertised > > encapsulation mode, and forward the contents. > > > > ==> s/of a/of/ > > ==> still a bit unclear, maybe change s/that is > of/that uses/ ? > > > > 8.References > > > > ==> references need to split to > normative/informative > > > > -- > > Pekka Savola "You each name > yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: > A Clash of Kings > > > > > > > > _______________________________________________ > > 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://uk.messenger.yahoo.com/ > > _______________________________________________ > 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 Sun Jul 27 19:24:37 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 TAA28688 for ; Sun, 27 Jul 2003 19:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gurw-0003ag-P6; Sun, 27 Jul 2003 19:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gura-0003aL-6P for isis-wg@optimus.ietf.org; Sun, 27 Jul 2003 19:23:38 -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 TAA28645 for ; Sun, 27 Jul 2003 19:23:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gurY-00016J-00 for isis-wg@ietf.org; Sun, 27 Jul 2003 19:23:36 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19gurX-00015W-00 for isis-wg@ietf.org; Sun, 27 Jul 2003 19:23:35 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 816B234452; Sun, 27 Jul 2003 16:22:21 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0b.na.procket.com [10.1.7.8]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6RNN0YB003145; Sun, 27 Jul 2003 16:23:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isis-wg] Feedback on IS-IS Automatic Encapsulation Message-ID: Thread-Topic: [Isis-wg] Feedback on IS-IS Automatic Encapsulation Thread-Index: AcNUi0YNbeNq4KcSSri+sc3rN06/jAAClVJw From: "Tony Li" To: , , Content-Transfer-Encoding: quoted-printable 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, 27 Jul 2003 16:23:00 -0700 Content-Transfer-Encoding: quoted-printable | If one accepts that this is going to get implemented by=20 | the ITU-T folks, how do you think=20 | that the IETF ISIS WG should handle it ? If it is outside of our WG charter, then the WG should not handle it at all. So far, I have yet to see a compelling reason to deploy this in the Internet, and I think we should let the ITU folks=20 deal with it. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Jul 28 23:52:06 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 XAA29127 for ; Mon, 28 Jul 2003 23:52:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hLVu-0000lw-0K; Mon, 28 Jul 2003 23:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hLV1-0000lW-3n for isis-wg@optimus.ietf.org; Mon, 28 Jul 2003 23:50:07 -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 XAA29095 for ; Mon, 28 Jul 2003 23:50:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hLUy-0002M1-00 for isis-wg@ietf.org; Mon, 28 Jul 2003 23:50:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hLUy-0002Ll-00 for isis-wg@ietf.org; Mon, 28 Jul 2003 23:50:04 -0400 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6T3nXuD029652 for ; Mon, 28 Jul 2003 20:49:33 -0700 (PDT) Received: from ginsberg-w2k.cisco.com (sjc-vpn4-937.cisco.com [10.21.83.168]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIL05278; Mon, 28 Jul 2003 20:41:51 -0700 (PDT) Message-Id: <4.3.2.7.2.20030728204408.0192b2c0@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@ietf.org From: Les Ginsberg Subject: Re: [Isis-wg] I-D ACTION:draft-ietf-isis-restart-04.txt In-Reply-To: <200307231915.PAA25387@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 28 Jul 2003 20:49:30 -0700 Folks - The correct text for V4 of the draft is now posted. Thank you for your patience. BTW, if in doubt, the correct version can be identified by the dates - which are "July 2003 - January 2004". Here is a summary of the significant changes from V3 to V4. Les V4 of the restart draft, in addition to numerous editorial improvements, includes the following significant changes: 1)In earlier versions acceptance of the holdtime in an IIH/RR by the helper routers was optional. A number of testing situations convinced us that this policy was flawed. It has been replaced by a policy which mandates acceptance of the holdtime in an IIH/RR with some provisions to prevent a router which is constantly restarting from maintaining an adjacency beyond all reason. 2)The addition of a "Restarting Neighbor System ID" to the restart TLV to identify the neighbor to whom the RA bit refers. This is necessary in order to disambiguate RAs in the case that two or more neighbors on a LAN restart at approximately the same time. 3)Noting that timer T3 is not to be used in case of a starting router since it serves no purpose in this case. 4)A loophole in reliability of the LSP DB resync process that could occur when there is a non-restart capable neighbor on a Pt-Pt circuit is closed. 5)State tables have been added At 03:15 PM 7/23/2003 -0400, Internet-Drafts@ietf.org wrote: >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 : Restart signaling for IS-IS > Author(s) : M. Shand, L. Ginsberg > Filename : draft-ietf-isis-restart-04.txt > Pages : 17 > Date : 2003-7-23 > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-04.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-restart-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-isis-restart-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-7-23151154.I-D@ietf.org> _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 14:28:46 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 OAA03831 for ; Tue, 29 Jul 2003 14:28:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZCb-0006uC-9c; Tue, 29 Jul 2003 14:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZCY-0006tv-An for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 14:27:58 -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 OAA03809 for ; Tue, 29 Jul 2003 14:27:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZCV-0000nJ-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 14:27:55 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hZCV-0000nG-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 14:27:55 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 9AD285EE2E2; Tue, 29 Jul 2003 11:27:54 -0700 (PDT) To: Hannes Gredler Cc: Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-reply-to: Mail from Hannes Gredler dated Sat, 26 Jul 2003 13:41:21 +0200 <20030726114120.GA12753@juniper.net> From: Naiming Shen Message-Id: <20030729182754.9AD285EE2E2@prattle.redback.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: Tue, 29 Jul 2003 11:27:54 -0700 ] ] actually here we have a nice example how MPLS can make things ] overall much simpler; ] ] i know the v6 bigots do not like that take, but i am afraid ] in the next years to come there won't be any 6-only networks; i don't think we are talking about 6-only networks. people are mainly interested in dual-mode, transition and isolated single/dual mode islands in the networks. yes, mpls can be a way to bridge the transition(assume those networks want to use mpls in their backbones), but to my knowledge, to bridge some isolated V6 regions(still mostly dual-mode) together, it's so easy to use a couple of tunnels. i agree that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the topologies in the domain, M-ISIS is just another simple way to create such a decoupled topologies. ] /hannes - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 16:58:36 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 QAA08942 for ; Tue, 29 Jul 2003 16:58:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbXl-0005Ar-5p; Tue, 29 Jul 2003 16:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbX6-0005AK-BX for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 16:57:20 -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 QAA08923 for ; Tue, 29 Jul 2003 16:57:14 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbX4-0001l8-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 16:57:18 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 19hbX3-0001l4-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 16:57:17 -0400 Received: from pc-80-194-90-59-hy.blueyonder.co.uk (HELO pchristi) (christian?tena@80.194.90.59 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jul 2003 20:57:16 -0000 To: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F26EF5E.9448.29EC80@localhost> Priority: normal In-reply-to: <20030729182754.9AD285EE2E2@prattle.redback.com> References: Mail from Hannes Gredler dated Sat, 26 Jul 2003 13:41:21 +0200 <20030726114120.GA12753@juniper.net> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 29 Jul 2003 22:04:14 +0100 Content-Transfer-Encoding: 7BIT This is where things get weird. Suppose you have a real topology that goes A-B-C-D-E-F So you make a tunnel from A to F because B-C-D-E don't support v6. Do you want to make a static route to force the v6 packets down the tunnel ? Maybe not, so you run IS-IS over the tunnel as well. Oh but the tunnel had better be more attractive to packets than the real path. Now all your v4 packets go down the tunnel as well even though they don't need to. So you have to run OSPFv3 on the tunnel instead and redistribute to IS-IS at each end or something. I think autoencap is easier :-) Philip On 29 Jul 2003 at 11:27, Naiming Shen wrote: > ] > ] actually here we have a nice example how MPLS can make things > ] overall much simpler; > ] > ] i know the v6 bigots do not like that take, but i am afraid > ] in the next years to come there won't be any 6-only networks; > > i don't think we are talking about 6-only networks. people are > mainly interested in dual-mode, transition and isolated single/dual > mode islands in the networks. yes, mpls can be a way to bridge the > transition(assume those networks want to use mpls in their backbones), > but to my knowledge, to bridge some isolated V6 regions(still mostly > dual-mode) together, it's so easy to use a couple of tunnels. i agree > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the > topologies in the domain, M-ISIS is just another simple way to create > such a decoupled topologies. > > ] /hannes > > - Naiming > > _______________________________________________ > 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 Jul 29 17:13:29 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 RAA09699 for ; Tue, 29 Jul 2003 17:13:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbmG-0006Bh-M4; Tue, 29 Jul 2003 17:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hblk-00065d-Ou for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 17:12:28 -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 RAA09666 for ; Tue, 29 Jul 2003 17:12:22 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbli-0001uD-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:12:26 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 19hblh-0001u9-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:12:25 -0400 Received: from pc-80-194-90-59-hy.blueyonder.co.uk (HELO pchristi) (christian?tena@80.194.90.59 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jul 2003 21:12:24 -0000 To: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F26F2E3.9628.37AC36@localhost> Priority: normal In-reply-to: <3F26EF5E.9448.29EC80@localhost> References: <20030729182754.9AD285EE2E2@prattle.redback.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 29 Jul 2003 22:19:15 +0100 Content-Transfer-Encoding: 7BIT Oh yes, I forgot that the MT spf can ignore the IPv4 nodes and therefore only include the tunnel as it is a direct adjacency between two nodes that are in the MT. But, you still have to stop legacy IS-IS from using the tunnel. What if C or D blow up ? Presumably the tunnel will go another way, but its metric won't change to reflect the new route. What if the tunnel now becomes more attractive to v4 than the backup path? Philip On 29 Jul 2003 at 22:04, christian_tena@yahoo.co.uk wrote: > This is where things get weird. > > Suppose you have a real topology that goes A-B-C-D-E-F > > So you make a tunnel from A to F because B-C-D-E don't support v6. > > Do you want to make a static route to force the v6 packets down the tunnel ? > > Maybe not, so you run IS-IS over the tunnel as well. > > Oh but the tunnel had better be more attractive to packets than the real path. > > Now all your v4 packets go down the tunnel as well even though they don't need to. > > So you have to run OSPFv3 on the tunnel instead and redistribute to IS-IS at each end > or something. > > I think autoencap is easier :-) > > Philip > > > > On 29 Jul 2003 at 11:27, Naiming Shen wrote: > > > ] > > ] actually here we have a nice example how MPLS can make things > > ] overall much simpler; > > ] > > ] i know the v6 bigots do not like that take, but i am afraid > > ] in the next years to come there won't be any 6-only networks; > > > > i don't think we are talking about 6-only networks. people are > > mainly interested in dual-mode, transition and isolated single/dual > > mode islands in the networks. yes, mpls can be a way to bridge the > > transition(assume those networks want to use mpls in their backbones), > > but to my knowledge, to bridge some isolated V6 regions(still mostly > > dual-mode) together, it's so easy to use a couple of tunnels. i agree > > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the > > topologies in the domain, M-ISIS is just another simple way to create > > such a decoupled topologies. > > > > ] /hannes > > > > - Naiming > > > > _______________________________________________ > > 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 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 17:15: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 RAA09799 for ; Tue, 29 Jul 2003 17:15: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 19hboE-0006IR-7R; Tue, 29 Jul 2003 17: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 19hbno-0006Hk-Fx for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 17:14:36 -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 RAA09766 for ; Tue, 29 Jul 2003 17:14:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbnm-0001vj-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:14:34 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hbnl-0001vg-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:14:33 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 21BEFFD224; Tue, 29 Jul 2003 14:14:30 -0700 (PDT) To: christian_tena@yahoo.co.uk Cc: Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-reply-to: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 22:04:14 BST <3F26EF5E.9448.29EC80@localhost> From: Naiming Shen Message-Id: <20030729211430.21BEFFD224@prattle.redback.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: Tue, 29 Jul 2003 14:14:30 -0700 ] This is where things get weird. ] ] Suppose you have a real topology that goes A-B-C-D-E-F ] ] So you make a tunnel from A to F because B-C-D-E don't support v6. ] ] Do you want to make a static route to force the v6 packets down the tunnel ? ] ] Maybe not, so you run IS-IS over the tunnel as well. ] ] Oh but the tunnel had better be more attractive to packets than the real pat h. ] ] Now all your v4 packets go down the tunnel as well even though they don't ne ed to. ] Hur? i think you're talking about tunnels with "normal" IGP, but i was talking about tunnels with M-ISIS. with M-ISIS, you just "label" this tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network does not even know such a tunnel link exist. this is equivalent to use ISIS for ipv4, but use ospfv3 on the tunnel links. hope this helps. thanks. ] So you have to run OSPFv3 on the tunnel instead and redistribute to IS-IS at each end ] or something. ] ] I think autoencap is easier :-) ] ] Philip ] ] ] ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: ] ] > ] ] > ] actually here we have a nice example how MPLS can make things ] > ] overall much simpler; ] > ] ] > ] i know the v6 bigots do not like that take, but i am afraid ] > ] in the next years to come there won't be any 6-only networks; ] > ] > i don't think we are talking about 6-only networks. people are ] > mainly interested in dual-mode, transition and isolated single/dual ] > mode islands in the networks. yes, mpls can be a way to bridge the ] > transition(assume those networks want to use mpls in their backbones), ] > but to my knowledge, to bridge some isolated V6 regions(still mostly ] > dual-mode) together, it's so easy to use a couple of tunnels. i agree ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the ] > topologies in the domain, M-ISIS is just another simple way to create ] > such a decoupled topologies. ] > ] > ] /hannes ] > ] > - Naiming ] > ] > _______________________________________________ ] > Isis-wg mailing list ] > Isis-wg@ietf.org ] > https://www1.ietf.org/mailman/listinfo/isis-wg ] ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 17:23:28 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 RAA10108 for ; Tue, 29 Jul 2003 17:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbvw-0006jn-Qg; Tue, 29 Jul 2003 17:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbv5-0006fR-58 for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 17:22:07 -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 RAA10036 for ; Tue, 29 Jul 2003 17:22:01 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbv2-0001zb-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:22:04 -0400 Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by ietf-mx with smtp (Exim 4.12) id 19hbv2-0001zY-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:22:04 -0400 Received: from pc-80-194-90-59-hy.blueyonder.co.uk (HELO pchristi) (christian?tena@80.194.90.59 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jul 2003 21:22:02 -0000 To: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F26F524.8945.407991@localhost> Priority: normal In-reply-to: <20030729211430.21BEFFD224@prattle.redback.com> References: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 22:04:14 BST <3F26EF5E.9448.29EC80@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 29 Jul 2003 22:28:52 +0100 Content-Transfer-Encoding: 7BIT Yeah, I messed up. But..... Suppose you label this tunnel as IPv6 only. How does the legacy IS-IS (not MT capable) know to ignore it ? It's still an IS-IS adjacency as far as legacy IS-IS is concerned. Or isn't it ? Philip On 29 Jul 2003 at 14:14, Naiming Shen wrote: > ] This is where things get weird. > ] > ] Suppose you have a real topology that goes A-B-C-D-E-F > ] > ] So you make a tunnel from A to F because B-C-D-E don't support v6. > ] > ] Do you want to make a static route to force the v6 packets down the tunnel ? > ] > ] Maybe not, so you run IS-IS over the tunnel as well. > ] > ] Oh but the tunnel had better be more attractive to packets than the real pat > h. > ] > ] Now all your v4 packets go down the tunnel as well even though they don't ne > ed to. > ] > > Hur? i think you're talking about tunnels with "normal" IGP, but i was > talking about tunnels with M-ISIS. with M-ISIS, you just "label" this > tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network > does not even know such a tunnel link exist. this is equivalent to use > ISIS for ipv4, but use ospfv3 on the tunnel links. > > hope this helps. > > thanks. > > ] So you have to run OSPFv3 on the tunnel instead and redistribute to IS-IS at > each end > ] or something. > ] > ] I think autoencap is easier :-) > ] > ] Philip > ] > ] > ] > ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: > ] > ] > ] > ] > ] actually here we have a nice example how MPLS can make things > ] > ] overall much simpler; > ] > ] > ] > ] i know the v6 bigots do not like that take, but i am afraid > ] > ] in the next years to come there won't be any 6-only networks; > ] > > ] > i don't think we are talking about 6-only networks. people are > ] > mainly interested in dual-mode, transition and isolated single/dual > ] > mode islands in the networks. yes, mpls can be a way to bridge the > ] > transition(assume those networks want to use mpls in their backbones), > ] > but to my knowledge, to bridge some isolated V6 regions(still mostly > ] > dual-mode) together, it's so easy to use a couple of tunnels. i agree > ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the > ] > topologies in the domain, M-ISIS is just another simple way to create > ] > such a decoupled topologies. > ] > > ] > ] /hannes > ] > > ] > - Naiming > ] > > ] > _______________________________________________ > ] > Isis-wg mailing list > ] > Isis-wg@ietf.org > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > ] > ] > > - Naiming > > _______________________________________________ > 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 Jul 29 17:27:28 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 RAA10321 for ; Tue, 29 Jul 2003 17:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbzp-0006t8-0M; Tue, 29 Jul 2003 17:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbz0-0006sL-FW for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 17:26:10 -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 RAA10266 for ; Tue, 29 Jul 2003 17:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbyy-00022Q-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:26:08 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hbyx-00022N-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:26:07 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 1785BFD227; Tue, 29 Jul 2003 14:26:07 -0700 (PDT) To: christian_tena@yahoo.co.uk Cc: Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-reply-to: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 22:19:15 BST <3F26F2E3.9628.37AC36@localhost> From: Naiming Shen Message-Id: <20030729212607.1785BFD227@prattle.redback.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: Tue, 29 Jul 2003 14:26:07 -0700 ] Oh yes, I forgot that the MT spf can ignore the IPv4 nodes and therefore onl y include ] the tunnel as it is a direct adjacency between two nodes that are in the MT. ] ] But, you still have to stop legacy IS-IS from using the tunnel. ] for the MT extension, legacy IS-IS, which is ipv4 unicast topology, does not know about this ipv6-only link. ] What if C or D blow up ? ] ] Presumably the tunnel will go another way, but its metric won't change to re flect the new ] route. if C or D is the only path for the tunnel, then there is no connection anyway, otherwise, IGP should reroute. if you only have a tunnel to connect two isolated islands, metric does not play any role here. this is no difference from using ISIS for ipv4 and ospfv3 for ipv6 case. usually using IP tunnel as IGP link can cause unexpected result if used inproperly. but for this application, the tunnel itself and IGP link belong to different address family and there is no dependancy there. ] ] What if the tunnel now becomes more attractive to v4 than the backup path? same as above, v4 spf just does not know there is such a tunnel link. (unless operators intentionally make this tunnel to run both ipv6 and ipv4 backup(v4 metric really high comparing to hop-by-hop)). thanks. ] ] Philip ] ] On 29 Jul 2003 at 22:04, christian_tena@yahoo.co.uk wrote: ] ] > This is where things get weird. ] > ] > Suppose you have a real topology that goes A-B-C-D-E-F ] > ] > So you make a tunnel from A to F because B-C-D-E don't support v6. ] > ] > Do you want to make a static route to force the v6 packets down the tunnel ? ] > ] > Maybe not, so you run IS-IS over the tunnel as well. ] > ] > Oh but the tunnel had better be more attractive to packets than the real p ath. ] > ] > Now all your v4 packets go down the tunnel as well even though they don't need to. ] > ] > So you have to run OSPFv3 on the tunnel instead and redistribute to IS-IS at each end ] > or something. ] > ] > I think autoencap is easier :-) ] > ] > Philip ] > ] > ] > ] > On 29 Jul 2003 at 11:27, Naiming Shen wrote: ] > ] > > ] ] > > ] actually here we have a nice example how MPLS can make things ] > > ] overall much simpler; ] > > ] ] > > ] i know the v6 bigots do not like that take, but i am afraid ] > > ] in the next years to come there won't be any 6-only networks; ] > > ] > > i don't think we are talking about 6-only networks. people are ] > > mainly interested in dual-mode, transition and isolated single/dual ] > > mode islands in the networks. yes, mpls can be a way to bridge the ] > > transition(assume those networks want to use mpls in their backbones), ] > > but to my knowledge, to bridge some isolated V6 regions(still mostly ] > > dual-mode) together, it's so easy to use a couple of tunnels. i agree ] > > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the ] > > topologies in the domain, M-ISIS is just another simple way to create ] > > such a decoupled topologies. ] > > ] > > ] /hannes ] > > ] > > - Naiming ] > > ] > > _______________________________________________ ] > > 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 ] ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 17:42:32 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 RAA10817 for ; Tue, 29 Jul 2003 17:42:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcEL-0007kp-8j; Tue, 29 Jul 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcDs-0007kW-3N for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 17:41:32 -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 RAA10781 for ; Tue, 29 Jul 2003 17:41:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcDp-00029T-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:41:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hcDo-00029Q-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:41:28 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 3F0CD766C8E; Tue, 29 Jul 2003 14:41:28 -0700 (PDT) To: christian_tena@yahoo.co.uk Cc: Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-reply-to: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 22:28:52 BST <3F26F524.8945.407991@localhost> From: Naiming Shen Message-Id: <20030729214128.3F0CD766C8E@prattle.redback.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: Tue, 29 Jul 2003 14:41:28 -0700 ] Yeah, I messed up. ] But..... ] Suppose you label this tunnel as IPv6 only. ] How does the legacy IS-IS (not MT capable) know to ignore it ? if the tunnel is ipv6-only link, then both routers at tunnel ends has to be M-ISIS aware. and both routers send LSPs contain MT IS adjacency records, other legacy routers do not understand those TLVs, thus they don't even know this tunnel. thanks. ] ] It's still an IS-IS adjacency as far as legacy IS-IS is concerned. Or isn't it ? ] ] Philip ] ] On 29 Jul 2003 at 14:14, Naiming Shen wrote: ] ] > ] This is where things get weird. ] > ] ] > ] Suppose you have a real topology that goes A-B-C-D-E-F ] > ] ] > ] So you make a tunnel from A to F because B-C-D-E don't support v6. ] > ] ] > ] Do you want to make a static route to force the v6 packets down the tun nel ? ] > ] ] > ] Maybe not, so you run IS-IS over the tunnel as well. ] > ] ] > ] Oh but the tunnel had better be more attractive to packets than the rea l pat ] > h. ] > ] ] > ] Now all your v4 packets go down the tunnel as well even though they don 't ne ] > ed to. ] > ] ] > ] > Hur? i think you're talking about tunnels with "normal" IGP, but i was ] > talking about tunnels with M-ISIS. with M-ISIS, you just "label" this ] > tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network ] > does not even know such a tunnel link exist. this is equivalent to use ] > ISIS for ipv4, but use ospfv3 on the tunnel links. ] > ] > hope this helps. ] > ] > thanks. ] > ] > ] So you have to run OSPFv3 on the tunnel instead and redistribute to IS- IS at ] > each end ] > ] or something. ] > ] ] > ] I think autoencap is easier :-) ] > ] ] > ] Philip ] > ] ] > ] ] > ] ] > ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: ] > ] ] > ] > ] ] > ] > ] actually here we have a nice example how MPLS can make things ] > ] > ] overall much simpler; ] > ] > ] ] > ] > ] i know the v6 bigots do not like that take, but i am afraid ] > ] > ] in the next years to come there won't be any 6-only networks; ] > ] > ] > ] > i don't think we are talking about 6-only networks. people are ] > ] > mainly interested in dual-mode, transition and isolated single/dual ] > ] > mode islands in the networks. yes, mpls can be a way to bridge the ] > ] > transition(assume those networks want to use mpls in their backbones) , ] > ] > but to my knowledge, to bridge some isolated V6 regions(still mostly ] > ] > dual-mode) together, it's so easy to use a couple of tunnels. i agree ] > ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple t he ] > ] > topologies in the domain, M-ISIS is just another simple way to create ] > ] > such a decoupled topologies. ] > ] > ] > ] > ] /hannes ] > ] > ] > ] > - Naiming ] > ] > ] > ] > _______________________________________________ ] > ] > Isis-wg mailing list ] > ] > Isis-wg@ietf.org ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg ] > ] ] > ] ] > ] > - Naiming ] > ] > _______________________________________________ ] > Isis-wg mailing list ] > Isis-wg@ietf.org ] > https://www1.ietf.org/mailman/listinfo/isis-wg ] ] - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 17:58:29 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 RAA11299 for ; Tue, 29 Jul 2003 17:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcTo-00008X-Vb; Tue, 29 Jul 2003 17:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcT0-000087-Qt for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 17:57:10 -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 RAA11235 for ; Tue, 29 Jul 2003 17:57:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcSy-0002Hz-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:57:08 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hcSx-0002Hu-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 17:57:07 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 14:56:34 -0700 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TLuVuD003734; Tue, 29 Jul 2003 14:56:31 -0700 (PDT) Received: from jlearman-w2k02.cisco.com (dhcp-64-102-83-254.cisco.com [64.102.83.254]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AIU95611; Tue, 29 Jul 2003 14:56:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20030729172517.00b9d8b8@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: christian_tena@yahoo.co.uk From: Jeff Learman Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Cc: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org In-Reply-To: <3F26EF5E.9448.29EC80@localhost> References: <20030729182754.9AD285EE2E2@prattle.redback.com> <20030726114120.GA12753@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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, 29 Jul 2003 17:56:27 -0400 Philip, if I understand it correctly, you needn't run ISIS on an MPLS tunnel, and it's dynamic anyway. No static routes are needed. The MPLS tunnel needn't be represented as a link in the topology. Frankly, if you treated every label path as a link, you'd have a serious scalability problem! I'm talking "Basic MPLS". Other applications may be different. All traffic from A to F gets tunneled, regardless of IPV6 or IPV4, no problem. The MPLS tunnel isn't treated by the routing protocols like it's a link, and you don't run ISIS over it. MPLS just provides a magic carpet for those IPV6 packets to float over the IPV4 network on ;) The information from routing protocols causes the nodes to set up the label network, and after that, each node locally makes the decision whether to use a label path to forward a packet, rather than native IP. Interestingly enough, in an IPV4-only situation, these decisions don't need to be made consistently by all routers -- if some router neglects to tag a packet and IP-routes it, the next one down the line can still tag it if it wants or not, and so on. The only problem where you'd come into any difficulty is Penultimate Hop Popping. This is an optimization where the penultimate (second- to-last) node in a label path pops the tag in order to even the load between the edge and next-to-edge routers. If you're using PHP but the penultimate node in the label path isn't IPV6, you'd have trouble. Presumably the IPV6 MPLS folks are well aware of this and have some mechanism to avoid this problem, it's beyond my area of incompetence. ;) The scenario I'm discussing is the standard Service Provider model providing IPV6 services to customers, and running Basic MPLS in their core network on IPV4 routers. If you want more flexibility on where you're running IPV6, perhaps you'd need MT or auto-encap. My head hurts when I think about MPLS in anything other than the standard deployments; I don't understand it well enough to extrapolate. Perhaps an MPLS guru can shed more light on whether there are limitations on what it can do to bridge IPV4 seas between arbitrary IPV6 islands. But I can't think of any reason it wouldn't "just work", other than the PHP thing. Now, maybe I'm all wet on my (admittedly limited) understanding of MPLS. But as I see it, you have no need to run a separate routing protocol or even use M-ISIS, as long as you have MPLS enabled in the whole domain (or at least, in any IPV4 core, including any boundary IPV6 nodes). Or maybe there isn't a solution to the PHP problem. Regards, Jeff Disclaimer: I don't work on ISIS at Cisco, and I don't represent Cisco in these discussions. At 05:04 PM 7/29/2003, christian_tena@yahoo.co.uk wrote: >This is where things get weird. > >Suppose you have a real topology that goes A-B-C-D-E-F > >So you make a tunnel from A to F because B-C-D-E don't support v6. > >Do you want to make a static route to force the v6 packets down the tunnel ? > >Maybe not, so you run IS-IS over the tunnel as well. > >Oh but the tunnel had better be more attractive to packets than the real path. > >Now all your v4 packets go down the tunnel as well even though they don't need to. > >So you have to run OSPFv3 on the tunnel instead and redistribute to IS-IS at each end >or something. > >I think autoencap is easier :-) > >Philip > > > >On 29 Jul 2003 at 11:27, Naiming Shen wrote: > >> ] >> ] actually here we have a nice example how MPLS can make things >> ] overall much simpler; >> ] >> ] i know the v6 bigots do not like that take, but i am afraid >> ] in the next years to come there won't be any 6-only networks; >> >> i don't think we are talking about 6-only networks. people are >> mainly interested in dual-mode, transition and isolated single/dual >> mode islands in the networks. yes, mpls can be a way to bridge the >> transition(assume those networks want to use mpls in their backbones), >> but to my knowledge, to bridge some isolated V6 regions(still mostly >> dual-mode) together, it's so easy to use a couple of tunnels. i agree >> that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple the >> topologies in the domain, M-ISIS is just another simple way to create >> such a decoupled topologies. >> >> ] /hannes >> >> - Naiming >> >> _______________________________________________ >> 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 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 18:16:32 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 SAA13138 for ; Tue, 29 Jul 2003 18:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hclF-0001UX-VQ; Tue, 29 Jul 2003 18:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hckI-0001Tv-F1 for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 18:15:02 -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 SAA12989 for ; Tue, 29 Jul 2003 18:14:55 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hckF-0002TC-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 18:14:59 -0400 Received: from smtp101.mail.sc5.yahoo.com ([216.136.174.139]) by ietf-mx with smtp (Exim 4.12) id 19hckE-0002T9-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 18:14:59 -0400 Received: from pc-80-194-90-59-hy.blueyonder.co.uk (HELO pchristi) (christian?tena@80.194.90.59 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 29 Jul 2003 22:14:58 -0000 To: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F270190.30785.710064@localhost> Priority: normal In-reply-to: <20030729214128.3F0CD766C8E@prattle.redback.com> References: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 22:28:52 BST <3F26F524.8945.407991@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 29 Jul 2003 23:21:52 +0100 Content-Transfer-Encoding: 7BIT Legacy routers will ignore the TLVs, but they won't ignore the fact that there is an IS-IS topology, and they will attempt to route over it. You need that basic IS-IS topology in order to flood the MT TLVs, but you can't stop legacy IS-IS viewing it as a usable topology. Even if the end points of the tunnel are M-ISIS aware, they still flood the LSPs onwards, and the non M-ISIS aware routers still see the adjacencies and plot a route through them, even though they don't understand the TLVs. I have seen IP routers plot a route (and attempt to forward traffic) through an OSI-only router, and vice versa. They are supposed to do that. As far as SPF is concerned in a legacy router, what is the difference between an MT aware, IPv6 router, and an OSI router with some extra TLVs that it doesn't understand ? No difference, it will plot the route. Philip On 29 Jul 2003 at 14:41, Naiming Shen wrote: > ] Yeah, I messed up. > ] But..... > ] Suppose you label this tunnel as IPv6 only. > ] How does the legacy IS-IS (not MT capable) know to ignore it ? > > if the tunnel is ipv6-only link, then both routers at tunnel ends has > to be M-ISIS aware. and both routers send LSPs contain MT IS adjacency > records, other legacy routers do not understand those TLVs, thus they > don't even know this tunnel. > > thanks. > > ] > ] It's still an IS-IS adjacency as far as legacy IS-IS is concerned. Or isn't > it ? > ] > ] Philip > ] > ] On 29 Jul 2003 at 14:14, Naiming Shen wrote: > ] > ] > ] This is where things get weird. > ] > ] > ] > ] Suppose you have a real topology that goes A-B-C-D-E-F > ] > ] > ] > ] So you make a tunnel from A to F because B-C-D-E don't support v6. > ] > ] > ] > ] Do you want to make a static route to force the v6 packets down the tun > nel ? > ] > ] > ] > ] Maybe not, so you run IS-IS over the tunnel as well. > ] > ] > ] > ] Oh but the tunnel had better be more attractive to packets than the rea > l pat > ] > h. > ] > ] > ] > ] Now all your v4 packets go down the tunnel as well even though they don > 't ne > ] > ed to. > ] > ] > ] > > ] > Hur? i think you're talking about tunnels with "normal" IGP, but i was > ] > talking about tunnels with M-ISIS. with M-ISIS, you just "label" this > ] > tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network > ] > does not even know such a tunnel link exist. this is equivalent to use > ] > ISIS for ipv4, but use ospfv3 on the tunnel links. > ] > > ] > hope this helps. > ] > > ] > thanks. > ] > > ] > ] So you have to run OSPFv3 on the tunnel instead and redistribute to IS- > IS at > ] > each end > ] > ] or something. > ] > ] > ] > ] I think autoencap is easier :-) > ] > ] > ] > ] Philip > ] > ] > ] > ] > ] > ] > ] > ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: > ] > ] > ] > ] > ] > ] > ] > ] actually here we have a nice example how MPLS can make things > ] > ] > ] overall much simpler; > ] > ] > ] > ] > ] > ] i know the v6 bigots do not like that take, but i am afraid > ] > ] > ] in the next years to come there won't be any 6-only networks; > ] > ] > > ] > ] > i don't think we are talking about 6-only networks. people are > ] > ] > mainly interested in dual-mode, transition and isolated single/dual > ] > ] > mode islands in the networks. yes, mpls can be a way to bridge the > ] > ] > transition(assume those networks want to use mpls in their backbones) > , > ] > ] > but to my knowledge, to bridge some isolated V6 regions(still mostly > ] > ] > dual-mode) together, it's so easy to use a couple of tunnels. i agree > ] > ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decouple t > he > ] > ] > topologies in the domain, M-ISIS is just another simple way to create > ] > ] > such a decoupled topologies. > ] > ] > > ] > ] > ] /hannes > ] > ] > > ] > ] > - Naiming > ] > ] > > ] > ] > _______________________________________________ > ] > ] > Isis-wg mailing list > ] > ] > Isis-wg@ietf.org > ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > ] > ] > ] > ] > ] > > ] > - Naiming > ] > > ] > _______________________________________________ > ] > Isis-wg mailing list > ] > Isis-wg@ietf.org > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > ] > ] > > - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Jul 29 18:37:31 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 SAA13720 for ; Tue, 29 Jul 2003 18:37:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hd5Y-0002GP-WC; Tue, 29 Jul 2003 18:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hd4y-0002F4-Nd for isis-wg@optimus.ietf.org; Tue, 29 Jul 2003 18:36:24 -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 SAA13653 for ; Tue, 29 Jul 2003 18:36:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hd4v-0002aU-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 18:36:21 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hd4u-0002aQ-00 for isis-wg@ietf.org; Tue, 29 Jul 2003 18:36:20 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 8FA12870808; Tue, 29 Jul 2003 15:34:52 -0700 (PDT) To: christian_tena@yahoo.co.uk Cc: Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-reply-to: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 23:21:52 BST <3F270190.30785.710064@localhost> From: Naiming Shen Message-Id: <20030729223452.8FA12870808@prattle.redback.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: Tue, 29 Jul 2003 15:34:52 -0700 pls read the MT draft. other than that, i should only add that the main purpose of M-ISIS is not letting legacy ipv4 routers 'see' any other topologies. in the case of ipv4 and ipv6, just think of the M-ISIS as isis running on ipv4, ospfv3 running on ipv6. thanks. ] Legacy routers will ignore the TLVs, but they won't ignore the fact that the re is an IS-IS ] topology, and they will attempt to route over it. ] ] You need that basic IS-IS topology in order to flood the MT TLVs, but you ca n't stop ] legacy IS-IS viewing it as a usable topology. ] ] Even if the end points of the tunnel are M-ISIS aware, they still flood the LSPs onwards, ] and the non M-ISIS aware routers still see the adjacencies and plot a route through ] them, even though they don't understand the TLVs. ] ] I have seen IP routers plot a route (and attempt to forward traffic) through an OSI-only ] router, and vice versa. They are supposed to do that. ] ] As far as SPF is concerned in a legacy router, what is the difference betwee n an MT ] aware, IPv6 router, and an OSI router with some extra TLVs that it doesn't u nderstand ? ] ] No difference, it will plot the route. ] ] Philip ] ] On 29 Jul 2003 at 14:41, Naiming Shen wrote: ] ] > ] Yeah, I messed up. ] > ] But..... ] > ] Suppose you label this tunnel as IPv6 only. ] > ] How does the legacy IS-IS (not MT capable) know to ignore it ? ] > ] > if the tunnel is ipv6-only link, then both routers at tunnel ends has ] > to be M-ISIS aware. and both routers send LSPs contain MT IS adjacency ] > records, other legacy routers do not understand those TLVs, thus they ] > don't even know this tunnel. ] > ] > thanks. ] > ] > ] ] > ] It's still an IS-IS adjacency as far as legacy IS-IS is concerned. Or isn't ] > it ? ] > ] ] > ] Philip ] > ] ] > ] On 29 Jul 2003 at 14:14, Naiming Shen wrote: ] > ] ] > ] > ] This is where things get weird. ] > ] > ] ] > ] > ] Suppose you have a real topology that goes A-B-C-D-E-F ] > ] > ] ] > ] > ] So you make a tunnel from A to F because B-C-D-E don't support v6. ] > ] > ] ] > ] > ] Do you want to make a static route to force the v6 packets down th e tun ] > nel ? ] > ] > ] ] > ] > ] Maybe not, so you run IS-IS over the tunnel as well. ] > ] > ] ] > ] > ] Oh but the tunnel had better be more attractive to packets than th e rea ] > l pat ] > ] > h. ] > ] > ] ] > ] > ] Now all your v4 packets go down the tunnel as well even though the y don ] > 't ne ] > ] > ed to. ] > ] > ] ] > ] > ] > ] > Hur? i think you're talking about tunnels with "normal" IGP, but i wa s ] > ] > talking about tunnels with M-ISIS. with M-ISIS, you just "label" this ] > ] > tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network ] > ] > does not even know such a tunnel link exist. this is equivalent to us e ] > ] > ISIS for ipv4, but use ospfv3 on the tunnel links. ] > ] > ] > ] > hope this helps. ] > ] > ] > ] > thanks. ] > ] > ] > ] > ] So you have to run OSPFv3 on the tunnel instead and redistribute t o IS- ] > IS at ] > ] > each end ] > ] > ] or something. ] > ] > ] ] > ] > ] I think autoencap is easier :-) ] > ] > ] ] > ] > ] Philip ] > ] > ] ] > ] > ] ] > ] > ] ] > ] > ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: ] > ] > ] ] > ] > ] > ] ] > ] > ] > ] actually here we have a nice example how MPLS can make things ] > ] > ] > ] overall much simpler; ] > ] > ] > ] ] > ] > ] > ] i know the v6 bigots do not like that take, but i am afraid ] > ] > ] > ] in the next years to come there won't be any 6-only networks; ] > ] > ] > ] > ] > ] > i don't think we are talking about 6-only networks. people are ] > ] > ] > mainly interested in dual-mode, transition and isolated single/d ual ] > ] > ] > mode islands in the networks. yes, mpls can be a way to bridge t he ] > ] > ] > transition(assume those networks want to use mpls in their backb ones) ] > , ] > ] > ] > but to my knowledge, to bridge some isolated V6 regions(still mo stly ] > ] > ] > dual-mode) together, it's so easy to use a couple of tunnels. i agree ] > ] > ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decou ple t ] > he ] > ] > ] > topologies in the domain, M-ISIS is just another simple way to c reate ] > ] > ] > such a decoupled topologies. ] > ] > ] > ] > ] > ] > ] /hannes ] > ] > ] > ] > ] > ] > - Naiming ] > ] > ] > ] > ] > ] > _______________________________________________ ] > ] > ] > Isis-wg mailing list ] > ] > ] > Isis-wg@ietf.org ] > ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg ] > ] > ] ] > ] > ] ] > ] > ] > ] > - Naiming ] > ] > ] > ] > _______________________________________________ ] > ] > Isis-wg mailing list ] > ] > Isis-wg@ietf.org ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg ] > ] ] > ] ] > ] > - Naiming ] ] ] ] _______________________________________________ ] Isis-wg mailing list ] Isis-wg@ietf.org ] https://www1.ietf.org/mailman/listinfo/isis-wg - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 30 05:15:51 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 FAA24615 for ; Wed, 30 Jul 2003 05:15:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn2y-0001Xk-V0; Wed, 30 Jul 2003 05:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hn2X-0001XM-7G for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 05:14:35 -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 FAA24594 for ; Wed, 30 Jul 2003 05:14:27 -0400 (EDT) From: christian_tena@yahoo.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hn2T-0006Cq-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 05:14:29 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 19hn2S-0006Cn-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 05:14:28 -0400 Received: from wireless05.one2one.net (HELO pchristi) (christian?tena@149.254.200.197 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Jul 2003 09:14:21 -0000 To: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F279C02.28091.3BA831@localhost> Priority: normal In-reply-to: <20030729223452.8FA12870808@prattle.redback.com> References: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 23:21:52 BST <3F270190.30785.710064@localhost> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 30 Jul 2003 10:20:50 +0100 Content-Transfer-Encoding: 7BIT I have read the draft (again). Take this network A-B-C-D-E-F A and F are MT aware. So we configure a GRE/IPv4 tunnel from A to F. In order for A and F to have an MT#2 adjacency over that tunnel, they have to have an ordinary IS-IS adjacency over the tunnel, and declare themselves adjacent to each other in their normal LSPs. Then they add on the MT stuff as TLVs on top of this new adjacency. Right or wrong ? If that is right, then, if a legacy IS-IS router somewhere else in the network gets the normal LSP then it will consider the tunnel to be a usable route. Suppose that B gets LSPs from A and F. B might think that its best route to F is actually B-A-F and so will send all packets back to A. The tunnel will I guess flap up and down if this happens as the GRE packets won't get through when the tunnel is "up", but will when it's "down". Sorry to be a pain, but I really think I'm right on this. If not then I'll have to eat humble pie (again) :-) Philip On 29 Jul 2003 at 15:34, Naiming Shen wrote: > > pls read the MT draft. other than that, i should only add that the main > purpose of M-ISIS is not letting legacy ipv4 routers 'see' any other > topologies. in the case of ipv4 and ipv6, just think of the M-ISIS as > isis running on ipv4, ospfv3 running on ipv6. > > thanks. > > ] Legacy routers will ignore the TLVs, but they won't ignore the fact that the > re is an IS-IS > ] topology, and they will attempt to route over it. > ] > ] You need that basic IS-IS topology in order to flood the MT TLVs, but you ca > n't stop > ] legacy IS-IS viewing it as a usable topology. > ] > ] Even if the end points of the tunnel are M-ISIS aware, they still flood the > LSPs onwards, > ] and the non M-ISIS aware routers still see the adjacencies and plot a route > through > ] them, even though they don't understand the TLVs. > ] > ] I have seen IP routers plot a route (and attempt to forward traffic) through > an OSI-only > ] router, and vice versa. They are supposed to do that. > ] > ] As far as SPF is concerned in a legacy router, what is the difference betwee > n an MT > ] aware, IPv6 router, and an OSI router with some extra TLVs that it doesn't u > nderstand ? > ] > ] No difference, it will plot the route. > ] > ] Philip > ] > ] On 29 Jul 2003 at 14:41, Naiming Shen wrote: > ] > ] > ] Yeah, I messed up. > ] > ] But..... > ] > ] Suppose you label this tunnel as IPv6 only. > ] > ] How does the legacy IS-IS (not MT capable) know to ignore it ? > ] > > ] > if the tunnel is ipv6-only link, then both routers at tunnel ends has > ] > to be M-ISIS aware. and both routers send LSPs contain MT IS adjacency > ] > records, other legacy routers do not understand those TLVs, thus they > ] > don't even know this tunnel. > ] > > ] > thanks. > ] > > ] > ] > ] > ] It's still an IS-IS adjacency as far as legacy IS-IS is concerned. Or > isn't > ] > it ? > ] > ] > ] > ] Philip > ] > ] > ] > ] On 29 Jul 2003 at 14:14, Naiming Shen wrote: > ] > ] > ] > ] > ] This is where things get weird. > ] > ] > ] > ] > ] > ] Suppose you have a real topology that goes A-B-C-D-E-F > ] > ] > ] > ] > ] > ] So you make a tunnel from A to F because B-C-D-E don't support v6. > ] > ] > ] > ] > ] > ] Do you want to make a static route to force the v6 packets down th > e tun > ] > nel ? > ] > ] > ] > ] > ] > ] Maybe not, so you run IS-IS over the tunnel as well. > ] > ] > ] > ] > ] > ] Oh but the tunnel had better be more attractive to packets than th > e rea > ] > l pat > ] > ] > h. > ] > ] > ] > ] > ] > ] Now all your v4 packets go down the tunnel as well even though the > y don > ] > 't ne > ] > ] > ed to. > ] > ] > ] > ] > ] > > ] > ] > Hur? i think you're talking about tunnels with "normal" IGP, but i wa > s > ] > ] > talking about tunnels with M-ISIS. with M-ISIS, you just "label" this > ] > ] > tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network > ] > ] > does not even know such a tunnel link exist. this is equivalent to us > e > ] > ] > ISIS for ipv4, but use ospfv3 on the tunnel links. > ] > ] > > ] > ] > hope this helps. > ] > ] > > ] > ] > thanks. > ] > ] > > ] > ] > ] So you have to run OSPFv3 on the tunnel instead and redistribute t > o IS- > ] > IS at > ] > ] > each end > ] > ] > ] or something. > ] > ] > ] > ] > ] > ] I think autoencap is easier :-) > ] > ] > ] > ] > ] > ] Philip > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] actually here we have a nice example how MPLS can make things > ] > ] > ] > ] overall much simpler; > ] > ] > ] > ] > ] > ] > ] > ] i know the v6 bigots do not like that take, but i am afraid > ] > ] > ] > ] in the next years to come there won't be any 6-only networks; > ] > ] > ] > > ] > ] > ] > i don't think we are talking about 6-only networks. people are > ] > ] > ] > mainly interested in dual-mode, transition and isolated single/d > ual > ] > ] > ] > mode islands in the networks. yes, mpls can be a way to bridge t > he > ] > ] > ] > transition(assume those networks want to use mpls in their backb > ones) > ] > , > ] > ] > ] > but to my knowledge, to bridge some isolated V6 regions(still mo > stly > ] > ] > ] > dual-mode) together, it's so easy to use a couple of tunnels. i > agree > ] > ] > ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decou > ple t > ] > he > ] > ] > ] > topologies in the domain, M-ISIS is just another simple way to c > reate > ] > ] > ] > such a decoupled topologies. > ] > ] > ] > > ] > ] > ] > ] /hannes > ] > ] > ] > > ] > ] > ] > - Naiming > ] > ] > ] > > ] > ] > ] > _______________________________________________ > ] > ] > ] > Isis-wg mailing list > ] > ] > ] > Isis-wg@ietf.org > ] > ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > ] > ] > ] > ] > ] > ] > ] > ] > > ] > ] > - Naiming > ] > ] > > ] > ] > _______________________________________________ > ] > ] > Isis-wg mailing list > ] > ] > Isis-wg@ietf.org > ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > ] > ] > ] > ] > ] > > ] > - Naiming > ] > ] > ] > ] _______________________________________________ > ] Isis-wg mailing list > ] Isis-wg@ietf.org > ] https://www1.ietf.org/mailman/listinfo/isis-wg > > - Naiming > > _______________________________________________ > 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 Wed Jul 30 05:40: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 FAA25214 for ; Wed, 30 Jul 2003 05:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnRB-0002h7-2V; Wed, 30 Jul 2003 05:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnQT-0002gK-S0 for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 05:39:17 -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 FAA25183 for ; Wed, 30 Jul 2003 05:39:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hnQP-0006NH-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 05:39:13 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hnQO-0006ND-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 05:39:12 -0400 Received: from redback.com (redwood.redback.com [155.53.44.120]) by prattle.redback.com (Postfix) with ESMTP id D835A7D099E; Wed, 30 Jul 2003 02:34:53 -0700 (PDT) Message-ID: <3F27913D.3F7BEEA4@redback.com> From: Albert Tian X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: christian_tena@yahoo.co.uk Cc: Naiming Shen , Tony Li , Andrew Partan , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 23:21:52 BST <3F270190.30785.710064@localhost> <3F279C02.28091.3BA831@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 30 Jul 2003 02:34:53 -0700 Content-Transfer-Encoding: 7bit christian_tena@yahoo.co.uk wrote: > > I have read the draft (again). > > Take this network A-B-C-D-E-F > > A and F are MT aware. > > So we configure a GRE/IPv4 tunnel from A to F. > > In order for A and F to have an MT#2 adjacency over that tunnel, they have to have an > ordinary IS-IS adjacency over the tunnel, and declare themselves adjacent to each > other in their normal LSPs. Then they add on the MT stuff as TLVs on top of this new No, I believe they should not declare themselves adjacent in normal(non-MT) LSPs. Thanks, Albert > adjacency. > > Right or wrong ? > > If that is right, then, if a legacy IS-IS router somewhere else in the network gets the > normal LSP then it will consider the tunnel to be a usable route. > > Suppose that B gets LSPs from A and F. > > B might think that its best route to F is actually B-A-F and so will send all packets back > to A. > > The tunnel will I guess flap up and down if this happens as the GRE packets won't get > through when the tunnel is "up", but will when it's "down". > > Sorry to be a pain, but I really think I'm right on this. If not then I'll have to eat humble > pie (again) :-) > > Philip > > On 29 Jul 2003 at 15:34, Naiming Shen wrote: > > > > > pls read the MT draft. other than that, i should only add that the main > > purpose of M-ISIS is not letting legacy ipv4 routers 'see' any other > > topologies. in the case of ipv4 and ipv6, just think of the M-ISIS as > > isis running on ipv4, ospfv3 running on ipv6. > > > > thanks. > > > > ] Legacy routers will ignore the TLVs, but they won't ignore the fact that the > > re is an IS-IS > > ] topology, and they will attempt to route over it. > > ] > > ] You need that basic IS-IS topology in order to flood the MT TLVs, but you ca > > n't stop > > ] legacy IS-IS viewing it as a usable topology. > > ] > > ] Even if the end points of the tunnel are M-ISIS aware, they still flood the > > LSPs onwards, > > ] and the non M-ISIS aware routers still see the adjacencies and plot a route > > through > > ] them, even though they don't understand the TLVs. > > ] > > ] I have seen IP routers plot a route (and attempt to forward traffic) through > > an OSI-only > > ] router, and vice versa. They are supposed to do that. > > ] > > ] As far as SPF is concerned in a legacy router, what is the difference betwee > > n an MT > > ] aware, IPv6 router, and an OSI router with some extra TLVs that it doesn't u > > nderstand ? > > ] > > ] No difference, it will plot the route. > > ] > > ] Philip > > ] > > ] On 29 Jul 2003 at 14:41, Naiming Shen wrote: > > ] > > ] > ] Yeah, I messed up. > > ] > ] But..... > > ] > ] Suppose you label this tunnel as IPv6 only. > > ] > ] How does the legacy IS-IS (not MT capable) know to ignore it ? > > ] > > > ] > if the tunnel is ipv6-only link, then both routers at tunnel ends has > > ] > to be M-ISIS aware. and both routers send LSPs contain MT IS adjacency > > ] > records, other legacy routers do not understand those TLVs, thus they > > ] > don't even know this tunnel. > > ] > > > ] > thanks. > > ] > > > ] > ] > > ] > ] It's still an IS-IS adjacency as far as legacy IS-IS is concerned. Or > > isn't > > ] > it ? > > ] > ] > > ] > ] Philip > > ] > ] > > ] > ] On 29 Jul 2003 at 14:14, Naiming Shen wrote: > > ] > ] > > ] > ] > ] This is where things get weird. > > ] > ] > ] > > ] > ] > ] Suppose you have a real topology that goes A-B-C-D-E-F > > ] > ] > ] > > ] > ] > ] So you make a tunnel from A to F because B-C-D-E don't support v6. > > ] > ] > ] > > ] > ] > ] Do you want to make a static route to force the v6 packets down th > > e tun > > ] > nel ? > > ] > ] > ] > > ] > ] > ] Maybe not, so you run IS-IS over the tunnel as well. > > ] > ] > ] > > ] > ] > ] Oh but the tunnel had better be more attractive to packets than th > > e rea > > ] > l pat > > ] > ] > h. > > ] > ] > ] > > ] > ] > ] Now all your v4 packets go down the tunnel as well even though the > > y don > > ] > 't ne > > ] > ] > ed to. > > ] > ] > ] > > ] > ] > > > ] > ] > Hur? i think you're talking about tunnels with "normal" IGP, but i wa > > s > > ] > ] > talking about tunnels with M-ISIS. with M-ISIS, you just "label" this > > ] > ] > tunnel link as ipv6-only, and ipv4 topology(thus spf) in your network > > ] > ] > does not even know such a tunnel link exist. this is equivalent to us > > e > > ] > ] > ISIS for ipv4, but use ospfv3 on the tunnel links. > > ] > ] > > > ] > ] > hope this helps. > > ] > ] > > > ] > ] > thanks. > > ] > ] > > > ] > ] > ] So you have to run OSPFv3 on the tunnel instead and redistribute t > > o IS- > > ] > IS at > > ] > ] > each end > > ] > ] > ] or something. > > ] > ] > ] > > ] > ] > ] I think autoencap is easier :-) > > ] > ] > ] > > ] > ] > ] Philip > > ] > ] > ] > > ] > ] > ] > > ] > ] > ] > > ] > ] > ] On 29 Jul 2003 at 11:27, Naiming Shen wrote: > > ] > ] > ] > > ] > ] > ] > ] > > ] > ] > ] > ] actually here we have a nice example how MPLS can make things > > ] > ] > ] > ] overall much simpler; > > ] > ] > ] > ] > > ] > ] > ] > ] i know the v6 bigots do not like that take, but i am afraid > > ] > ] > ] > ] in the next years to come there won't be any 6-only networks; > > ] > ] > ] > > > ] > ] > ] > i don't think we are talking about 6-only networks. people are > > ] > ] > ] > mainly interested in dual-mode, transition and isolated single/d > > ual > > ] > ] > ] > mode islands in the networks. yes, mpls can be a way to bridge t > > he > > ] > ] > ] > transition(assume those networks want to use mpls in their backb > > ones) > > ] > , > > ] > ] > ] > but to my knowledge, to bridge some isolated V6 regions(still mo > > stly > > ] > ] > ] > dual-mode) together, it's so easy to use a couple of tunnels. i > > agree > > ] > ] > ] > that one can use OSPF for ipv4 and ISIS/OSPFv3 for ipv6 to decou > > ple t > > ] > he > > ] > ] > ] > topologies in the domain, M-ISIS is just another simple way to c > > reate > > ] > ] > ] > such a decoupled topologies. > > ] > ] > ] > > > ] > ] > ] > ] /hannes > > ] > ] > ] > > > ] > ] > ] > - Naiming > > ] > ] > ] > > > ] > ] > ] > _______________________________________________ > > ] > ] > ] > Isis-wg mailing list > > ] > ] > ] > Isis-wg@ietf.org > > ] > ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > > ] > ] > ] > > ] > ] > ] > > ] > ] > > > ] > ] > - Naiming > > ] > ] > > > ] > ] > _______________________________________________ > > ] > ] > Isis-wg mailing list > > ] > ] > Isis-wg@ietf.org > > ] > ] > https://www1.ietf.org/mailman/listinfo/isis-wg > > ] > ] > > ] > ] > > ] > > > ] > - Naiming > > ] > > ] > > ] > > ] _______________________________________________ > > ] Isis-wg mailing list > > ] Isis-wg@ietf.org > > ] https://www1.ietf.org/mailman/listinfo/isis-wg > > > > - Naiming > > > > _______________________________________________ > > 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 Wed Jul 30 05:57:32 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 FAA25531 for ; Wed, 30 Jul 2003 05:57:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnhd-00032a-Pf; Wed, 30 Jul 2003 05:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hnhA-000321-V4 for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 05:56:33 -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 FAA25502 for ; Wed, 30 Jul 2003 05:56:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hnh5-0006TN-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 05:56:28 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19hnh4-0006T7-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 05:56:26 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h6U9tMU05568; Wed, 30 Jul 2003 11:55:22 +0200 From: Hannes Gredler To: Jeff Learman Cc: christian_tena@yahoo.co.uk, Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Message-ID: <20030730095522.GA5498@juniper.net> References: <20030729182754.9AD285EE2E2@prattle.redback.com> <20030726114120.GA12753@juniper.net> <4.3.2.7.2.20030729172517.00b9d8b8@dingdong.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030729172517.00b9d8b8@dingdong.cisco.com> User-Agent: Mutt/1.3.28i 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, 30 Jul 2003 11:55:22 +0200 jeff, see answers/comments inline: On Tue, Jul 29, 2003 at 05:56:27PM -0400, Jeff Learman wrote: | | Philip, if I understand it correctly, you needn't run ISIS on an | MPLS tunnel, and it's dynamic anyway. No static routes are needed. | The MPLS tunnel needn't be represented as a link in the topology. | Frankly, if you treated every label path as a link, you'd have a | serious scalability problem! I'm talking "Basic MPLS". Other | applications may be different. | | All traffic from A to F gets tunneled, regardless of IPV6 or IPV4, no | problem. The MPLS tunnel isn't treated by the routing protocols | like it's a link, and you don't run ISIS over it. MPLS just provides | a magic carpet for those IPV6 packets to float over the IPV4 network | on ;) The information from routing protocols causes the nodes to set | up the label network, and after that, each node locally makes the | decision whether to use a label path to forward a packet, rather than | native IP. Interestingly enough, in an IPV4-only situation, these | decisions don't need to be made consistently by all routers -- if | some router neglects to tag a packet and IP-routes it, the next one | down the line can still tag it if it wants or not, and so on. | | The only problem where you'd come into any difficulty is Penultimate | Hop Popping. This is an optimization where the penultimate (second- | to-last) node in a label path pops the tag in order to even the load | between the edge and next-to-edge routers. If you're using PHP but | the penultimate node in the label path isn't IPV6, you'd have trouble. | Presumably the IPV6 MPLS folks are well aware of this and have some | mechanism to avoid this problem, it's beyond my area of incompetence. ;) the way so solve that is that the tunnel-headend does a double-push where the outerlabel is the "magic carpet" label and the inner is IPv6 explicit null (2); now the penultimate router knows to send it to the ultimate router using a v6 link layer protocol; | The scenario I'm discussing is the standard Service Provider model | providing IPV6 services to customers, and running Basic MPLS in | their core network on IPV4 routers. If you want more flexibility | on where you're running IPV6, perhaps you'd need MT or auto-encap. | My head hurts when I think about MPLS in anything other than the | standard deployments; I don't understand it well enough to extrapolate. | Perhaps an MPLS guru can shed more light on whether there are | limitations on what it can do to bridge IPV4 seas between arbitrary | IPV6 islands. But I can't think of any reason it wouldn't "just work", | other than the PHP thing. | | Now, maybe I'm all wet on my (admittedly limited) understanding of | MPLS. But as I see it, you have no need to run a separate routing | protocol or even use M-ISIS, as long as you have MPLS enabled in the | whole domain (or at least, in any IPV4 core, including any boundary | IPV6 nodes). Or maybe there isn't a solution to the PHP problem. jeff is way right - there is no need to run M-ISIS or even generate V6 TLVs at all; tunneling V6 traffic over V4 MPLS tunnels is [depending on your favourite router vendor] known as "6PE" or "V6-tunneling" - many SPs like that approach where you have a single-topology-ipv4-only IS-IS core and the edge routers run then MP-BGP to pass on the V6 island prefixes; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 30 08:15:43 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 IAA27962 for ; Wed, 30 Jul 2003 08:15:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hprB-0006cw-PD; Wed, 30 Jul 2003 08:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hpql-0006cT-1F for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 08:14:35 -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 IAA27941 for ; Wed, 30 Jul 2003 08:14:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hpqj-0007AU-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 08:14:33 -0400 Received: from gwnj8.utstar.com ([65.200.123.8] helo=lxmail.xebeo.com) by ietf-mx with smtp (Exim 4.12) id 19hpqj-0007AG-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 08:14:33 -0400 Received: (qmail 27236 invoked from network); 30 Jul 2003 12:14:01 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.106) by lxmail.nj.us.utstar.com with SMTP; 30 Jul 2003 12:14:01 -0000 Message-ID: <3F27B4C9.5070800@xebeo.com> From: Tony Przygienda Reply-To: prz@xebeo.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: christian_tena@yahoo.co.uk CC: Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: Mail from christian_tena@yahoo.co.uk dated Tue, 29 Jul 2003 23:21:52 BST <3F270190.30785.710064@localhost> <3F279C02.28091.3BA831@localhost> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 30 Jul 2003 14:06:33 +0200 Content-Transfer-Encoding: 7bit christian_tena@yahoo.co.uk wrote: >I have read the draft (again). > >Take this network A-B-C-D-E-F > >A and F are MT aware. > >So we configure a GRE/IPv4 tunnel from A to F. > >In order for A and F to have an MT#2 adjacency over that tunnel, they have to have an >ordinary IS-IS adjacency over the tunnel, and declare themselves adjacent to each >other in their normal LSPs. Then they add on the MT stuff as TLVs on top of this new >adjacency. > >Right or wrong ? > >If that is right, then, if a legacy IS-IS router somewhere else in the network gets the >normal LSP then it will consider the tunnel to be a usable route. > >Suppose that B gets LSPs from A and F. > >B might think that its best route to F is actually B-A-F and so will send all packets back >to A. > >The tunnel will I guess flap up and down if this happens as the GRE packets won't get >through when the tunnel is "up", but will when it's "down". > >Sorry to be a pain, but I really think I'm right on this. If not then I'll have to eat humble >pie (again) :-) > >Philip > they're not adjacent in MT#0. read the draft carefully, pls. I think section 5.1 is very clear about that. -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 30 12:14: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 MAA06694 for ; Wed, 30 Jul 2003 12:14: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 19htaT-0007Cv-Iw; Wed, 30 Jul 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htZp-0007Cb-OA for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 12:13:21 -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 MAA06616 for ; Wed, 30 Jul 2003 12:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htZo-0001RX-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 12:13:20 -0400 Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by ietf-mx with smtp (Exim 4.12) id 19htZn-0001RU-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 12:13:19 -0400 Received: from wireless09.one2one.net (HELO pchristi) (christian?tena@149.254.200.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 30 Jul 2003 16:13:14 -0000 From: "Philip Christian" To: Tony Przygienda , Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org MIME-Version: 1.0 Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Reply-to: christian_tena@yahoo.co.uk Message-ID: <3F27FC30.2625.1B35F07@localhost> Priority: normal In-reply-to: <3F27B4C9.5070800@xebeo.com> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT 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, 30 Jul 2003 17:11:12 +0100 Content-Transfer-Encoding: 7BIT On 30 Jul 2003 at 14:06, Tony Przygienda wrote: > they're not adjacent in MT#0. read the draft carefully, pls. I think > section 5.1 is very clear about that. > okay, I now understand that an adjacency can exist between two routers as far as MT#n is concerned, without the legacy IS-IS adjacency (mt#0) being "up". This makes such an adjacency invisible to legacy IS-IS. Very clever.. This is not clearly stated anywhere in the draft, and most certainly not in section 5.1. Section 5.1 says what is advertised in MT bit of LSPs, but not what is advertised in parts of the LSP readable by legacy implementations. Moreover, section 5.1 talks about "topology based LSPs" but the draft does not really define what a "topology based LSP" is. I think actually it means an MT TLV relating to a particular MT topology. Anyway the term is a bit too vague. Moreover in the abstract it says "This draft describes how to run within a single ISIS domain a set of independent IP topologies that we call Multi-Topologies (MTs)." but actually you are now talking about MTs that are not "within" the ISIS domain, because the legacy ISIS domain doesn't go over that tunnel. I think that there is a strong risk of a new implementer coming along and not realising that you can have an adjacency up and declared in an MT without it being up in the legacy ISIS and making a horrid interoperability problem. It needs to be clearly stated. Philip _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 30 14:06: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 OAA11155 for ; Wed, 30 Jul 2003 14:06: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 19hvKr-0004vJ-Pl; Wed, 30 Jul 2003 14:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvKA-0004tg-58 for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 14:05:18 -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 OAA11074 for ; Wed, 30 Jul 2003 14:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvK7-0002MK-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 14:05:15 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19hvK7-0002MH-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 14:05:15 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 7F09535C949; Wed, 30 Jul 2003 11:03:10 -0700 (PDT) To: Hannes Gredler Cc: Jeff Learman , christian_tena@yahoo.co.uk, Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] In-reply-to: Mail from Hannes Gredler dated Wed, 30 Jul 2003 11:55:22 +0200 <20030730095522.GA5498@juniper.net> From: Naiming Shen Message-Id: <20030730180310.7F09535C949@prattle.redback.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, 30 Jul 2003 11:03:10 -0700 Using mpls is a good approach, but the conclusion here is only partially correct. Follow the same logic, we should say OSPFv3 is useless and not needed, since if we have OSPFv2, we have MPLS and we have BGP, why do we need OSPFv3? why not just run 6PE everywhere in every network? We seem to be mixing the IGP with BGP or 'overloaded-BGP'. IGP is used for intradomain paths to connect internal routers together. while 6PE does the job to transport ISP's customer v6 data across ISP's v4 backbone, this assumes also the network using v4 ibgp peers, the whole network is mpls enabled, providers want to use the v4 topology for v6 traffic with no change. Otherwise, if the network does want to enable native v6 internally, if they do want to run a different topology than the v4 topology(e.g. two links between two nodes, they want to run v4 on the GE link, but v6 on the FE link), if the network is not running bgp-mpls-vpn or even mpls, then operators may want to run a v6 IGP in part of their network. But if your comment meant for the people using mpls transport v6 data and v6 IGP is not needed, then I completely agree. thanks. ] ] jeff is way right - there is no need to run M-ISIS or even ] generate V6 TLVs at all; ] ] tunneling V6 traffic over V4 MPLS tunnels is [depending on your ] favourite router vendor] known as "6PE" or "V6-tunneling" - ] ] many SPs like that approach where you have a single-topology-ipv4-only ] IS-IS core and the edge routers run then MP-BGP to pass on the V6 ] island prefixes; ] ] /hannes - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Jul 30 15:50: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 PAA15359 for ; Wed, 30 Jul 2003 15:50: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 19hwxV-0001BN-B2; Wed, 30 Jul 2003 15:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwwl-0001Ak-D7 for isis-wg@optimus.ietf.org; Wed, 30 Jul 2003 15:49:15 -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 PAA15301 for ; Wed, 30 Jul 2003 15:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwwj-00034A-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 15:49:13 -0400 Received: from net4u.net4u.ch ([194.191.0.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwwi-000347-00 for isis-wg@ietf.org; Wed, 30 Jul 2003 15:49:12 -0400 Received: from net4u.ch (zux006-022-154.adsl.green.ch [81.6.22.154]) by net4u.net4u.ch (8.12.9/8.12.9) with ESMTP id h6UJoJ2G025165; Wed, 30 Jul 2003 21:50:19 +0200 Message-ID: <3F281F72.7050602@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: christian_tena@yahoo.co.uk CC: Tony Przygienda , Naiming Shen , Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] References: <3F27FC30.2625.1B35F07@localhost> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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, 30 Jul 2003 21:41:38 +0200 Content-Transfer-Encoding: 7bit Philip Christian wrote: >On 30 Jul 2003 at 14:06, Tony Przygienda wrote: > > > >>they're not adjacent in MT#0. read the draft carefully, pls. I think >>section 5.1 is very clear about that. >> >> >> > >okay, I now understand that an adjacency can exist between two routers as far as MT#n >is concerned, without the legacy IS-IS adjacency (mt#0) being "up". This makes such >an adjacency invisible to legacy IS-IS. > >Very clever.. > >This is not clearly stated anywhere in the draft, and most certainly not in section 5.1. > >Section 5.1 says what is advertised in MT bit of LSPs, but not what is advertised in parts >of the LSP readable by legacy implementations. > >Moreover, section 5.1 talks about "topology based LSPs" but the draft does not really >define what a "topology based LSP" is. I think actually it means an MT TLV relating to a >particular MT topology. Anyway the term is a bit too vague. > >Moreover in the abstract it says "This draft describes how to run within a single ISIS >domain a set of independent IP topologies that we call Multi-Topologies (MTs)." but >actually you are now talking about MTs that are not "within" the ISIS domain, because >the legacy ISIS domain doesn't go over that tunnel. > >I think that there is a strong risk of a new implementer coming along and not realising >that you can have an adjacency up and declared in an MT without it being up in the >legacy ISIS and making a horrid interoperability problem. > >It needs to be clearly stated. > > Philip, I dare to disagree here, when section 5.1 says If local router does not participate in certain MTs, it will not advertise those MTIDs in it's IIHs and thus will not include that neighbor within it's topology based LSPs. On the other hand, if a MTID is not detected in remote side's IIHs, the local router MUST NOT include that neighbor within it's MT LSPs. The local router SHOULD NOT form adjacency if they don't have at least one common MT set over the interface. which clearly implies that you maintain an adjaceny _per topology_ and there is no _implicit #0 adjacency_. In 5.2 however Two Routers on a LAN SHALL always establish adjacency regardless whether they have common MT set or not. This is to ensure all the routers on the LAN can correctly elect the same DIS. The IS SHOULD NOT include the MT IS TLV in its LSP if none of the adjacencies on the LAN contains this MT. clearly describes an _implicit adjacency_. But ok, let's say, clarifying can't hurt so as editorial fix what would be the clarifying sentence you would like to add ? BTW, IMHO there will be no interop problem if an implementor screws up since the backlink will be always missing for the SPF ... thanks ---tony > > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Jul 31 02:54:41 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 CAA13746 for ; Thu, 31 Jul 2003 02:54:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7K6-0008Kl-9k; Thu, 31 Jul 2003 02:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7Je-0008Jz-6A for isis-wg@optimus.ietf.org; Thu, 31 Jul 2003 02:53: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 CAA13714 for ; Thu, 31 Jul 2003 02:53:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7Ja-0000AW-00 for isis-wg@ietf.org; Thu, 31 Jul 2003 02:53:30 -0400 Received: from ghostrider.gredler.at ([193.83.223.228]) by ietf-mx with esmtp (Exim 4.12) id 19i7JY-00009s-00 for isis-wg@ietf.org; Thu, 31 Jul 2003 02:53:29 -0400 Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h6V6qfL09705; Thu, 31 Jul 2003 08:52:41 +0200 From: Hannes Gredler To: Naiming Shen Cc: Jeff Learman , christian_tena@yahoo.co.uk, Tony Li , Andrew Partan , Albert Tian , isis-wg@ietf.org Subject: Re: Multiple-topology IS-IS [RE: [Isis-wg] Feedback on IS-IS AutomaticEncapsulation] Message-ID: <20030731065241.GA9669@juniper.net> References: <20030730095522.GA5498@juniper.net> <20030730180310.7F09535C949@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030730180310.7F09535C949@prattle.redback.com> User-Agent: Mutt/1.3.28i 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, 31 Jul 2003 08:52:41 +0200 hi naiming, answers/comments inline; On Wed, Jul 30, 2003 at 11:03:10AM -0700, Naiming Shen wrote: | | Using mpls is a good approach, but the conclusion here is only | partially correct. | | Follow the same logic, we should say OSPFv3 is useless and not needed, | since if we have OSPFv2, we have MPLS and we have BGP, why do we | need OSPFv3? why not just run 6PE everywhere in every network? i won't comment if OSPFv{2,3} i useless or not ;-) - let me put it that way: going down the protocol maturity curve for a new routing protoccol [OSPFv3] in order to establish a control-plane that will be redundant [i.e. v4 already there] is a risk that nat everybody wants to afford; rather than taking the pain of maturing OSPFv3 SPs are more willing to turn on MPLS as all major implmentations are mature and interoperable these days; | We seem to be mixing the IGP with BGP or 'overloaded-BGP'. conveying V6 routes in BGP is IMHO not overloading; | IGP is used for intradomain paths to connect internal routers together. | while 6PE does the job to transport ISP's customer v6 data across | ISP's v4 backbone, this assumes also the network using v4 ibgp peers, | the whole network is mpls enabled, providers want to use the v4 | topology for v6 traffic with no change. Otherwise, if the network | does want to enable native v6 internally, if they do want to run | a different topology than the v4 topology(e.g. two links between | two nodes, they want to run v4 on the GE link, but v6 on the FE | link), if the network is not running bgp-mpls-vpn or even mpls, | then operators may want to run a v6 IGP in part of their network. another possibility would be to force your V6 traffic to use a certain tunnel that is different form the shortest path .... you have used the term "overload" - don't we run risk that with MT we are trying to "overload" light TE functions in the IGP ? the best argument for MT so far is traffic-control over non-congurnet topologies - i'll ask myself how much traffic control functions do we want to piggyback to our IGPs ? | But if your comment meant for the people using mpls transport v6 | data and v6 IGP is not needed, then I completely agree. what i tried to say is that on the list we are doing a discussion purely about technology - however the deployement reality [=SPs] tell(s) us that the problem has already been solved and further evolvement of the protocol is not needed; /hannes | ] | ] jeff is way right - there is no need to run M-ISIS or even | ] generate V6 TLVs at all; | ] | ] tunneling V6 traffic over V4 MPLS tunnels is [depending on your | ] favourite router vendor] known as "6PE" or "V6-tunneling" - | ] | ] many SPs like that approach where you have a single-topology-ipv4-only | ] IS-IS core and the edge routers run then MP-BGP to pass on the V6 | ] island prefixes; | ] | ] /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg