From isis-wg-admin@ietf.org Mon Feb 3 10:01:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09477 for ; Mon, 3 Feb 2003 10:01:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F48J27441; Mon, 3 Feb 2003 10:04:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13F1jJ27311 for ; Mon, 3 Feb 2003 10:01:45 -0500 Received: from strange-brew.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09125 for ; Mon, 3 Feb 2003 09:56:13 -0500 (EST) Received: from there (ams-clip-vpn-dhcp49.cisco.com [10.61.64.49]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id h13ExeI19900; Mon, 3 Feb 2003 15:59:41 +0100 (CET) Message-Id: <200302031459.h13ExeI19900@strange-brew.cisco.com> Content-Type: text/plain; charset="iso-8859-15" From: stefano previdi To: Noguchi Kay , isis-wg@ietf.org Subject: Re: [Isis-wg] 56th IETF X-Mailer: KMail [version 1.3.1] References: <8765s68nc9.wl@titanium.ekay.org> In-Reply-To: <8765s68nc9.wl@titanium.ekay.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h13F1kJ27312 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, 3 Feb 2003 15:59:27 +0100 Content-Transfer-Encoding: 8bit On Thursday 30 January 2003 20:11, Noguchi Kay wrote: > Hi all, > > This is Kay. > > 56th IETF agenda items are listed in the IETF web site but thers is no > slot for IS-IS working group. > > http://ietf.org/meetings/agenda_56.html > > And there are lots of internet-drafts out there so let's have a session > at 56th IETF. What do you think, all, especially draft authers? > > At least for me, I want to have a slot for my new draft, Protocol Topology > Support for IS-IS. > > http://ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-00.txt don't we have exact same capability in draft-ietf-isis-wg-multi-topology ? s. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Feb 3 11:29:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12338 for ; Mon, 3 Feb 2003 11:29:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GVoJ01674; Mon, 3 Feb 2003 11:31:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13GUSJ01596 for ; Mon, 3 Feb 2003 11:30:28 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12173 for ; Mon, 3 Feb 2003 11:24:54 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18fjSN-0000Bs-00; Mon, 03 Feb 2003 08:28:28 -0800 Message-ID: <874r7ljplg.wl@giga.kayz.org> From: Noguchi Kay To: stefano previdi Cc: Noguchi Kay , isis-wg@ietf.org In-Reply-To: <200302031459.h13ExeI19900@strange-brew.cisco.com> References: <8765s68nc9.wl@titanium.ekay.org> <200302031459.h13ExeI19900@strange-brew.cisco.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Feb 2003 08:28:27 -0800 Hi Stefano, This is Kay. I changed the subject. > > At least for me, I want to have a slot for my new draft, Protocol Topology > > Support for IS-IS. > > > > http://ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-00.txt > > don't we have exact same capability in draft-ietf-isis-wg-multi-topology ? It's different. In Multi Topology, if you pick the IPv4 network layer protocols for standard IS-IS topology(MT ID #0), then all routers MUST support IPv4 network layer protocols. With my draft, you can mix up IPv4, IPv6 and IPv4/IPv6 routers in a single IS-IS domain(standard IS-IS topology). Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Feb 3 15:10:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19801 for ; Mon, 3 Feb 2003 15:10:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KDgJ22008; Mon, 3 Feb 2003 15:13:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13KCEJ21935 for ; Mon, 3 Feb 2003 15:12:14 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19556 for ; Mon, 3 Feb 2003 15:06:35 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 6DA973899A3; Mon, 3 Feb 2003 12:10:10 -0800 (PST) To: Noguchi Kay Cc: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay dated Mon, 03 Feb 2003 08:28:27 PST <874r7ljplg.wl@giga.kayz.org> From: Naiming Shen Message-Id: <20030203201010.6DA973899A3@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: Mon, 03 Feb 2003 12:10:10 -0800 Kay, ] ] > > At least for me, I want to have a slot for my new draft, Protocol Topolo gy ] > > Support for IS-IS. ] > > ] > > http://ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-00. txt ] > ] > don't we have exact same capability in draft-ietf-isis-wg-multi-topology ? ] ] It's different. ] ] In Multi Topology, if you pick the IPv4 network layer protocols for ] standard IS-IS topology(MT ID #0), then all routers MUST support ] IPv4 network layer protocols. really? could you point out where in the M-ISIS draft mentioning this particular feature? thanks. ] ] With my draft, you can mix up IPv4, IPv6 and IPv4/IPv6 routers in a ] single IS-IS domain(standard IS-IS topology). ] ] Thank you, ] ] kay ] _______________________________________________ ] 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 Mon Feb 3 17:03:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23308 for ; Mon, 3 Feb 2003 17:03:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13M6dJ29378; Mon, 3 Feb 2003 17:06:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13M4wJ29323 for ; Mon, 3 Feb 2003 17:04:58 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23206 for ; Mon, 3 Feb 2003 16:59:17 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18fofR-0000QX-00; Mon, 03 Feb 2003 14:02:17 -0800 Message-ID: <87znpdhvkn.wl@giga.kayz.org> From: Noguchi Kay To: Naiming Shen Cc: Noguchi Kay , stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030203201010.6DA973899A3@prattle.redback.com> References: X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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, 03 Feb 2003 14:02:16 -0800 Hi Naiming, This is Kay. > ] It's different. > ] > ] In Multi Topology, if you pick the IPv4 network layer protocols for > ] standard IS-IS topology(MT ID #0), then all routers MUST support > ] IPv4 network layer protocols. > > really? could you point out where in the M-ISIS draft mentioning this > particular feature? From my understanding, to make adjacency with routers that doesn't support M-ISIS extension, M-ISIS capable routers MUST paticipate in the standard topology, MT ID #0. In that case, all the routers MUST support network layer protocols for standard topology, in this case IPv4. So there is no IPv6 only routers in that IS-IS domain. Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Feb 3 17:35:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24065 for ; Mon, 3 Feb 2003 17:35:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13McAJ31923; Mon, 3 Feb 2003 17:38:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13MbhJ31891 for ; Mon, 3 Feb 2003 17:37:43 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23988 for ; Mon, 3 Feb 2003 17:32:01 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 65ECA343009; Mon, 3 Feb 2003 14:35:37 -0800 (PST) To: Noguchi Kay Cc: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay dated Mon, 03 Feb 2003 14:02:16 PST <87znpdhvkn.wl@giga.kayz.org> From: Naiming Shen Message-Id: <20030203223537.65ECA343009@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: Mon, 03 Feb 2003 14:35:37 -0800 Kay, ] > ] It's different. ] > ] ] > ] In Multi Topology, if you pick the IPv4 network layer protocols for ] > ] standard IS-IS topology(MT ID #0), then all routers MUST suppor t ] > ] IPv4 network layer protocols. ] > ] > really? could you point out where in the M-ISIS draft mentioning this ] > particular feature? ] ] From my understanding, to make adjacency with routers that doesn't ] support M-ISIS extension, M-ISIS capable routers MUST paticipate ] in the standard topology, MT ID #0. this is a misunderstaind of the M-ISIS mechanism. i'm still wondering where this assumption comes from. if this is from the M-ISIS draft, please point this out. over a LAN media, the draft explicitly requires to establish adjacencies with all the neighobrs regardless of topology. thus there is absolutely no requirement to put itself into MTID #0 in order to make adjacency with legacy isis software. thanks. ] ] In that case, all the routers MUST support network layer protocols ] for standard topology, in this case IPv4. ] ] So there is no IPv6 only routers in that IS-IS domain. ] ] Thank you, ] ] kay ] _______________________________________________ ] 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 Mon Feb 3 18:11:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24867 for ; Mon, 3 Feb 2003 18:11:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NEMJ01622; Mon, 3 Feb 2003 18:14:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13NDLJ01593 for ; Mon, 3 Feb 2003 18:13:21 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24779 for ; Mon, 3 Feb 2003 18:07:40 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18fpkU-0000TT-00; Mon, 03 Feb 2003 15:11:34 -0800 Message-ID: <87vg01hsd5.wl@giga.kayz.org> From: Noguchi Kay To: Naiming Shen Cc: Noguchi Kay , stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030203223537.65ECA343009@prattle.redback.com> References: X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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, 03 Feb 2003 15:11:34 -0800 Hi Namiming, This is Kay. > this is a misunderstaind of the M-ISIS mechanism. i'm still wondering > where this assumption comes from. if this is from the M-ISIS draft, please > point this out. > over a LAN media, the draft explicitly requires to establish adjacencies > with all the neighobrs regardless of topology. thus there is absolutely > no requirement to put itself into MTID #0 in order to make adjacency > with legacy isis software. So then, how to make adjacent between legacy ISIS software which only supports IPv4 and M-ISIS capable software which only supports IPv6? Legacy IS-IS software requires same network layer topology support in a area that is mensioned in RFC 1195. Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Feb 3 18:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25332 for ; Mon, 3 Feb 2003 18:34:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Nb7J02516; Mon, 3 Feb 2003 18:37:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h13Na5J02280 for ; Mon, 3 Feb 2003 18:36:05 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25229 for ; Mon, 3 Feb 2003 18:30:24 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 8328D2FF84; Mon, 3 Feb 2003 15:33:59 -0800 (PST) To: Noguchi Kay Cc: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay dated Mon, 03 Feb 2003 15:11:34 PST <87vg01hsd5.wl@giga.kayz.org> From: Naiming Shen Message-Id: <20030203233359.8328D2FF84@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: Mon, 03 Feb 2003 15:33:59 -0800 Kay, ] ] So then, how to make adjacent between legacy ISIS software which ] only supports IPv4 and M-ISIS capable software which only supports ] IPv6? ] ] Legacy IS-IS software requires same network layer topology support ] in a area that is mensioned in RFC 1195. on a Lan media, just announce all the possible NLPIDs, but only MT ID for IPv6. don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4 neighbor will fail on backlink check during the SPF, thus will not use you as a nexthop. thanks. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Feb 4 16:56:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05769 for ; Tue, 4 Feb 2003 16:56:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LxSJ26674; Tue, 4 Feb 2003 16:59:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14LudJ26555 for ; Tue, 4 Feb 2003 16:56:39 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05452 for ; Tue, 4 Feb 2003 16:50:28 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18gB0q-0002WV-00; Tue, 04 Feb 2003 13:53:52 -0800 Message-ID: <87hebjiufk.wl@giga.kayz.org> From: Noguchi Kay To: Naiming Shen Cc: Noguchi Kay , stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030203233359.8328D2FF84@prattle.redback.com> References: X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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, 04 Feb 2003 13:53:51 -0800 Hi Naiming, This is Kay. > ] So then, how to make adjacent between legacy ISIS software which > ] only supports IPv4 and M-ISIS capable software which only supports > ] IPv6? > ] > ] Legacy IS-IS software requires same network layer topology support > ] in a area that is mensioned in RFC 1195. > > on a Lan media, just announce all the possible NLPIDs, but only MT ID for > IPv6. Two questions for this. 1) How to get the "all the possible NLPIDs" and what is the value which M-ISIS software only support IPv6 puts in for this case? IPv4 and IPv6 NLPIDs or IPv4 NLPID only? 2) Some implementation checks if the IP Interface Address TLV is in the same subnetwork or not to form an adjacency as stated in draft-ietf-isis-ip-interoperable-00.txt section 13. How does M-ISIS software which only supports IPv6 get the IPv4 subnetwork information for this link? > don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4 > neighbor will fail on backlink check during the SPF, thus will not > use you as a nexthop. I know OSPFv2 specification has the "link back check" in the spec, RFC 2328 section 16.1(p. 163). But I didn't see it in ISO 10589 nor RFC 1195. Could you point out where it's documented or is that an unwritten spec? Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Feb 4 17:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06498 for ; Tue, 4 Feb 2003 17:23:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14MRCJ29328; Tue, 4 Feb 2003 17:27:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h14MOWJ29223 for ; Tue, 4 Feb 2003 17:24:32 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06353 for ; Tue, 4 Feb 2003 17:18:21 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h14MLxSQ004806; Tue, 4 Feb 2003 14:21:59 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-83.cisco.com [128.107.163.83]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADZ18678; Tue, 4 Feb 2003 14:09:20 -0800 (PST) Message-Id: <4.3.2.7.2.20030204141510.00b6dd40@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Noguchi Kay From: Les Ginsberg Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Cc: Naiming Shen , Noguchi Kay , stefano previdi , isis-wg@ietf.org In-Reply-To: <87hebjiufk.wl@giga.kayz.org> References: <20030203233359.8328D2FF84@prattle.redback.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_12419948==_.ALT" Sender: isis-wg-admin@ietf.org Errors-To: isis-wg-admin@ietf.org X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF IS-IS working group List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Feb 2003 14:21:58 -0800 --=====================_12419948==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 01:53 PM 2/4/2003 -0800, Noguchi Kay wrote: > > don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4 > > neighbor will fail on backlink check during the SPF, thus will not > > use you as a nexthop. > > I know OSPFv2 specification has the "link back check" in > the spec, RFC 2328 section 16.1(p. 163). > > But I didn't see it in ISO 10589 nor RFC 1195. > > Could you point out where it's documented or is that an > unwritten spec? From ISO 10589: 7.2.8.2 Two-way connectivity check The Decision Process shall not utilise a link between two Intermediate Systems unless both ISs report the link. Les --=====================_12419948==_.ALT Content-Type: text/html; charset="us-ascii" At 01:53 PM 2/4/2003 -0800, Noguchi Kay wrote:

> don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4
> neighbor will fail on backlink check during the SPF, thus will not
> use you as a nexthop.

        I know OSPFv2 specification has the "link back check" in
        the spec, RFC 2328 section 16.1(p. 163).

        But I didn't see it in ISO 10589 nor RFC 1195.

        Could you point out where it's documented or is that an
        unwritten spec?

From ISO 10589:

7.2.8.2 Two-way connectivity check

The Decision Process shall not utilise a link between two Intermediate Systems unless both ISs report the link.

    Les
 --=====================_12419948==_.ALT-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Feb 4 20:01:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09559 for ; Tue, 4 Feb 2003 20:01:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1515JJ05524; Tue, 4 Feb 2003 20:05:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1512rJ05438 for ; Tue, 4 Feb 2003 20:02:53 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09417 for ; Tue, 4 Feb 2003 19:56:40 -0500 (EST) Received: from net4u.ch (zux006-008-206.adsl.green.ch [81.6.8.206]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h1510GC20529 for ; Wed, 5 Feb 2003 02:00:16 +0100 Message-ID: <3E40614B.3050401@net4u.ch> From: Tony Przygienda Reply-To: prz@net4u.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ISIS-WG (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Isis-wg] new version of the proprietary/experimental draft ... 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, 05 Feb 2003 01:56:43 +0100 Content-Transfer-Encoding: 7bit Everyone, we had "behind the scenes" a pretty good conversion (we kept the group initially small to make progress) on some philosophical issues brought up by IAB concerning the 'experimental' draft. The consensus boiled down to multiple points that at this point in time will need an open discussion on the list to make sure the significant participants are happy with the result forthcoming: . we change all references from 'proprietary' to 'experimental' so instead of encouraging vendors to 'hide' things they will lay them out in the open in an informal way so the deploying parties have a chance to judge the risks vs. gains. We add a section to the draft saying something along the lines of "Implementers SHOULD openly document their use of the Experimental TLV in an Experimental status RFC." . given that we have RFC 2026, a nice track exists where the publication of the experimental TLV is not even bound by having made it into the workgroup. The authors can and should send the experimental TLV description directly to the IETF editor so the hurdle to document the work is absolutely minimal. That will merit a section in the document as well. . A section that is equivalent to 'proceed at your own risk' will be necessary, basically saying that interoperability of such an experimental extension is not guaranteed to interoperate with other implementations and may pose unknown security risks. In connection to the security risk, the section will emphasize again that without documentation for an experimental TLV, the operators have not even the possiblity to understand possible problems in terms of security and interoperability they are facing when deploying an experimental TLV. thanks -- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 01:45:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17928 for ; Wed, 5 Feb 2003 01:45:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h156mqJ22554; Wed, 5 Feb 2003 01:48:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h156j4J22485 for ; Wed, 5 Feb 2003 01:45:04 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17792 for ; Wed, 5 Feb 2003 01:38:43 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 472B83FAC8; Tue, 4 Feb 2003 22:42:21 -0800 (PST) To: Noguchi Kay Cc: stefano previdi , isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay dated Tue, 04 Feb 2003 13:53:51 PST <87hebjiufk.wl@giga.kayz.org> From: Naiming Shen Message-Id: <20030205064221.472B83FAC8@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, 04 Feb 2003 22:42:21 -0800 Hi Kay, ] > on a Lan media, just announce all the possible NLPIDs, but only MT ID for ] > IPv6. ] ] Two questions for this. ] ] 1) How to get the "all the possible NLPIDs" and what is the value ] which M-ISIS software only support IPv6 puts in for this case? ] ] IPv4 and IPv6 NLPIDs or IPv4 NLPID only? NLPIDs for both v4 and v6. the adjacency status will be determined by the MT status. ] ] 2) Some implementation checks if the IP Interface Address TLV is ] in the same subnetwork or not to form an adjacency as ] stated in draft-ietf-isis-ip-interoperable-00.txt section 13. ] ] How does M-ISIS software which only supports IPv6 get the IPv4 ] subnetwork information for this link? as you noticed, this is an implementation issue. and get aournd those implementation, one can assign an ipv4 address on the LAN interface, and "inject" that ipv4 address in the IIH which is on the same subnet as your neighbors. as far as i know, there is no ipv6 only routers yet, get an ipv4 address on the LAN interface does not mean the router need to switch ipv4 traffic, it can still be a ipv6 only M-ISIS node. for any new routing scheme, we can not expect a flag day to upgrage all the nodes with new software. any scheme HAS to co-exist with the current/legacy software. new software has the flexibility to do "tricks" to work with the old software. going forward, as i mentioned in my previous email post, it's better to get rid of the restriction on setting up LAN adjacencies. just set up them all, to use them or not, it's a local issue(e.g. if the node does not like neighbor's IP subnet, then don't put a pnode tlv in it's lsp). Les has answered the below question. thanks. ] ] > don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4 ] > neighbor will fail on backlink check during the SPF, thus will not ] > use you as a nexthop. ] ] I know OSPFv2 specification has the "link back check" in ] the spec, RFC 2328 section 16.1(p. 163). ] ] But I didn't see it in ISO 10589 nor RFC 1195. ] ] Could you point out where it's documented or is that an ] unwritten spec? - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 05:23:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16164 for ; Wed, 5 Feb 2003 05:23:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15ARfJ11962; Wed, 5 Feb 2003 05:27:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15AQVJ11921 for ; Wed, 5 Feb 2003 05:26:31 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16065 for ; Wed, 5 Feb 2003 05:20:05 -0500 (EST) Received: (qmail 10573 invoked from network); 5 Feb 2003 10:23:39 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 5 Feb 2003 10:23:39 -0000 Received: (qmail 45013 invoked from network); 5 Feb 2003 10:23:35 -0000 Received: from unknown (HELO ws1-3.us4.outblaze.com) (205.158.62.55) by 205-158-62-153.outblaze.com with SMTP; 5 Feb 2003 10:23:34 -0000 Received: (qmail 15337 invoked by uid 1001); 5 Feb 2003 10:23:34 -0000 Message-ID: <20030205102334.15336.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [149.254.120.136] by ws1-3.us4.outblaze.com with http for philip.christian@iname.com; Wed, 05 Feb 2003 10:23:34 +0000 From: "Philip Christian" To: naiming@redback.com, kay@ipinfusion.com Cc: sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt X-Originating-Ip: 149.254.120.136 X-Originating-Server: ws1-3.us4.outblaze.com 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, 05 Feb 2003 10:23:34 +0000 Content-Transfer-Encoding: 7bit I also have serious problems with this draft. 1. Integrated IS-IS was originally architected as an "Integrated" routing protocol to route both CLNP and IPv4 in a single SPF. The problem of running IPv4 and IPv6 together is not a new problem, it is actually exactly the same one that RFC 1195 was originally written to deal with (but with v4 and CLNP). Integrated IS-IS will work just as well with v4 and v6 as it did with v4 and CLNP. This draft attempts to unravel this behaviour by having separate SPFs. This is contrary to the original architecture of Integrated IS-IS (it isn't even "integrated") and contrary to section 3.10 of RFC 1195 where it says "The Dijkstra computation does not take into consideration whether a router is IP-only, OSI-only, or dual. The topological restrictions specified in section 1.4 ensure that IP packets will only be sent via IP-capable routers, and OSI packets will only be sent via OSI-capable routers." This is not just some detail, but a fundamental behaviour of the protocol. Consequently there is no interoperability between this draft and RFC 1195. 2. If one wants to run separate SPFs for v4 and v6 then there are easier ways to do it. You could put all of the v4 nodes in one area and all the v6 nodes in another. Then you could just make a dual router with two SPFs that participates in both areas. Or you could use the existing MT draft. Or you could just use OSPF. 3. The draft isn't even honest enough to state that it will not interoperate with existing RFC 1195 implementations, nor with G.7712, nor with auto-encap. If there is some non-interoperability introduced then it should be clearly stated up front. Regards, Philip Christian ----- Original Message ----- From: Naiming Shen Date: Tue, 04 Feb 2003 22:42:21 -0800 To: Noguchi Kay Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Hi Kay, ] > on a Lan media, just announce all the possible NLPIDs, but only MT ID for ] > IPv6. ] ] Two questions for this. ] ] 1) How to get the "all the possible NLPIDs" and what is the value ] which M-ISIS software only support IPv6 puts in for this case? ] ] IPv4 and IPv6 NLPIDs or IPv4 NLPID only? NLPIDs for both v4 and v6. the adjacency status will be determined by the MT status. ] ] 2) Some implementation checks if the IP Interface Address TLV is ] in the same subnetwork or not to form an adjacency as ] stated in draft-ietf-isis-ip-interoperable-00.txt section 13. ] ] How does M-ISIS software which only supports IPv6 get the IPv4 ] subnetwork information for this link? as you noticed, this is an implementation issue. and get aournd those implementation, one can assign an ipv4 address on the LAN interface, and "inject" that ipv4 address in the IIH which is on the same subnet as your neighbors. as far as i know, there is no ipv6 only routers yet, get an ipv4 address on the LAN interface does not mean the router need to switch ipv4 traffic, it can still be a ipv6 only M-ISIS node. for any new routing scheme, we can not expect a flag day to upgrage all the nodes with new software. any scheme HAS to co-exist with the current/legacy software. new software has the flexibility to do "tricks" to work with the old software. going forward, as i mentioned in my previous email post, it's better to get rid of the restriction on setting up LAN adjacencies. just set up them all, to use them or not, it's a local issue(e.g. if the node does not like neighbor's IP subnet, then don't put a pnode tlv in it's lsp). Les has answered the below question. thanks. ] ] > don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4 ] > neighbor will fail on backlink check during the SPF, thus will not ] > use you as a nexthop. ] ] I know OSPFv2 specification has the "link back check" in ] the spec, RFC 2328 section 16.1(p. 163). ] ] But I didn't see it in ISO 10589 nor RFC 1195. ] ] Could you point out where it's documented or is that an ] unwritten spec? - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 06:15:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17740 for ; Wed, 5 Feb 2003 06:15:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BJ8J15378; Wed, 5 Feb 2003 06:19:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15BIqJ15362 for ; Wed, 5 Feb 2003 06:18:52 -0500 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17584 for ; Wed, 5 Feb 2003 06:12:19 -0500 (EST) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h15BEg717421; Wed, 5 Feb 2003 12:14:42 +0100 From: Hannes Gredler To: Philip Christian Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Message-ID: <20030205111442.GA17397@juniper.net> References: <20030205102334.15336.qmail@iname.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205102334.15336.qmail@iname.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, 5 Feb 2003 12:14:42 +0100 On Wed, Feb 05, 2003 at 10:23:34AM +0000, Philip Christian wrote: | I also have serious problems with this draft. | | 1. Integrated IS-IS was originally architected as an "Integrated" routing protocol to route both CLNP and IPv4 in a single SPF. The problem of running IPv4 and IPv6 together is not a new problem, it is actually exactly the same one that RFC 1195 was originally written to deal with (but with v4 and CLNP). Integrated IS-IS will work just as well with v4 and v6 as it did with v4 and CLNP. This draft attempts to unravel this behaviour by having separate SPFs. This is contrary to the original architecture of Integrated IS-IS (it isn't even "integrated") and contrary to section 3.10 of RFC 1195 where it says | "The Dijkstra computation does not take into consideration whether a | router is IP-only, OSI-only, or dual. The topological restrictions | specified in section 1.4 ensure that IP packets will only be sent via | IP-capable routers, and OSI packets will only be sent via OSI-capable | routers." | | This is not just some detail, but a fundamental behaviour of the protocol. ^^^^^^^^^ i'd call it a fundamental flaw - stating "all nodes have to support all the protocols" is practically speaking non-sense as it ignores the fact that large networks cannot be transitioned on a flag-day; today, the main purpose of the MT today is incremental transition; | Consequently there is no interoperability between this draft and RFC 1195. | | 2. If one wants to run separate SPFs for v4 and v6 then there are easier ways to do it. You could put all of the v4 nodes in one area and all the v6 nodes in another. Then you could just make a dual router with two SPFs that participates in both areas. Or you could use the existing MT draft. Or you could just use OSPF. on a 600+ router L2 network ? | 3. The draft isn't even honest enough to state that it will not interoperate with existing RFC 1195 implementations, nor with G.7712, nor with auto-encap. If there is some non-interoperability introduced then it should be clearly stated up front. compliance to rfc1195, which is flawed in that respect, is not desired; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 08:49:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25015 for ; Wed, 5 Feb 2003 08:49:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15DrdJ25973; Wed, 5 Feb 2003 08:53:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15DquJ25943 for ; Wed, 5 Feb 2003 08:52:56 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24899 for ; Wed, 5 Feb 2003 08:46:27 -0500 (EST) Received: from extremenetworks.com (unknown [10.18.3.100]) by gnat.inet.org (Postfix) with ESMTP id 3D65367105; Wed, 5 Feb 2003 09:00:01 -0500 (EST) Subject: Re: [Isis-wg] new version of the proprietary/experimental draft ... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "ISIS-WG (E-mail)" To: prz@net4u.ch From: RJ Atkinson In-Reply-To: <3E40614B.3050401@net4u.ch> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, 5 Feb 2003 08:50:03 -0500 Content-Transfer-Encoding: 7bit On Tuesday, Feb 4, 2003, at 19:56 America/Montreal, Tony Przygienda wrote: > . given that we have RFC 2026, a nice track exists where the > publication of the experimental > TLV is not even bound by having made it into the workgroup. The > authors can and should send > the experimental TLV description directly to the IETF editor so > the hurdle to document the work is absolutely minimal. That will merit > a section in the document > as well. s/IETF Editor/RFC Editor/ The process is basically this: - One writes up one's experimental TLV in an Internet-Draft. That Internet-Draft does not need to give the IETF rights to create any derivative works or give away any IPR. The I-D should say that it is describing an "experimental protocol extension to IS-IS" (or similar words) in order to avoid creating confusion about whether it is an IETF standards-track spec. - One submits the I-D as draft---00.txt - Then the author of the I-D asks the RFC Editor to publish the I-D as an RFC. This is normally just an email note. - The RFC-Editor will pass the I-D to the IESG for a review (which MUST be completed by IESG in a defined period of time) where the IESG is supposed to ONLY ensure that the document is NOT an "end-run" around active standards-track work already ongoing inside IS-IS WG. - If no problem arises, then the RFC-Editor will publish as an RFC. So this lets folks define implementation-specific extensions and get non-conflicting TLV space for those extensions, but does so in a way that lets the operators/users have a decent chance of understanding what the extension is doing so the operators/users are able to make informed decisions about what to deploy in their networks. Ran rja@extremenetworks.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 09:16:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26045 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 09:16:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EKEJ27822; Wed, 5 Feb 2003 09:20:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15EJsJ27737 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 09:19:54 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25930 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 09:13:24 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15EHsoA026440; Wed, 5 Feb 2003 09:17:54 -0500 (EST) Received: from jlearman-w2k01.cisco.com (rtp-vpn1-516.cisco.com [10.82.226.4]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ01497; Wed, 5 Feb 2003 09:16:59 -0500 (EST) Message-Id: <4.3.2.7.2.20030205090115.017d5710@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" <philip.christian@iname.com> From: Jeff Learman <jlearman@cisco.com> Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org In-Reply-To: <20030205102334.15336.qmail@iname.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 09:13:42 -0500 At 05:23 AM 2/5/2003, Philip Christian wrote: >I also have serious problems with this draft. > >1. Integrated IS-IS was originally architected as an "Integrated" routing protocol to route both CLNP and IPv4 in a single SPF. The problem of running IPv4 and IPv6 together is not a new problem, it is actually exactly the same one that RFC 1195 was originally written to deal with (but with v4 and CLNP). Integrated IS-IS will work just as well with v4 and v6 as it did with v4 and CLNP. This draft attempts to unravel this behaviour by having separate SPFs. This is contrary to the original architecture of Integrated IS-IS (it isn't even "integrated") and contrary to section 3.10 of RFC 1195 where it says > > "The Dijkstra computation does not take into consideration whether a > router is IP-only, OSI-only, or dual. The topological restrictions > specified in section 1.4 ensure that IP packets will only be sent via > IP-capable routers, and OSI packets will only be sent via OSI-capable > routers." > >This is not just some detail, but a fundamental behaviour of the protocol. > >Consequently there is no interoperability between this draft and RFC 1195. I disagree. An implementation that runs multiple SPFs will interoperate perfectly with one that doesn't in any topology that meets 1195's deployment restrictions, so there is NO interoperability problem until you go BEYOND RFC-1195. I have long been a supporter of running multiple SPFs (personally, not as a spokesman for Cisco). However, it is clear to me that there is little or no support for this idea among router vendors. My suspicion now is that many IPV4/IPV6 migration issues can be mitigated by use of MPLS, and new complex schemes to allow arbitrary topologies are unnecessary. Regards, Jeff >2. If one wants to run separate SPFs for v4 and v6 then there are easier ways to do it. You could put all of the v4 nodes in one area and all the v6 nodes in another. Then you could just make a dual router with two SPFs that participates in both areas. Or you could use the existing MT draft. Or you could just use OSPF. > >3. The draft isn't even honest enough to state that it will not interoperate with existing RFC 1195 implementations, nor with G.7712, nor with auto-encap. If there is some non-interoperability introduced then it should be clearly stated up front. > >Regards, Philip Christian > > > >----- Original Message ----- >From: Naiming Shen <naiming@redback.com> >Date: Tue, 04 Feb 2003 22:42:21 -0800 >To: Noguchi Kay <kay@ipinfusion.com> >Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt > > >Hi Kay, > > ] > on a Lan media, just announce all the possible NLPIDs, but only MT ID for > ] > IPv6. > ] > ] Two questions for this. > ] > ] 1) How to get the "all the possible NLPIDs" and what is the value > ] which M-ISIS software only support IPv6 puts in for this case? > ] > ] IPv4 and IPv6 NLPIDs or IPv4 NLPID only? > >NLPIDs for both v4 and v6. the adjacency status will be determined by >the MT status. > > ] > ] 2) Some implementation checks if the IP Interface Address TLV is > ] in the same subnetwork or not to form an adjacency as > ] stated in draft-ietf-isis-ip-interoperable-00.txt section 13. > ] > ] How does M-ISIS software which only supports IPv6 get the IPv4 > ] subnetwork information for this link? > >as you noticed, this is an implementation issue. and get aournd those >implementation, one can assign an ipv4 address on the LAN interface, >and "inject" that ipv4 address in the IIH which is on the same subnet >as your neighbors. as far as i know, there is no ipv6 only routers yet, >get an ipv4 address on the LAN interface does not mean the router >need to switch ipv4 traffic, it can still be a ipv6 only M-ISIS node. > >for any new routing scheme, we can not expect a flag day to upgrage >all the nodes with new software. any scheme HAS to co-exist with the >current/legacy software. new software has the flexibility to do "tricks" >to work with the old software. > >going forward, as i mentioned in my previous email post, it's better >to get rid of the restriction on setting up LAN adjacencies. just set >up them all, to use them or not, it's a local issue(e.g. if the node does >not like neighbor's IP subnet, then don't put a pnode tlv in it's lsp). > >Les has answered the below question. > >thanks. > > ] > ] > don't put IPv4 IS pnode neighbor TLV in the LSP, so your IPv4 > ] > neighbor will fail on backlink check during the SPF, thus will not > ] > use you as a nexthop. > ] > ] I know OSPFv2 specification has the "link back check" in > ] the spec, RFC 2328 section 16.1(p. 163). > ] > ] But I didn't see it in ISO 10589 nor RFC 1195. > ] > ] Could you point out where it's documented or is that an > ] unwritten spec? > >- Naiming >_______________________________________________ >Isis-wg mailing list >Isis-wg@ietf.org >https://www1.ietf.org/mailman/listinfo/isis-wg > >-- >__________________________________________________________ >Sign-up for your own FREE Personalized E-mail at Mail.com >http://www.mail.com/?sr=signup > >_______________________________________________ >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 Feb 5 11:02:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29521 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 11:02:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15G5eJ02083; Wed, 5 Feb 2003 11:05:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15G4aJ02048 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 11:04:36 -0500 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29353 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 10:58:04 -0500 (EST) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h15G17m19044; Wed, 5 Feb 2003 17:01:07 +0100 From: Hannes Gredler <hannes@juniper.net> To: Jeff Learman <jlearman@cisco.com> Cc: Philip Christian <philip.christian@iname.com>, naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Message-ID: <20030205160107.GA19024@juniper.net> References: <20030205102334.15336.qmail@iname.com> <4.3.2.7.2.20030205090115.017d5710@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.20030205090115.017d5710@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 5 Feb 2003 17:01:07 +0100 On Wed, Feb 05, 2003 at 09:13:42AM -0500, Jeff Learman wrote: | >Consequently there is no interoperability between this draft and RFC 1195. | | I disagree. An implementation that runs multiple SPFs will interoperate | perfectly with one that doesn't in any topology that meets 1195's | deployment restrictions, so there is NO interoperability problem until | you go BEYOND RFC-1195. | | I have long been a supporter of running multiple SPFs (personally, not | as a spokesman for Cisco). However, it is clear to me that there is | little or no support for this idea among router vendors. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ i know about at least one implementation which supports per-topo SPF runs ;-) /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 15:12:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08945 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 15:12:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KCoJ19738; Wed, 5 Feb 2003 15:12:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KBwJ19674 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 15:11:58 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08655 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 15:05:22 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18gVqp-0003aY-00; Wed, 05 Feb 2003 12:08:55 -0800 Message-ID: <877kceij6x.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: Naiming Shen <naiming@redback.com> Cc: Noguchi Kay <kay@ipinfusion.com>, stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030205064221.472B83FAC8@prattle.redback.com> References: <kay@ipinfusion.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 12:08:54 -0800 Hi Naimimg, This is Kay. > ] > on a Lan media, just announce all the possible NLPIDs, but only MT ID for > ] > IPv6. > ] > ] Two questions for this. > ] > ] 1) How to get the "all the possible NLPIDs" and what is the value > ] which M-ISIS software only support IPv6 puts in for this case? > ] > ] IPv4 and IPv6 NLPIDs or IPv4 NLPID only? > > NLPIDs for both v4 and v6. the adjacency status will be determined by > the MT status. But how to adjacent with legacy IPv4/IPv6 IS-IS software which enables IPv4 routing but disables IPv6 routing. In this case, legacy software means the software doesn't support M-ISIS capability. That kind of legacy software doesn't allow to make adjacent with neighbors which contains IPv4 and IPv6 NLPIDs in IIH Protocols Supported TLV. Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 15:20:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09288 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 15:20:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KM4J20201; Wed, 5 Feb 2003 15:22:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KL3J20150 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 15:21:03 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09093 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 15:14:26 -0500 (EST) Received: (qmail 12870 invoked from network); 5 Feb 2003 20:18:00 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 5 Feb 2003 20:18:00 -0000 Received: (qmail 57188 invoked from network); 5 Feb 2003 20:04:06 -0000 Received: from unknown (HELO ws1-3.us4.outblaze.com) (205.158.62.55) by 205-158-62-153.outblaze.com with SMTP; 5 Feb 2003 20:04:06 -0000 Received: (qmail 7218 invoked by uid 1001); 5 Feb 2003 20:04:06 -0000 Message-ID: <20030205200406.7217.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [62.136.232.66] by ws1-3.us4.outblaze.com with http for philip.christian@iname.com; Wed, 05 Feb 2003 20:04:05 +0000 From: "Philip Christian" <philip.christian@iname.com> To: jlearman@cisco.com Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt X-Originating-Ip: 62.136.232.66 X-Originating-Server: ws1-3.us4.outblaze.com 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 20:04:05 +0000 Content-Transfer-Encoding: 7bit > > I disagree. An implementation that runs multiple SPFs will interoperate > perfectly with one that doesn't in any topology that meets 1195's > deployment restrictions, so there is NO interoperability problem until > you go BEYOND RFC-1195. Jeff, if a network meets 1195 deployment restrictions, then you don't need multiple SPFs. The whole justification of multiple SPFs is that it allows you to break the 1195 deployment restrictions. Once you do this then you cannot install a legacy 1195 box in the network, because you can't stop a legacy v4 node plotted a shortest path through a v6 only box. If you read the Noguchi draft then its whole justification is that it allows one to break 1195 restrictions. What you say is technically true but no defense of the Noguchi draft. > > I have long been a supporter of running multiple SPFs (personally, not > as a spokesman for Cisco). However, it is clear to me that there is > little or no support for this idea among router vendors. > There is more to the Noguchi draft than multiple SPFs. It says that two ISs MUST form an adjacency irrespective of protocols supported. Last time I looked Cisco's implementation looked for an overlap of at least one of NLPIDs, which also is exactly what G.7712 says to do. It will not be possible for an implementation to conform to both G.7712 and to the Noguchi draft. > My suspicion now is that many IPV4/IPV6 migration issues can be > mitigated by use of MPLS, and new complex schemes to allow arbitrary > topologies are unnecessary. > True. I also believe that the MT draft will allow folks to define that a subset of their network can route IPv6. This WILL interwork with legacy nodes. The Noguchi draft simply isn't needed as MT already does it. If one wants to have multiple SPFs then no new standard is necessary, just use the MT draft. With a combination of MT and autoencap then you have something very powerful. You can have a general IPv4 legacy network. Then you can use MT to define some nodes to be IPv6 and limit v6 to them. The legacy nodes won't understand the MT and so will route through them anyway. Then you use autoencap to autotunnel IPv4 through any IPv6-only MT nodes that happen to get in the way. Philip -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 15:39:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09925 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 15:39:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Kf8J21726; Wed, 5 Feb 2003 15:41:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15KeFJ21697 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 15:40:15 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09742 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 15:33:38 -0500 (EST) Received: (qmail 16873 invoked from network); 5 Feb 2003 20:37:12 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 5 Feb 2003 20:37:12 -0000 Received: (qmail 51410 invoked from network); 5 Feb 2003 20:25:55 -0000 Received: from unknown (HELO ws1-3.us4.outblaze.com) (205.158.62.55) by 205-158-62-153.outblaze.com with SMTP; 5 Feb 2003 20:25:55 -0000 Received: (qmail 34585 invoked by uid 1001); 5 Feb 2003 20:25:55 -0000 Message-ID: <20030205202555.34584.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [62.136.232.66] by ws1-3.us4.outblaze.com with http for philip.christian@iname.com; Wed, 05 Feb 2003 20:25:55 +0000 From: "Philip Christian" <philip.christian@iname.com> To: hannes@juniper.net Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt X-Originating-Ip: 62.136.232.66 X-Originating-Server: ws1-3.us4.outblaze.com 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 20:25:55 +0000 Content-Transfer-Encoding: 7bit > | > | 2. If one wants to run separate SPFs for v4 and v6 then there are easier ways to do it. You could put all of the v4 nodes in one area and all the v6 nodes in another. Then you could just make a dual router with two SPFs that participates in both areas. Or you could use the existing MT draft. Or you could just use OSPF. > > on a 600+ router L2 network ? > Please can you explain what the Noguchi draft buys you on a 600+ L2 network that MT doesn't. Also you could run level-2 IS-IS for IPv4 and OSPFv3 for IPv6, or you could use different authentication fields for IPv4, IPv6 and dual and make a kind of "do-it-yourself" level-3 routing. Philip -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 17:20:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13154 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 17:20:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15MOGp01945; Wed, 5 Feb 2003 17:24:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15MJfp01796 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 17:19:41 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12959 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 17:13:01 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 66D9F3E9B28; Wed, 5 Feb 2003 14:16:38 -0800 (PST) To: Noguchi Kay <kay@ipinfusion.com> Cc: stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay <kay@ipinfusion.com> dated Wed, 05 Feb 2003 12:08:54 PST <877kceij6x.wl@giga.kayz.org> From: Naiming Shen <naiming@redback.com> Message-Id: <20030205221638.66D9F3E9B28@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 14:16:38 -0800 Kay, ] ] > ] > on a Lan media, just announce all the possible NLPIDs, but only MT ID for ] > ] > IPv6. ] > ] ] > ] Two questions for this. ] > ] ] > ] 1) How to get the "all the possible NLPIDs" and what is the val ue ] > ] which M-ISIS software only support IPv6 puts in for this cas e? ] > ] ] > ] IPv4 and IPv6 NLPIDs or IPv4 NLPID only? ] > ] > NLPIDs for both v4 and v6. the adjacency status will be determined by ] > the MT status. ] ] But how to adjacent with legacy IPv4/IPv6 IS-IS software which ] enables IPv4 routing but disables IPv6 routing. ] ] In this case, legacy software means the software doesn't support ] M-ISIS capability. ] ] That kind of legacy software doesn't allow to make adjacent ] with neighbors which contains IPv4 and IPv6 NLPIDs in IIH ] Protocols Supported TLV. do you have information on which vendor's isis software actually does that (not forming adjacency because neighbor supports more than my own nlpid) ? thanks. ] ] Thank you, ] ] kay ] _______________________________________________ ] 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 Feb 5 17:41:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14000 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 17:41:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mj7p03532; Wed, 5 Feb 2003 17:45:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mi6p03486 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 17:44:06 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13849 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 17:37:26 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15Mft1C011816; Wed, 5 Feb 2003 17:41:55 -0500 (EST) Received: from jlearman-w2k01.cisco.com (dhcp-64-102-222-215.cisco.com [64.102.222.215]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ17629; Wed, 5 Feb 2003 17:40:59 -0500 (EST) Message-Id: <4.3.2.7.2.20030205152624.01692888@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Philip Christian" <philip.christian@iname.com> From: Jeff Learman <jlearman@cisco.com> Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org In-Reply-To: <20030205200406.7217.qmail@iname.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 17:30:27 -0500 At 03:04 PM 2/5/2003, Philip Christian wrote: >> >> I disagree. An implementation that runs multiple SPFs will interoperate >> perfectly with one that doesn't in any topology that meets 1195's >> deployment restrictions, so there is NO interoperability problem until >> you go BEYOND RFC-1195. > >Jeff, if a network meets 1195 deployment restrictions, then you don't need multiple SPFs. The whole justification of multiple SPFs is that it allows you to break the 1195 deployment restrictions. Once you do this then you cannot install a legacy 1195 box in the network, because you can't stop a legacy v4 node plotted a shortest path through a v6 only box. If you read the Noguchi draft then its whole justification is that it allows one to break 1195 restrictions. What you say is technically true but no defense of the Noguchi draft. "Technically true" is important. While the draft has interoperability problems with 1195, they are unrelated to running multiple SPFs. If these other problems were fixed, you could drop that implementation into an 1195-compliant network and it would work. This is a very important issue, and not just a technicality, because we sell routers for different markets. Some customers require multiprotocol support, some don't. Any solution should work well for both. Regards, Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 17:41:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14015 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 17:41:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mj8p03548; Wed, 5 Feb 2003 17:45:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mi7p03490 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 17:44:07 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13848 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 17:37:26 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15MftoE011823; Wed, 5 Feb 2003 17:41:55 -0500 (EST) Received: from jlearman-w2k01.cisco.com (dhcp-64-102-222-215.cisco.com [64.102.222.215]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ17628; Wed, 5 Feb 2003 17:40:58 -0500 (EST) Message-Id: <4.3.2.7.2.20030205160011.017d2780@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: kay@ipinfusion.com From: Jeff Learman <jlearman@cisco.com> Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Cc: isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030205155931.01778c48@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 17:40:55 -0500 With the exception of the capability to support different protocols on different interfaces, I have advocated this solution like since I first read RFC-1195. However, that was way too late to change 1195, and by the time I brought it up in this forum, it was considered a bad idea by most. It was not a new idea at that time. In most cases, the reasons were related to existing implementations rather than the merits of the solution. One disadvantage that was pointed out was that in order for it to work, you need network of connectivity for each protocol, considered separately. I don't think that's such a big disadvantage, and it avoids unnecessary tunneling that Philip's solution can entail. But it does not automatically close gaps like Philip's solution. (Philip's solution was driven by a valid requirement to be able to handle gaps due to specific problems that occur in SONET management networks, which may or may not be representative of the way IP networks are planned and deployed.) One of the biggest sticking points is the need to form an adjacency even when IP subnet addresses don't match. While there is no theoretical need for this match, the practical reality is that IP router implementations expect neighbors to have IP addresses with matching subnets and which support ARP. Any proposal that requires a change to this behavior is not likely to be supported by the major vendors. It would dictate a more radical implementation change than you might think. The ability to support different protocols on different interfaces complicates the subject considerably, especially with respect to interoperability, legacy issues, and configuration difficulties. We want to build routers so that there are as few knobs as possible that have to be set correctly in order for the router to work. This solution requires that you turn the special behavior for this RFC on or off in order to work well with existing implementations. It would be better to try to avoid that if possible. (Note that the only reason this proposal has interoperability problems in 1995-supported networks is that it omits the necessary Protocol Supported TLVs.) On the other hand, this ability might be very important for today's distributed implementations, where all protocols might not be supportable on all interface types. Of course, it doesn't interoperate with Philip's ITU spec, which requires the typical behavior (not specified in 1195) of rejecting adjacencies when there are no protocols in common. More comments below, if you're serious about pursuing this. More detail is required in the behavioral sections. As it is, it's rather ambiguous, especially how it should operate in a "normal" (e.g., single-protocol) network alongside legacy equipment. I believe all these details shouldn't be too hard to work out. But different people would work them out quite differently! Regards, Jeff >Abstract > > RFC 1195 [1] documents a dual routing protocol that can be used to > route both CLNP and IPv4, that is Integrated IS-IS. [2] adds > functionality to Integrated IS-IS so that it supports IPv6. > > RFC 1195 [1] places topological restrictions on networks that are > routed using Integrated IS-IS, specifically, that every router in a > level-1 area must be capable of all network layer protocols that are > present in that area, and every router in a level-2 area must be > capable of all network layer protocols that are present in the whole > IS-IS routing domain. > > The mechanism described in this document enables a single IS-IS > routing domain to support different network layer protocol topologies > by maintaining separate SPF trees for each network layer protocol. Furthermore, it no longer requires a router's protocol support to be identical for all interfaces. [Note that this is not necessary for multiple topologies.] >3 Maintaining Router Adjacency > > All routers MUST announce the interface-specific protocols-supported > capability in IS-IS Hello packet to build the concrete view of the > network layer protocol topology in the IS-IS routing domain. > > The "Interface Protocols Supported TLV" is introduced into the IS-IS > Hello packet for this purpose. It replaces the existing Protocols > Supported TLV that is prohibited from having different protocols- > capability for each interface as specified in RFC 1195 [1] section 4.4 > > Adjacency is made depending on with which interface the IS-IS Hello > packet is exchanged. Try this: The rules for adjacency formation are different for broadcast and point-to-point interfaces. >3.1 Maintaining Adjacencies on Point-to-Point interfaces > > On point-to-point interfaces, all routers MUST be adjacent if the > neighboring router supports at least one of the same interface- > specific protocols-supported capabilities reported by "Interface > Protocols Supported TLV" in IS-IS Hello packet. This isn't clear. It says that routers "MUST be adjacent" -- I think you mean that they must attempt to form an adjacency. Do you mean to imply that an adjacency MUST be rejected if there are no matching protocols? If so, you need to say it, because it's not strictly implied. Also, you need to say what to do if the conditions are NOT met and the adjacency is rejected. Also, note that a legacy implementation might accept the adjacency, since it will ignore the TLVs it doesn't recognize. You need to make it clear whether the old protocols-supported TLV should be included or excluded. Above you say it "replaces", but it isn't clear whether you mean that literally in the PDUs, or whether you mean that their function replaces the function of the old TLV. Hopefully you expect people to include the old option in addition to the new one. Otherwise there will be serious problems caused by simple configuration problems, because without the old option, an RFC-1195 compliant router is required to assume that the neighbor is an OSI-only router. You need to make a lot of behavior very clear here. >3.2 Maintaining Adjacencies on Broadcast interfaces > > On broadcast interfaces, all routers MUST be adjacent regardless of > the neighbor's interface-specific protocols-supported capability > reported by "Interface Protocols Supported TLV" in IS-IS Hello > packet. As above, "MUST be adjacent" isn't good spec-writing. Talk about what a router should do, not about what is true. Are two routers adjacent if they have a connecting link, or only if they form adjacencies with each other? Avoid that kind of confusion by stating specifically what they are required to do. In this case, what you mean is: A router MUST NOT check Interface Protocols Supported TLVs for a protocol match when deciding whether to accept or reject a received IIH PDU. You must state exactly what the router should do if it receives a PDU with the old TLV present, or with both old and new TLV present (if that is permitted -- and if it isn't, then there will be a LOT of problems!) > There is no change regarding Designated IS selection, CSNP and CSNP > with ISO 10589 [3]. > > >4 Advertising Protocols Supported Sub-TLV in Extended IS Reachability > TLV > > The routing capability of network layer protocols between two > neighboring routers MUST be encoded by "Protocols Supported Sub-TLV" > in the Extended IS Reachability TLV [4]. This sub-TLV replaces the > existing Protocols Supported TLV in LSP that contains only the node- > specific routing capability of the network layer protocols. > > Encoding is made differently depending on which network the > neighboring router exists on. I think you mean: The rules for encoding this sub-TLV depend on the type of interface. Note that "which network" does NOT mean "what type of network". >4.1 Protocols Supported Sub-TLV for Point-to-Point Interface Neighbors > > On point-to-point interfaces, "Protocols Supported Sub-TLV" MUST be > encoded by ORing the local side of interface-specific protocols- > supported capability with the remote side of interface-specific > protocols-supported capability, which is reported by the "Interface > Protocols Supported TLV" in the neighboring router's IS-IS Hello > packet. Don't you mean AND-ing? If I support IPV4 and OSI and he supports IPV4 and IPV6, then I mark all three protocols? I doubt it! Regards, Jeff _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 5 17:54:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14540 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 17:54:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15Mx4p04101; Wed, 5 Feb 2003 17:59:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h15MwDp04037 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 17:58:13 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14413 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 17:51:32 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h15Mu3jr013342; Wed, 5 Feb 2003 17:56:03 -0500 (EST) Received: from jlearman-w2k01.cisco.com (dhcp-64-102-222-215.cisco.com [64.102.222.215]) by dingdong.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ABJ18040; Wed, 5 Feb 2003 17:55:07 -0500 (EST) Message-Id: <4.3.2.7.2.20030205174951.01788328@dingdong.cisco.com> X-Sender: jlearman@dingdong.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: isis-wg@ietf.org, kay@ipinfusion.com From: Jeff Learman <jlearman@cisco.com> Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Cc: kay@ipinfusion.com, isis-wg@ietf.org In-Reply-To: <4.3.2.7.2.20030205160011.017d2780@dingdong.cisco.com> References: <4.3.2.7.2.20030205155931.01778c48@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 05 Feb 2003 17:55:05 -0500 Sorry, should have proofread first ... At 05:40 PM 2/5/2003, Jeff Learman wrote: >With the exception of the capability to support different protocols on >different interfaces, I have advocated this solution since I first >read RFC-1195. However, that was way too late to change 1195, and >by the time I brought it up in this forum, it was considered a bad >idea by most. It was not a new idea at that time. > >In most cases, the reasons were related to existing implementations >rather than the merits of the solution. One disadvantage that was >pointed out was that in order for it to work, you need network >of connectivity for each protocol, considered separately. I don't >think that's such a big disadvantage, and it avoids unnecessary >tunneling that Philip's solution can entail. But it does not >automatically close gaps like Philip's solution. (Philip's >solution was driven by a valid requirement to be able to handle >gaps due to specific problems that occur in SONET management networks, >which may or may not be representative of the way IP networks are >planned and deployed.) > >One of the biggest sticking points is the need to form an adjacency >even when IP subnet addresses don't match. While there is no >theoretical need for this match, the practical reality is that >IP router implementations expect neighbors to have IP addresses with >matching subnets and which support ARP. Any proposal that requires >a change to this behavior is not likely to be supported by the major >vendors. It would dictate a more radical implementation change than >you might think. > >The ability to support different protocols on different interfaces >complicates the subject considerably, especially with respect to >interoperability, legacy issues, and configuration difficulties. >We want to build routers so that there are as few knobs as possible >that have to be set correctly in order for the router to work. This >solution requires that you turn the special behavior for this RFC >on or off in order to work well with existing implementations. >It would be better to try to avoid that if possible. (Note that >the only reason this proposal has interoperability problems in >1995-supported networks is that it omits the necessary Protocol 1195-supported ... >Supported TLVs.) On the other hand, this ability might be very >important for today's distributed implementations, where all >protocols might not be supportable on all interface types. > >Of course, it doesn't interoperate with Philip's ITU spec, which >requires the typical behavior (not specified in 1195) of rejecting >adjacencies when there are no protocols in common. > >More comments below, if you're serious about pursuing this. >More detail is required in the behavioral sections. As it is, >it's rather ambiguous, especially how it should operate in a "normal" >(e.g., single-protocol) network alongside legacy equipment. I believe >all these details shouldn't be too hard to work out. But different >people would work them out quite differently! > >Regards, >Jeff > >>Abstract >> >> RFC 1195 [1] documents a dual routing protocol that can be used to >> route both CLNP and IPv4, that is Integrated IS-IS. [2] adds >> functionality to Integrated IS-IS so that it supports IPv6. >> >> RFC 1195 [1] places topological restrictions on networks that are >> routed using Integrated IS-IS, specifically, that every router in a >> level-1 area must be capable of all network layer protocols that are >> present in that area, and every router in a level-2 area must be >> capable of all network layer protocols that are present in the whole >> IS-IS routing domain. >> >> The mechanism described in this document enables a single IS-IS >> routing domain to support different network layer protocol topologies >> by maintaining separate SPF trees for each network layer protocol. > > Furthermore, it no longer requires a router's protocol support to > be identical for all interfaces. > >[Note that this is not necessary for multiple topologies.] > > >>3 Maintaining Router Adjacency >> >> All routers MUST announce the interface-specific protocols-supported >> capability in IS-IS Hello packet to build the concrete view of the >> network layer protocol topology in the IS-IS routing domain. >> >> The "Interface Protocols Supported TLV" is introduced into the IS-IS >> Hello packet for this purpose. It replaces the existing Protocols >> Supported TLV that is prohibited from having different protocols- >> capability for each interface as specified in RFC 1195 [1] section 4.4 >> >> Adjacency is made depending on with which interface the IS-IS Hello >> packet is exchanged. > >Try this: > > The rules for adjacency formation are different for broadcast > and point-to-point interfaces. > > >>3.1 Maintaining Adjacencies on Point-to-Point interfaces >> >> On point-to-point interfaces, all routers MUST be adjacent if the >> neighboring router supports at least one of the same interface- >> specific protocols-supported capabilities reported by "Interface >> Protocols Supported TLV" in IS-IS Hello packet. > >This isn't clear. It says that routers "MUST be adjacent" -- I think >you mean that they must attempt to form an adjacency. Do you mean to >imply that an adjacency MUST be rejected if there are no matching >protocols? If so, you need to say it, because it's not strictly >implied. Also, you need to say what to do if the conditions are NOT >met and the adjacency is rejected. Also, note that a legacy implementation >might accept the adjacency, since it will ignore the TLVs it doesn't >recognize. > >You need to make it clear whether the old protocols-supported TLV >should be included or excluded. Above you say it "replaces", but >it isn't clear whether you mean that literally in the PDUs, or >whether you mean that their function replaces the function of the >old TLV. > >Hopefully you expect people to include the old option in addition >to the new one. Otherwise there will be serious problems caused >by simple configuration problems, because without the old option, >an RFC-1195 compliant router is required to assume that the neighbor >is an OSI-only router. > >You need to make a lot of behavior very clear here. > >>3.2 Maintaining Adjacencies on Broadcast interfaces >> >> On broadcast interfaces, all routers MUST be adjacent regardless of >> the neighbor's interface-specific protocols-supported capability >> reported by "Interface Protocols Supported TLV" in IS-IS Hello >> packet. > >As above, "MUST be adjacent" isn't good spec-writing. Talk about >what a router should do, not about what is true. Are two routers >adjacent if they have a connecting link, or only if they form >adjacencies with each other? Avoid that kind of confusion by >stating specifically what they are required to do. In this case, >what you mean is: > > A router MUST NOT check Interface Protocols Supported TLVs > for a protocol match when deciding whether to accept or reject > a received IIH PDU. > >You must state exactly what the router should do if it receives >a PDU with the old TLV present, or with both old and new TLV >present (if that is permitted -- and if it isn't, then there >will be a LOT of problems!) > >> There is no change regarding Designated IS selection, CSNP and CSNP >> with ISO 10589 [3]. >> >> >>4 Advertising Protocols Supported Sub-TLV in Extended IS Reachability >> TLV >> >> The routing capability of network layer protocols between two >> neighboring routers MUST be encoded by "Protocols Supported Sub-TLV" >> in the Extended IS Reachability TLV [4]. This sub-TLV replaces the >> existing Protocols Supported TLV in LSP that contains only the node- >> specific routing capability of the network layer protocols. >> >> Encoding is made differently depending on which network the >> neighboring router exists on. > >I think you mean: > > The rules for encoding this sub-TLV depend on the type of > interface. > >Note that "which network" does NOT mean "what type of network". > >>4.1 Protocols Supported Sub-TLV for Point-to-Point Interface Neighbors >> >> On point-to-point interfaces, "Protocols Supported Sub-TLV" MUST be >> encoded by ORing the local side of interface-specific protocols- >> supported capability with the remote side of interface-specific >> protocols-supported capability, which is reported by the "Interface >> Protocols Supported TLV" in the neighboring router's IS-IS Hello >> packet. > >Don't you mean AND-ing? If I support IPV4 and OSI and he supports IPV4 >and IPV6, then I mark all three protocols? I doubt it! > >Regards, >Jeff > > >_______________________________________________ >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 Feb 5 22:23:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20546 for <isis-archive@lists.ietf.org>; Wed, 5 Feb 2003 22:23:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h163Obp17259; Wed, 5 Feb 2003 22:24:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h163NTp17208 for <isis-wg@optimus.ietf.org>; Wed, 5 Feb 2003 22:23:29 -0500 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20448 for <isis-wg@ietf.org>; Wed, 5 Feb 2003 22:16:42 -0500 (EST) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h163IqG20618; Thu, 6 Feb 2003 04:18:52 +0100 From: Hannes Gredler <hannes@juniper.net> To: Philip Christian <philip.christian@iname.com> Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt Message-ID: <20030206031852.GA20591@juniper.net> References: <20030205202555.34584.qmail@iname.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205202555.34584.qmail@iname.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 6 Feb 2003 04:18:52 +0100 On Wed, Feb 05, 2003 at 08:25:55PM +0000, Philip Christian wrote: | > | | > | 2. If one wants to run separate SPFs for v4 and v6 then there are easier ways to do it. You could put all of the v4 nodes in one area and all the v6 nodes in another. Then you could just make a dual router with two SPFs that participates in both areas. Or you could use the existing MT draft. Or you could just use OSPF. | > | > on a 600+ router L2 network ? | > | Please can you explain what the Noguchi draft buys you on a 600+ L2 network that MT doesn't. thats was not the point; it is the other way around - using MT i got the possibility for _incremental transition_, which is all i need; the noguchi draft is IMHO redundant as it does not provide a fix any new problem; | Also you could run level-2 IS-IS for IPv4 and OSPFv3 for IPv6, or you could use different authentication fields for IPv4, IPv6 and dual and make a kind of "do-it-yourself" level-3 routing. you're right thats technical possible, however administratively no desirable, which is why most customers would reject that kind of ideas; /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 6 05:01:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10758 for <isis-archive@lists.ietf.org>; Thu, 6 Feb 2003 05:01:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16A2lp17437; Thu, 6 Feb 2003 05:02:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16A1Bp17400 for <isis-wg@optimus.ietf.org>; Thu, 6 Feb 2003 05:01:11 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10428 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 04:54:17 -0500 (EST) Received: (qmail 18852 invoked from network); 6 Feb 2003 09:57:53 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 6 Feb 2003 09:57:53 -0000 Received: (qmail 78515 invoked from network); 6 Feb 2003 09:57:53 -0000 Received: from unknown (HELO ws1-3.us4.outblaze.com) (205.158.62.55) by 205-158-62-153.outblaze.com with SMTP; 6 Feb 2003 09:57:53 -0000 Received: (qmail 41918 invoked by uid 1001); 6 Feb 2003 09:57:53 -0000 Message-ID: <20030206095753.41917.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [149.254.120.136] by ws1-3.us4.outblaze.com with http for philip.christian@iname.com; Thu, 06 Feb 2003 09:57:53 +0000 From: "Philip Christian" <philip.christian@iname.com> To: hannes@juniper.net Cc: naiming@redback.com, kay@ipinfusion.com, sprevidi@cisco.com, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt X-Originating-Ip: 149.254.120.136 X-Originating-Server: ws1-3.us4.outblaze.com 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 06 Feb 2003 09:57:53 +0000 Content-Transfer-Encoding: 7bit > > thats was not the point; > it is the other way around - using MT i got the possibility for > _incremental transition_, which is all i need; the noguchi draft > is IMHO redundant as it does not provide a fix any new problem; > It was my point, maybe not very well put. I think in actual fact that we agree. Folks have the choice to use vanilla Integrated IS-IS if they want a single SPF, or MT if they want multiple SPFs. Personally I think that I can live with that. Because vanilla IS-IS ignores the MT TLVs, and MT respects that there might be vanilla IS-IS around, I think that they can co-exist. I feel that the Noguchi draft is attempting to remove the choice of vanilla single SPF Integrated IS-IS and that is why I am against it. Please don't enterpret my critism of the Noguchi draft as criticism of MT, because it isn't. Philip -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 6 13:12:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28860 for <isis-archive@lists.ietf.org>; Thu, 6 Feb 2003 13:12:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16IHbp20688; Thu, 6 Feb 2003 13:17:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16IGBp20636 for <isis-wg@optimus.ietf.org>; Thu, 6 Feb 2003 13:16:11 -0500 Received: from psg.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28695 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 13:09:06 -0500 (EST) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18gqVt-0008tD-00; Thu, 06 Feb 2003 10:12:41 -0800 From: Alex Zinin <zinin@psg.com> X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin <zinin@psg.com> X-Priority: 3 (Normal) Message-ID: <14266790103.20030206101228@psg.com> To: RJ Atkinson <rja@extremenetworks.com> CC: prz@net4u.ch, "ISIS-WG (E-mail)" <isis-wg@ietf.org> Subject: Re: [Isis-wg] new version of the proprietary/experimental draft ... In-Reply-To: <BA57F13C-3910-11D7-B5CA-00039357A82A@extremenetworks.com> References: <BA57F13C-3910-11D7-B5CA-00039357A82A@extremenetworks.com> MIME-Version: 1.0 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 6 Feb 2003 10:12:28 -0800 Content-Transfer-Encoding: 7bit I'd like to support suggested change to the document. A bit of clarification to what Ran described below to make sure we have a complete picture: Wednesday, February 5, 2003, 5:50:03 AM, RJ Atkinson wrote: > On Tuesday, Feb 4, 2003, at 19:56 America/Montreal, Tony Przygienda > wrote: >> . given that we have RFC 2026, a nice track exists where the >> publication of the experimental >> TLV is not even bound by having made it into the workgroup. The >> authors can and should send >> the experimental TLV description directly to the IETF editor so >> the hurdle to document the work is absolutely minimal. That will merit >> a section in the document >> as well. > s/IETF Editor/RFC Editor/ > The process is basically this: > - One writes up one's experimental TLV in an Internet-Draft. That > Internet-Draft does not need to give the IETF rights to create any > derivative works or give away any IPR. The I-D should say that it is > describing an "experimental protocol extension to IS-IS" (or similar > words) > in order to avoid creating confusion about whether it is an IETF > standards-track spec. > - One submits the I-D as draft-<lastname>-<title>-00.txt > - Then the author of the I-D asks the RFC Editor to publish the I-D > as an RFC. This is normally just an email note. publish as an Informational RFC... > - The RFC-Editor will pass the I-D to the IESG for a review (which > MUST be completed by IESG in a defined period of time) where the IESG > is supposed to ONLY ensure that the document is NOT an "end-run" > around active standards-track work already ongoing inside IS-IS WG. not only standards-track work, any work inside the WG. Also, we usually do the end-run check by referring the document to the WG, i.e., sending a note to the WG asking to check. > - If no problem arises, then the RFC-Editor will publish as an RFC. > So this lets folks define implementation-specific extensions and get > non-conflicting > TLV space for those extensions, but does so in a way that lets the > operators/users > have a decent chance of understanding what the extension is doing so the > operators/users are able to make informed decisions about what to deploy > in their networks. Amen. Alex _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 6 15:36:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03367 for <isis-archive@lists.ietf.org>; Thu, 6 Feb 2003 15:36:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Kfkp29664; Thu, 6 Feb 2003 15:41:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h16Ke9p29626 for <isis-wg@optimus.ietf.org>; Thu, 6 Feb 2003 15:40:09 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03215 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 15:33:03 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18gsl1-00055e-00; Thu, 06 Feb 2003 12:36:27 -0800 Message-ID: <87wukdgn91.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: Naiming Shen <naiming@redback.com> Cc: Noguchi Kay <kay@ipinfusion.com>, stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030205221638.66D9F3E9B28@prattle.redback.com> References: <kay@ipinfusion.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 06 Feb 2003 12:36:26 -0800 Hi Naiming, This is Kay. > ] > NLPIDs for both v4 and v6. the adjacency status will be determined by > ] > the MT status. > ] > ] But how to adjacent with legacy IPv4/IPv6 IS-IS software which > ] enables IPv4 routing but disables IPv6 routing. > ] > ] In this case, legacy software means the software doesn't support > ] M-ISIS capability. > ] > ] That kind of legacy software doesn't allow to make adjacent > ] with neighbors which contains IPv4 and IPv6 NLPIDs in IIH > ] Protocols Supported TLV. > > do you have information on which vendor's isis software actually does > that (not forming adjacency because neighbor supports more than my > own nlpid) ? Before the implementation topic, could you point out which spec states it and how? Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 6 20:10:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11213 for <isis-archive@lists.ietf.org>; Thu, 6 Feb 2003 20:10:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171Esp14020; Thu, 6 Feb 2003 20:14:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h171DWp13964 for <isis-wg@optimus.ietf.org>; Thu, 6 Feb 2003 20:13:32 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11066 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 20:06:18 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id BD8C52AA640; Thu, 6 Feb 2003 17:09:57 -0800 (PST) To: Noguchi Kay <kay@ipinfusion.com> Cc: stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay <kay@ipinfusion.com> dated Thu, 06 Feb 2003 12:36:26 PST <87wukdgn91.wl@giga.kayz.org> From: Naiming Shen <naiming@redback.com> Message-Id: <20030207010957.BD8C52AA640@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 06 Feb 2003 17:09:57 -0800 Hi Kay, This is Naiming. ] > ] That kind of legacy software doesn't allow to make adjacent ] > ] with neighbors which contains IPv4 and IPv6 NLPIDs in IIH ] > ] Protocols Supported TLV. ] > ] > do you have information on which vendor's isis software actually does ] > that (not forming adjacency because neighbor supports more than my ] > own nlpid) ? ] ] Before the implementation topic, could you point out ] which spec states it and how? ] we are talking about backwards compatibility, so we are only dealing with existing systems. the goal is to solve real network problems(how to fit a new routing scheme into an existing network), not those theoretical ones. as far as i know of, dominant isis software out there does not care at all about some extra nlpids in hellos. if one has to document it, then it probably should be included in the "interoperability" drafts. it's "extremely" normal to do something the specs didn't state, and to ignore something the specs explicitly state. it only reflects the specs often need updates. thanks. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 6 21:58:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13609 for <isis-archive@lists.ietf.org>; Thu, 6 Feb 2003 21:58:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1732jp19322; Thu, 6 Feb 2003 22:02:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1730op19266 for <isis-wg@optimus.ietf.org>; Thu, 6 Feb 2003 22:00:50 -0500 Received: from dmz2.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13527 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 21:53:36 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1EC1434441 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 19:18:17 -0800 (PST) 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 h172vEDw002140 for <isis-wg@ietf.org>; Thu, 6 Feb 2003 18:57:14 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <D2EC481073504E498A8DB9C0687E8CAF05D88288@EXCHANGE0-0.na.procket.com> Thread-Topic: Meeting topics? Thread-Index: AcLOVJ18jHkrtSJyTt6eF2tJofgIbg== From: "Tony Li" <Tony.Li@procket.com> To: <isis-wg@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1730op19267 Subject: [Isis-wg] Meeting topics? 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 6 Feb 2003 18:57:13 -0800 Content-Transfer-Encoding: 8bit Folks, If folks are interested in having a physical live session at the next IETF, we need to put together an agenda. Could you please send me any requests for topics? If you're proposing to talk, I'd appreciate an estimate of the time required for your talk and discussion. Please unicast to me. Thanks, Tony L. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 7 03:49:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01850 for <isis-archive@lists.ietf.org>; Fri, 7 Feb 2003 03:49:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h178rup17868; Fri, 7 Feb 2003 03:53:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h178q2p17820 for <isis-wg@optimus.ietf.org>; Fri, 7 Feb 2003 03:52:02 -0500 Received: from spf1.us.outblaze.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01703 for <isis-wg@ietf.org>; Fri, 7 Feb 2003 03:44:39 -0500 (EST) Received: (qmail 30202 invoked from network); 7 Feb 2003 08:48:19 -0000 Received: from unknown (205.158.62.68) by spf1.us.outblaze.com with QMQP; 7 Feb 2003 08:48:19 -0000 Received: (qmail 1297 invoked from network); 7 Feb 2003 08:48:18 -0000 Received: from unknown (HELO ws1-7.us4.outblaze.com) (205.158.62.57) by 205-158-62-153.outblaze.com with SMTP; 7 Feb 2003 08:48:18 -0000 Received: (qmail 21963 invoked by uid 1001); 7 Feb 2003 08:48:17 -0000 Message-ID: <20030207084817.21962.qmail@iname.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [149.254.120.136] by ws1-7.us4.outblaze.com with http for philip.christian@iname.com; Fri, 07 Feb 2003 08:48:17 +0000 From: "Philip Christian" <philip.christian@iname.com> To: kay@ipinfusion.com, naiming@redback.com Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt X-Originating-Ip: 149.254.120.136 X-Originating-Server: ws1-7.us4.outblaze.com 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 07 Feb 2003 08:48:17 +0000 Content-Transfer-Encoding: 7bit Kay, Please read section 7.1.10.1.1 of G.7712. You can download it from ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/isis/index.html Please also have a good look at http://www.ietf.org/internet-drafts/draft-ietf-isis-auto-encap-02.txt The behaviour mentioned in these documents was also mentioned in section 18 of http://www.ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt Regards, Philip ----- Original Message ----- From: Noguchi Kay <kay@ipinfusion.com> Date: Thu, 06 Feb 2003 12:36:26 -0800 To: Naiming Shen <naiming@redback.com> Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt > Hi Naiming, > > This is Kay. > > > ] > NLPIDs for both v4 and v6. the adjacency status will be determined by > > ] > the MT status. > > ] > > ] But how to adjacent with legacy IPv4/IPv6 IS-IS software which > > ] enables IPv4 routing but disables IPv6 routing. > > ] > > ] In this case, legacy software means the software doesn't support > > ] M-ISIS capability. > > ] > > ] That kind of legacy software doesn't allow to make adjacent > > ] with neighbors which contains IPv4 and IPv6 NLPIDs in IIH > > ] Protocols Supported TLV. > > > > do you have information on which vendor's isis software actually does > > that (not forming adjacency because neighbor supports more than my > > own nlpid) ? > > Before the implementation topic, could you point out > which spec states it and how? > > Thank you, > > kay > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www1.ietf.org/mailman/listinfo/isis-wg -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 12 13:56:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11971 for <isis-archive@lists.ietf.org>; Wed, 12 Feb 2003 13:56:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJ3up13216; Wed, 12 Feb 2003 14:03:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1CJ2jp13170 for <isis-wg@optimus.ietf.org>; Wed, 12 Feb 2003 14:02:45 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11707 for <isis-wg@ietf.org>; Wed, 12 Feb 2003 13:52:43 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18j24R-0008AJ-00; Wed, 12 Feb 2003 10:57:23 -0800 Message-ID: <878ywlwcml.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: Naiming Shen <naiming@redback.com> Cc: Noguchi Kay <kay@ipinfusion.com>, stefano previdi <sprevidi@cisco.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030207010957.BD8C52AA640@prattle.redback.com> References: <kay@ipinfusion.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 12 Feb 2003 10:57:22 -0800 Hi Naiming, This is Kay. > ] > ] That kind of legacy software doesn't allow to make adjacent > ] > ] with neighbors which contains IPv4 and IPv6 NLPIDs in IIH > ] > ] Protocols Supported TLV. > ] > > ] > do you have information on which vendor's isis software actually does > ] > that (not forming adjacency because neighbor supports more than my > ] > own nlpid) ? > ] > ] Before the implementation topic, could you point out > ] which spec states it and how? > ] > > we are talking about backwards compatibility, so we are only dealing with > existing systems. the goal is to solve real network problems(how to fit a > new routing scheme into an existing network), not those theoretical ones. > as far as i know of, dominant isis software out there does not care at > all about some extra nlpids in hellos. Did you check the legacy IPv4/IPv6 IS-IS software which only enables IPv4 routing? Does that software allowed to receive IIH packet which contains IPv4 "and" IPv6 NLPID in the Protocols Supported TLV? Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 14 07:37:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20528 for <isis-archive@lists.ietf.org>; Fri, 14 Feb 2003 07:37:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECctp22893; Fri, 14 Feb 2003 07:38:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ECbgp22802 for <isis-wg@optimus.ietf.org>; Fri, 14 Feb 2003 07:37:42 -0500 Received: from spy3.spymac.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20330 for <isis-wg@ietf.org>; Fri, 14 Feb 2003 07:33:33 -0500 (EST) Received: from spy3.spymac.com (localhost [127.0.0.1]) by spy3.spymac.com (Postfix) with ESMTP id 15630E8BA for <isis-wg@ietf.org>; Fri, 14 Feb 2003 05:37:17 -0700 (MST) Content-Disposition: inline Content-Transfer-Encoding: binary Mime-Version: 1.0 From: Saravana Kumar <sarav_k@spymac.com> To: isis-wg@ietf.org Reply-To: sarav_k@spymac.com Content-Type: text/plain X-Mailer: AtMail Corp 3.5 - http://webbasedemail.com/ X-Uidl: 1045226237276672183 X-Origin: 203.197.168.168 Message-Id: <20030214123717.15630E8BA@spy3.spymac.com> Content-Transfer-Encoding: binary Subject: [Isis-wg] encoding default route in TLV 135 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 14 Feb 2003 05:37:17 -0700 (MST) Content-Transfer-Encoding: binary Hi All, Can anyone clarify on how to encode the default route 0/0 in TLV 135. If the prefix length is set to zero, does it mean that the default route is being advertised in the TLV ? Thanks, Sarav --- Msg sent via Spymac Mail -- http://mail.spymac.com _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 14 14:46:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02757 for <isis-archive@lists.ietf.org>; Fri, 14 Feb 2003 14:46:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJmYp19770; Fri, 14 Feb 2003 14:48:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EJl1p19688 for <isis-wg@optimus.ietf.org>; Fri, 14 Feb 2003 14:47:01 -0500 Received: from ghostrider.gredler.at (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02545 for <isis-wg@ietf.org>; Fri, 14 Feb 2003 14:42:42 -0500 (EST) Received: (from hannes@localhost) by ghostrider.gredler.at (8.11.6/8.11.6) id h1EJkOB32005; Fri, 14 Feb 2003 20:46:24 +0100 From: Hannes Gredler <hannes@juniper.net> To: Saravana Kumar <sarav_k@spymac.com> Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] encoding default route in TLV 135 Message-ID: <20030214194624.GA31931@juniper.net> References: <20030214123717.15630E8BA@spy3.spymac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030214123717.15630E8BA@spy3.spymac.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 14 Feb 2003 20:46:24 +0100 On Fri, Feb 14, 2003 at 05:37:17AM -0700, Saravana Kumar wrote: | Hi All, | | Can anyone clarify on how to encode the default route 0/0 in TLV 135. If the prefix length is set to zero, does it mean that the default route is | being advertised in the TLV ? correct - set prefix-len to 0 and store 0 bytes; [except of course you have no subTLVs] /hannes _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 14 17:15:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07329 for <isis-archive@lists.ietf.org>; Fri, 14 Feb 2003 17:15:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMFmp30159; Fri, 14 Feb 2003 17:15:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EMCWp29973 for <isis-wg@optimus.ietf.org>; Fri, 14 Feb 2003 17:12:32 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06735 for <isis-wg@ietf.org>; Fri, 14 Feb 2003 17:08:10 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18jo3t-0000MX-00; Fri, 14 Feb 2003 14:12:01 -0800 Message-ID: <87r8aa5x72.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: Naiming Shen <naiming@redback.com> Cc: Noguchi Kay <kay@ipinfusion.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030205064221.472B83FAC8@prattle.redback.com> References: <kay@ipinfusion.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 14 Feb 2003 14:12:01 -0800 Hi Naiming, This is Kay. > ] 2) Some implementation checks if the IP Interface Address TLV is > ] in the same subnetwork or not to form an adjacency as > ] stated in draft-ietf-isis-ip-interoperable-00.txt section 13. > ] > ] How does M-ISIS software which only supports IPv6 get the IPv4 > ] subnetwork information for this link? > > as you noticed, this is an implementation issue. and get aournd those > implementation, one can assign an ipv4 address on the LAN interface, > and "inject" that ipv4 address in the IIH which is on the same subnet So M-ISIS routers which follows draft-ietf-isis-ip-interoperable-00.txt section 13 MUST advertise IP Interface Address TLV if they want to make adjacent with legacy IPv4 routers on a LAN even if M-ISIS routers only support IPv6 IS-IS routing. Is this correct? > as your neighbors. as far as i know, there is no ipv6 only routers yet, > get an ipv4 address on the LAN interface does not mean the router > need to switch ipv4 traffic, it can still be a ipv6 only M-ISIS node. I don't think this is a good assumption. We are talking about "IPv6 only" IS-IS routers so we don't know the routers has IPv4 address on the interface or not. If they don't have the IPv4 address on the interface, then how to encode the IP Interface Address TLV? > for any new routing scheme, we can not expect a flag day to upgrage > all the nodes with new software. any scheme HAS to co-exist with the > current/legacy software. new software has the flexibility to do "tricks" > to work with the old software. kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 14 18:00:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08540 for <isis-archive@lists.ietf.org>; Fri, 14 Feb 2003 18:00:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EN26p01002; Fri, 14 Feb 2003 18:02:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1EN1rp00982 for <isis-wg@optimus.ietf.org>; Fri, 14 Feb 2003 18:01:53 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08435 for <isis-wg@ietf.org>; Fri, 14 Feb 2003 17:57:31 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id C9153326BC1; Fri, 14 Feb 2003 15:01:16 -0800 (PST) To: Noguchi Kay <kay@ipinfusion.com> Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay <kay@ipinfusion.com> dated Fri, 14 Feb 2003 14:12:01 PST <87r8aa5x72.wl@giga.kayz.org> From: Naiming Shen <naiming@redback.com> Message-Id: <20030214230116.C9153326BC1@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 14 Feb 2003 15:01:16 -0800 ] ] So M-ISIS routers which follows draft-ietf-isis-ip-interoperable-00.txt ] section 13 MUST advertise IP Interface Address TLV ] if they want to make adjacent with legacy IPv4 routers on a LAN ] even if M-ISIS routers only support IPv6 IS-IS routing. ] ] Is this correct? correct. in specific, it's needed for those legacy IPv4 routers check on those subnets(not all the legacy IPv4 routers do that). ] > as your neighbors. as far as i know, there is no ipv6 only routers yet, ] > get an ipv4 address on the LAN interface does not mean the router ] > need to switch ipv4 traffic, it can still be a ipv6 only M-ISIS node. ] ] I don't think this is a good assumption. please give one example of an existing "ipv6 only" router. we are talking about transition, and legacy software does not stay forever. by the time we see this kind of "ipv6 only" router widely used, we may not find those legacy software based ipv4 routers around in networks. but if you have to insert the "ipv6 only" router into the LAN which has a mix of ip protocols, then: - have a knob in isis to maually inject an IPv4 address in the LAN IIH, only isis knows about this address internally. it's just software. ipv6 RFCs do not say it's illegal to type an ipv4 address inside an ipv6 only router. - upgrade the IPv4 only router software not to check the ipv4 subnet for ipv6 only neighbor, so it is not a "legacy" anymore. - don't put it into that LAN, ethernet is so cheap, setup another LAN. thanks. ] ] We are talking about "IPv6 only" IS-IS routers so we don't know ] the routers has IPv4 address on the interface or not. ] ] If they don't have the IPv4 address on the interface, then ] how to encode the IP Interface Address TLV? ] ] > for any new routing scheme, we can not expect a flag day to upgrage ] > all the nodes with new software. any scheme HAS to co-exist with the ] > current/legacy software. new software has the flexibility to do "tricks" ] > to work with the old software. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 14 18:29:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09307 for <isis-archive@lists.ietf.org>; Fri, 14 Feb 2003 18:29:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ENVIp03005; Fri, 14 Feb 2003 18:31:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ENUfp02964 for <isis-wg@optimus.ietf.org>; Fri, 14 Feb 2003 18:30:41 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09218 for <isis-wg@ietf.org>; Fri, 14 Feb 2003 18:26:18 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18jpHo-0000Pb-00; Fri, 14 Feb 2003 15:30:28 -0800 Message-ID: <87of5e5tkb.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: Naiming Shen <naiming@redback.com> Cc: Noguchi Kay <kay@ipinfusion.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-Reply-To: <20030214230116.C9153326BC1@prattle.redback.com> References: <kay@ipinfusion.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 14 Feb 2003 15:30:28 -0800 Hi Naiming, This is Kay. > but if you have to insert the "ipv6 only" router into the LAN which has a > mix of ip protocols, then: > > - have a knob in isis to maually inject an IPv4 address in the LAN IIH, > only isis knows about this address internally. it's just software. > ipv6 RFCs do not say it's illegal to type an ipv4 address inside > an ipv6 only router. > - upgrade the IPv4 only router software not to check the ipv4 subnet for > ipv6 only neighbor, so it is not a "legacy" anymore. How to know the neighbor is IPv6 only router? You mentioned that M-ISIS router puts IPv4 "and" IPv6 NLPID in the Protocols Supported TLV. > - don't put it into that LAN, ethernet is so cheap, setup another LAN. kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 14 18:57:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09846 for <isis-archive@lists.ietf.org>; Fri, 14 Feb 2003 18:57:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ENxQp04768; Fri, 14 Feb 2003 18:59:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1ENwrp04739 for <isis-wg@optimus.ietf.org>; Fri, 14 Feb 2003 18:58:53 -0500 Received: from prattle.redback.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09754 for <isis-wg@ietf.org>; Fri, 14 Feb 2003 18:54:31 -0500 (EST) Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A2AC823E1B2; Fri, 14 Feb 2003 15:57:31 -0800 (PST) To: Noguchi Kay <kay@ipinfusion.com> Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt In-reply-to: Mail from Noguchi Kay <kay@ipinfusion.com> dated Fri, 14 Feb 2003 15:30:28 PST <87of5e5tkb.wl@giga.kayz.org> From: Naiming Shen <naiming@redback.com> Message-Id: <20030214235731.A2AC823E1B2@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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 14 Feb 2003 15:57:31 -0800 ] > - upgrade the IPv4 only router software not to check the ipv4 subnet for ] > ipv6 only neighbor, so it is not a "legacy" anymore. ] ] How to know the neighbor is IPv6 only router? ] ] You mentioned that M-ISIS router puts IPv4 "and" IPv6 NLPID in ] the Protocols Supported TLV. if i'm the developer for this new ipv4 only router, i'll just put a knob, "disable ip-subnet-check", it's up to the operators to issue that. if you want it automatically, then as soon as you see the neighbor is not ipv4 only, just don't check it. hope this helps. thanks. - Naiming _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 20 10:40:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18393 for <isis-archive@lists.ietf.org>; Thu, 20 Feb 2003 10:40:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFifp22083; Thu, 20 Feb 2003 10:44:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KFh2p22043 for <isis-wg@optimus.ietf.org>; Thu, 20 Feb 2003 10:43:02 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18157 for <isis-wg@ietf.org>; Thu, 20 Feb 2003 10:35:53 -0500 (EST) Message-ID: <EB5FFC72F183D411B382000629573429035E8750@r2d2.axiowave.com> From: Jeff Parker <jparker@axiowave.com> To: "'Manral, Vishwas'" <VishwasM@netplane.com> Cc: "ISIS-WG (E-mail)" <isis-wg@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: draft-ietf-isis-wg-mib-10.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 20 Feb 2003 10:39:28 -0500 > The Redistribute Address Table too has not been given in the Overview Section. From the looks of my version, someone caught that already. It is right after the SummAddr listing. I have beefed up the description while I was there. > Besides typo "are are" in discription of the table. > Also it would be nice to state that any destination > not falling into the range is not announced at all. > Thanks, > Vishwas Thanks. I've removed and updated the text. - jeff parker isisRedistributeAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRedistributeAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides criteria to decide if a route should be leaked from L2 to L1 when Domain Wide Prefix leaking is enabled. Addresses that match the summary mask in the table will be announced at L1 by routers when isisSysL2toL1Leaking is enabled. Routes that fall into the ranges specified are announced as is, without being summarized. Routes that do not match a summary mask are not announced." ::= { isisSystem 6 } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 20 11:12:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19669 for <isis-archive@lists.ietf.org>; Thu, 20 Feb 2003 11:12:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGGBp24674; Thu, 20 Feb 2003 11:16:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGCEp24464 for <isis-wg@optimus.ietf.org>; Thu, 20 Feb 2003 11:12:14 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19262 for <isis-wg@ietf.org>; Thu, 20 Feb 2003 11:05:04 -0500 (EST) Message-ID: <EB5FFC72F183D411B382000629573429035E8751@r2d2.axiowave.com> From: Jeff Parker <jparker@axiowave.com> To: "ISIS-WG (E-mail)" <isis-wg@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Changes for System Host table 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 20 Feb 2003 11:08:47 -0500 I had mentioned adding a table to track the hostname and routerID. I have a first draft below. There are a few issues which may merit discussion. I have called it "RouterTable", feeling that "ISTable" might be too archaic, but RouterTable is also pretty ugly. Following suggestions, I have included the level as an index, in case there is confusion at different levels. The RouterID is an Unsigned32. It coud be argued that it should be an IP address, but I am trying to maintain the fiction that RouterID and IP address are two different name spaces. There is an assumption that the SystemID is unique, but no assumption that the router ID or hostname is unique. Duplicating any of these, of course, creates problems. We currently have a Notification called isisOwnLSPPurge, so responsibility for spotting the reuse of a system ID is placed on the owners of the system ID, rather than on every system in the network. I have just added a field in that notification to hold the remote router ID, which may provide an alternative way of contacting a misconfigured system (perhaps using the router ID as an IP address?) We may wish to add notifications if we see a duplication of the routerID or the hostname. I would use the same rule: the owner of the duplicated item should complain, to reduce the noise level. Here are the relevant changes: first the RouterTable, and then the changes to the Notifications. - jeff parker -- The Router Table keeps track of hostnames and router IDs -- associated with peers in the area and domain. isisRouterTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRouterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The set of hostnames and router ID." ::= { isisSystem 7 } isisRouterEntry OBJECT-TYPE SYNTAX IsisRouterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry tracks information about one peer at one level." INDEX { isisSysInstance, isisRouterSysID, isisRouterLevel } ::= { isisRouterTable 1 } IsisRouterEntry ::= SEQUENCE { isisRouterSysID SystemID, isisRouterLevel INTEGER, isisRouterHostName DisplayString, isisRouterID Unsigned32 } isisRouterSysID OBJECT-TYPE SYNTAX SystemID MAX-ACCESS not-accessible STATUS current DESCRIPTION "The System ID of the Router Peer." ::= { isisRouterEntry 1 } isisRouterLevel OBJECT-TYPE SYNTAX INTEGER { area(1), -- L1 domain(2), -- L2 both(3) -- L1L2 } MAX-ACCESS not-accessible STATUS current DESCRIPTION "The level of this Intermediate System." ::= { isisRouterEntry 2 } isisRouterHostName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The hostname listed in LSP, or NULL if none." ::= { isisRouterEntry 3 } isisRouterID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of the Peer found in LSP, or NULL if none." ::= { isisRouterEntry 4 } ////////////////////// isisRemoteRouterID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The Router ID of a remote system. If not known, we set this to 0." ::= { isisNotificationEntry 12 } .... isisOwnLSPPurge NOTIFICATION-TYPE OBJECTS { isisSystemInstance, isisSystemLevel, isisCircIfIndex, isisTrapLSPID, isisRemoteRouterID } STATUS current DESCRIPTION "A notification sent when we receive a PDU with our systemID and zero age. This notification includes the circuit Index and router ID from the LSP, if available, which may help a network manager identify the source of the confusion." ::= { isisTrapPrefix 7 } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 20 11:53:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21152 for <isis-archive@lists.ietf.org>; Thu, 20 Feb 2003 11:53:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGwBp28394; Thu, 20 Feb 2003 11:58:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1KGvVp28296 for <isis-wg@optimus.ietf.org>; Thu, 20 Feb 2003 11:57:31 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21026 for <isis-wg@ietf.org>; Thu, 20 Feb 2003 11:50:21 -0500 (EST) Message-ID: <EB5FFC72F183D411B382000629573429035E8752@r2d2.axiowave.com> From: Jeff Parker <jparker@axiowave.com> To: "'jonathan.sadler@tellabs.com'" <jonathan.sadler@tellabs.com> Cc: "ISIS-WG (E-mail)" <isis-wg@ietf.org> Subject: RE: [Isis-wg] Changes for System Host table 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 20 Feb 2003 11:54:01 -0500 > Jeff - > > Your use of an enumeration for the isisRouterLevel > entry concerns me as it may prevent use of this MIB > by future multi-level IS-IS implementations. Could > it instead be a bitfield, with each bit stating the > level? This is generally compatible with the > enumeration you have described, but is not > bounded at 2 levels. > > Jonathan Sadler Jonathan - One thing I could do would be to use the TC ISLevel, which I've introduced to allow some indirection for just this sort of change. See below for details. Since this takes more "objects" to describe a tuple that is valid at multiple levels, this is less efficient that the proposed scheme, but it may simplify implementation. - jeff parker ISLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Identifies a level." SYNTAX INTEGER { none(0), area(1), -- L1 domain(2) -- L2 } _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Mon Feb 24 12:39:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20037 for <isis-archive@lists.ietf.org>; Mon, 24 Feb 2003 12:39:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHjop09586; Mon, 24 Feb 2003 12:45:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1OHiip09540 for <isis-wg@optimus.ietf.org>; Mon, 24 Feb 2003 12:44:44 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19897 for <isis-wg@ietf.org>; Mon, 24 Feb 2003 12:35:37 -0500 (EST) Message-ID: <EB5FFC72F183D411B382000629573429035E879E@r2d2.axiowave.com> From: Jeff Parker <jparker@axiowave.com> To: "ISIS-WG (E-mail)" <isis-wg@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Changes to the 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Mon, 24 Feb 2003 12:39:25 -0500 I have made enough changes in the MIB recently to require a new draft. I have sent in my current version to the IETF. - jeff parker - axiowave networks _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Feb 25 07:01:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25989 for <isis-archive@lists.ietf.org>; Tue, 25 Feb 2003 07:01:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PC5Fp21889; Tue, 25 Feb 2003 07:05:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PC2hp21806 for <isis-wg@optimus.ietf.org>; Tue, 25 Feb 2003 07:02:43 -0500 Received: from xover.netplane.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25427 for <isis-wg@ietf.org>; Tue, 25 Feb 2003 06:53:13 -0500 (EST) Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1RXV3RQK>; Tue, 25 Feb 2003 06:57:07 -0500 Message-ID: <E7E13AAF2F3ED41197C100508BD6A328666916@india_exch.hyderabad.mindspeed.com> From: "Jonnala, Nagi" <nagij@netplane.com> To: "'jparker@axiowave.com'" <jparker@axiowave.com> Cc: "ISIS-WG (E-mail)" <isis-wg@ietf.org>, "Shukla, Vineet" <vineets@netplane.com>, "Manral, Vishwas" <VishwasM@netplane.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] isisRedistributeAddrTable question 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Tue, 25 Feb 2003 06:58:46 -0500 Jeff, After reading the table description my understanding is: "Unlike in summary address table, all addresses that fall in the range specified would be announced as it is without being summarized". My questions are: 1) I have a route which doesn't fall in that range, then does it need be thrown away? or what is the behavior? 2) Why should Redistribute table behavior be different from summary address table at the conceptual level. i.e., advertise the summary prefix for the routes that fall in the range, otherwise advertise the route as it is. Quick reference: -- The Redistribution table defines addresses that should be leaked from -- L2 to L1 if isisSysL2toL1Leaking is enabled. isisRedistributeAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IsisRedistributeAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides criteria to decide if a route should be leaked from L2 to L1 when Domain Wide Prefix leaking is enabled. Addresses that match the summary mask in the table will be announced at L1 by routers when isisSysL2toL1Leaking is enabled. Routes that fall into the ranges specified are are announced as is, without being summarized." ::= { isisSystem 6 } Thanks Nagi. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Feb 25 10:41:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03834 for <isis-archive@lists.ietf.org>; Tue, 25 Feb 2003 10:41:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFmRp06449; Tue, 25 Feb 2003 10:48:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PFl1p06375 for <isis-wg@optimus.ietf.org>; Tue, 25 Feb 2003 10:47:01 -0500 Received: from bridge.axiowave.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03679 for <isis-wg@ietf.org>; Tue, 25 Feb 2003 10:37:25 -0500 (EST) Message-ID: <EB5FFC72F183D411B382000629573429035E87B1@r2d2.axiowave.com> From: Jeff Parker <jparker@axiowave.com> To: "'Jonnala, Nagi'" <nagij@netplane.com>, Jeff Parker <jparker@axiowave.com> Cc: "ISIS-WG (E-mail)" <isis-wg@ietf.org>, "Shukla, Vineet" <vineets@netplane.com>, "Manral, Vishwas" <VishwasM@netplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] RE: isisRedistributeAddrTable question 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Tue, 25 Feb 2003 10:40:59 -0500 > After reading the isisRedistributeAddrTable description > > "Unlike in summary address table, all addresses that fall > in the range specified would be announced as it is without > being summarized". > > 1) I have a route which doesn't fall in that range: > what is the behavior? Don't leak it. > 2) Why should Redistribute table behavior be different > from the summary address table? Jonnala - My thought was that leaking up should be the default behavior, and leaking down should be the exception. I would expect that we don't want to leak down most routes. But what is the experience of the group on this point? - jeff parker PS The new draft is in the queue, but as I waited until the last minute to send it in, it may not appear for some time. If you are interested in seeing version 11, drop me a private note and I'll be happy to send it. _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Tue Feb 25 12:30:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07609 for <isis-archive@lists.ietf.org>; Tue, 25 Feb 2003 12:30:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHaep14664; Tue, 25 Feb 2003 12:36:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1PHZrp14570 for <isis-wg@optimus.ietf.org>; Tue, 25 Feb 2003 12:35:53 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07287 for <isis-wg@ietf.org>; Tue, 25 Feb 2003 12:26:14 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 2A49D23C35 for <isis-wg@ietf.org>; Tue, 25 Feb 2003 09:42:21 -0800 (PST) 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 h1PHU8Dw012425 for <isis-wg@ietf.org>; Tue, 25 Feb 2003 09:30:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <D2EC481073504E498A8DB9C0687E8CAF01AD1496@EXCHANGE0-0.na.procket.com> Thread-Topic: Meeting in San Francisco Thread-Index: AcLc84rojvXLnYlySCyY6/4531FnsQ== From: "Tony Li" <Tony.Li@procket.com> To: <isis-wg@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1PHZrp14571 Subject: [Isis-wg] Meeting in San Francisco 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Tue, 25 Feb 2003 09:30:08 -0800 Content-Transfer-Encoding: 8bit Folks, We will be having one session in San Francisco. According to the latest draft agenda, it will be 5pm on Tuesday. This may change, so please pay attention to the schedule changes. The current agenda looks like: Review document status Multi-level support Protocol topology support If you have any other requests, please unicast to me. For those of you who have not been to our fair city, the weather reports say that things are warming up (mid forties to low sixties, F), however you should be aware that SF has the ability to be significantly colder than what the thermometer reads. Fog is a virtual certainty and rain is reasonably likely. California has two seasons: dry and wet. We're now in wet. Dress accordingly, don't rent a car, and I'll see you 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 Feb 26 09:04:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05551 for <isis-archive@lists.ietf.org>; Wed, 26 Feb 2003 09:04:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEBWp10948; Wed, 26 Feb 2003 09:11:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QEA5p10799 for <isis-wg@optimus.ietf.org>; Wed, 26 Feb 2003 09:10:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04864; Wed, 26 Feb 2003 09:00:04 -0500 (EST) Message-Id: <200302261400.JAA04864@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-sadler-isis-ml-bcp-00.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 26 Feb 2003 09:00:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multi-Level IS-IS Without Protocol Extensions Author(s) : J. Sadler Filename : draft-sadler-isis-ml-bcp-00.txt Pages : 19 Date : 2003-2-25 Work has started in the ITU, the IETF IP over Optical Working Group, and in the OIF to specify the requirements for ASON NNI routing. One of the requirements identified is support for multi-level hierarchies. IS-IS is one of the candidate protocols to provide this functionality. Therefore, methods for multi-level IS-IS routing need to be developed. This draft documents one that provides multi-level routing through the 'stacking' of Level 2 IS-IS instances. The method is possible using existing extensions to IS-IS. It also provides insight into some of the resulting operational issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sadler-isis-ml-bcp-00.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-sadler-isis-ml-bcp-00.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-sadler-isis-ml-bcp-00.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-2-25160045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sadler-isis-ml-bcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sadler-isis-ml-bcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25160045.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 Feb 26 16:07:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25593 for <isis-archive@lists.ietf.org>; Wed, 26 Feb 2003 16:07:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLEbp11212; Wed, 26 Feb 2003 16:14:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLDep11126 for <isis-wg@optimus.ietf.org>; Wed, 26 Feb 2003 16:13:40 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25356 for <isis-wg@ietf.org>; Wed, 26 Feb 2003 16:03:29 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18o8m5-0000NL-00; Wed, 26 Feb 2003 13:07:33 -0800 Message-ID: <87of4ybvje.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: isis-wg@ietf.org cc: kay@ipinfusion.com X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Subject: [Isis-wg] 4.2 c) draft-ietf-isis-restart-02.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 26 Feb 2003 13:07:33 -0800 Hi Mike, I have a question regarding 4.2 c) Adjacency re-acquisition. In 4.2 c), > c) if the corresponding interface is a Point-to-Point interface, or > if the receiving router has the highest LnRouterPriority (with > highest source MAC address breaking ties) among those routers > whose IIHs contain the restart TLV, excluding the transmitting > router (note the actual DIS is NOT changed by this process.), > initiate the transmission over the corresponding interface of a > complete set of CSNPs, and set SRMflags on the corresponding > interface for all LSPs in the local LSP database. Could you tell me the reason why helper router should send CSNPs and set SRMflags for each LSPs? As noted below, standard process can acheive the database synchronization without any special treatment. What do you think? 1) On Point-to-Point interface Restarting router sends CSNP with own LSP only. Then neighbor router just sets SRMflags for missing LSPs and synchronization will be done as normal. 2.1) DIS restarting on Broadcast interface Restartng router sends CSNP with own LSP only. Then neighbor routers just sets SRMflags for missing LSPs and synchronization will be done as normal. 2.2) nonDIS restarting on Broadcast interface Restarting router receives CSNPs from DIS after some period, but less than CSNP interval, and restarting router sets SSNflags for missing LSPs and synchronization will be done as normal. Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 26 17:24:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29718 for <isis-archive@lists.ietf.org>; Wed, 26 Feb 2003 17:24:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMVSp16786; Wed, 26 Feb 2003 17:31:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QMUPp16701 for <isis-wg@optimus.ietf.org>; Wed, 26 Feb 2003 17:30:25 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29507 for <isis-wg@ietf.org>; Wed, 26 Feb 2003 17:20:11 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1QMO656012881; Wed, 26 Feb 2003 14:24:07 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-59.cisco.com [128.107.163.59]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEJ93731; Wed, 26 Feb 2003 14:07:30 -0800 (PST) Message-Id: <4.3.2.7.2.20030226140136.0376d688@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Noguchi Kay <kay@ipinfusion.com> From: Les Ginsberg <ginsberg@cisco.com> Subject: Re: [Isis-wg] 4.2 c) draft-ietf-isis-restart-02.txt Cc: isis-wg@ietf.org, kay@ipinfusion.com In-Reply-To: <87of4ybvje.wl@giga.kayz.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 26 Feb 2003 14:24:05 -0800 At 01:07 PM 2/26/2003 -0800, Noguchi Kay wrote: >Hi Mike, > >I have a question regarding 4.2 c) Adjacency re-acquisition. > >In 4.2 c), > > > c) if the corresponding interface is a Point-to-Point interface, or > > if the receiving router has the highest LnRouterPriority (with > > highest source MAC address breaking ties) among those routers > > whose IIHs contain the restart TLV, excluding the transmitting > > router (note the actual DIS is NOT changed by this process.), > > initiate the transmission over the corresponding interface of a > > complete set of CSNPs, and set SRMflags on the corresponding > > interface for all LSPs in the local LSP database. > > Could you tell me the reason why helper router should send CSNPs > and set SRMflags for each LSPs? > > As noted below, standard process can acheive the database > synchronization without any special treatment. > > What do you think? Kay - You are correct is stating that the normal operation of the update process will eventually result in database synchronization. But one of the requirements of restart is for the restarting router to be able to deterministically know WHEN it has achieved database synchronization. In order to do that the restarting router must know the set of LSPs that it should expect in order to reach "synchronization". This requires receiving a full set of CSNPs from your neighbor(s). When the restarting router has received all of the LSPs mentioned in the CSNPs, it can then declare itself synchronized (cancel T2 timers and T3 timer) and begin to update FIB, clear OL bit and regenerate its own LSPs, etc. On Point-to-point interface CSNPs would not normally be sent unless adjacency transitioned to UP. In the restart case we are trying to prevent an unnecessary down-up transition, so we must get the neighbor to send CSNPs even though adjacency state has not transitioned to UP. On Broadcast interface, if restarting router was DIS, CSNPs would not normally be sent by other routers, so we must get the router which would be elected DIS in the absence of the restarting router to send the CSNPs. If the restarting router was NOT DIS, we would like the current DIS to send CSNPs immediately (rather than waiting for expiration of the next SNP interval) so as to make database synchronization faster. In all cases the router sending CSNPs must set SRMflags to initiate the sending of the LSPs to the restarting router. Les >1) On Point-to-Point interface > > Restarting router sends CSNP with own LSP only. Then neighbor router > just sets SRMflags for missing LSPs and synchronization will be done > as normal. > >2.1) DIS restarting on Broadcast interface > > Restartng router sends CSNP with own LSP only. Then neighbor routers > just sets SRMflags for missing LSPs and synchronization will be done > as normal. > >2.2) nonDIS restarting on Broadcast interface > > Restarting router receives CSNPs from DIS after some period, but less > than CSNP interval, and restarting router sets SSNflags for missing > LSPs and synchronization will be done as normal. > >Thank you, > > kay > > > >_______________________________________________ >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 Feb 26 19:02:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03335 for <isis-archive@lists.ietf.org>; Wed, 26 Feb 2003 19:02:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R0APp23643; Wed, 26 Feb 2003 19:10:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R09Kp23602 for <isis-wg@optimus.ietf.org>; Wed, 26 Feb 2003 19:09:20 -0500 Received: from giga.kayz.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03176 for <isis-wg@ietf.org>; Wed, 26 Feb 2003 18:59:05 -0500 (EST) Received: from localhost ([127.0.0.1] helo=giga.kayz.org) by giga.kayz.org with esmtp (Exim 3.35 #1 (Debian)) id 18oBVl-0000VE-00; Wed, 26 Feb 2003 16:02:53 -0800 Message-ID: <87k7fmbnf6.wl@giga.kayz.org> From: Noguchi Kay <kay@ipinfusion.com> To: Les Ginsberg <ginsberg@cisco.com> Cc: Noguchi Kay <kay@ipinfusion.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] 4.2 c) draft-ietf-isis-restart-02.txt In-Reply-To: <4.3.2.7.2.20030226140136.0376d688@mira-sjc5-3.cisco.com> References: <87of4ybvje.wl@giga.kayz.org> <4.3.2.7.2.20030226140136.0376d688@mira-sjc5-3.cisco.com> X-Mailer: Wanderlust/2.8.1 MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 26 Feb 2003 16:02:53 -0800 Hi Les, Thank you for your quick reply. I understand the deterministic synchronization then why don't we put one line after the clause that tells us the reason to send the CSNPs and LSPs by helper router like below. > c) if the corresponding interface is a Point-to-Point interface, or > if the receiving router has the highest LnRouterPriority (with > highest source MAC address breaking ties) among those routers > whose IIHs contain the restart TLV, excluding the transmitting > router (note the actual DIS is NOT changed by this process.), > initiate the transmission over the corresponding interface of a > complete set of CSNPs, and set SRMflags on the corresponding interface for all LSPs in the local LSP database to achive the deterministic synchronization for resterting router as stated in section 4.3. Thank you, kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Wed Feb 26 19:15:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03549 for <isis-archive@lists.ietf.org>; Wed, 26 Feb 2003 19:15:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R0N7p24015; Wed, 26 Feb 2003 19:23:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1R0MTp23991 for <isis-wg@optimus.ietf.org>; Wed, 26 Feb 2003 19:22:29 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03466 for <isis-wg@ietf.org>; Wed, 26 Feb 2003 19:12:13 -0500 (EST) Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1R0FuP7012780; Wed, 26 Feb 2003 16:15:56 -0800 (PST) Received: from ginsberg-w2k.cisco.com (dhcp-128-107-163-59.cisco.com [128.107.163.59]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id AEK01976; Wed, 26 Feb 2003 15:59:32 -0800 (PST) Message-Id: <4.3.2.7.2.20030226161330.03778770@mira-sjc5-3.cisco.com> X-Sender: ginsberg@mira-sjc5-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Noguchi Kay <kay@ipinfusion.com> From: Les Ginsberg <ginsberg@cisco.com> Subject: Re: [Isis-wg] 4.2 c) draft-ietf-isis-restart-02.txt Cc: Noguchi Kay <kay@ipinfusion.com>, isis-wg@ietf.org In-Reply-To: <87k7fmbnf6.wl@giga.kayz.org> References: <4.3.2.7.2.20030226140136.0376d688@mira-sjc5-3.cisco.com> <87of4ybvje.wl@giga.kayz.org> <4.3.2.7.2.20030226140136.0376d688@mira-sjc5-3.cisco.com> 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Wed, 26 Feb 2003 16:16:08 -0800 At 04:02 PM 2/26/2003 -0800, Noguchi Kay wrote: >Hi Les, > >Thank you for your quick reply. > >I understand the deterministic synchronization then why don't we put >one line after the clause that tells us the reason to send the CSNPs >and LSPs by helper router like below. Given the statement in Section 3 "Secondly, whether or not the router is being re-started, it is desirable to be able to determine when the LSP databases of the neighboring routers have been synchronized (so that the overload bit can be cleared in the router's own LSP, for example). This document describes modifications to achieve this. " your proposal seems unnecessary. Les > > c) if the corresponding interface is a Point-to-Point interface, or > > if the receiving router has the highest LnRouterPriority (with > > highest source MAC address breaking ties) among those routers > > whose IIHs contain the restart TLV, excluding the transmitting > > router (note the actual DIS is NOT changed by this process.), > > initiate the transmission over the corresponding interface of a > > complete set of CSNPs, and set SRMflags on the corresponding > interface for all LSPs in the local LSP database to achive the > deterministic synchronization for resterting router as stated > in section 4.3. > >Thank you, > > kay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 27 05:16:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24368 for <isis-archive@lists.ietf.org>; Thu, 27 Feb 2003 05:16:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RAOep04836; Thu, 27 Feb 2003 05:24:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RANBp04787 for <isis-wg@optimus.ietf.org>; Thu, 27 Feb 2003 05:23:11 -0500 Received: from smtp.cwnt.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24272 for <isis-wg@ietf.org>; Thu, 27 Feb 2003 05:12:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Isis-wg] Meeting in San Francisco Message-ID: <C7DF4400240AFB4095D98C7C6EC2A34A5EAEF9@bart.cwnt.com> Thread-Topic: Meeting in San Francisco Thread-Index: AcLc84rojvXLnYlySCyY6/4531FnsQBVb5Vw From: "Amir Hermelin" <amir@cwnt.com> To: "Tony Li" <Tony.Li@procket.com>, <isis-wg@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RANBp04788 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 27 Feb 2003 12:16:37 +0200 Content-Transfer-Encoding: 8bit Don't rent a car? Anybody second that motion? > -----Original Message----- > From: Tony Li [mailto:Tony.Li@procket.com] > Sent: Tuesday, February 25, 2003 7:30 PM > To: isis-wg@ietf.org > Subject: [Isis-wg] Meeting in San Francisco > > > > Folks, > > We will be having one session in San Francisco. According to the > latest draft agenda, it will be 5pm on Tuesday. This may change, > so please pay attention to the schedule changes. > > The current agenda looks like: > > Review document status > Multi-level support > Protocol topology support > > If you have any other requests, please unicast to me. > > For those of you who have not been to our fair city, the > weather reports say that things are warming up (mid forties to > low sixties, F), however you should be aware that SF has the > ability to be significantly colder than what the thermometer > reads. Fog is a virtual certainty and rain is reasonably > likely. California has two seasons: dry and wet. We're now > in wet. Dress accordingly, don't rent a car, and I'll see > you there. > > Tony > > > _______________________________________________ > 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 Thu Feb 27 05:55:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24961 for <isis-archive@lists.ietf.org>; Thu, 27 Feb 2003 05:55:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RB4Gp07050; Thu, 27 Feb 2003 06:04:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RB3Mp06996 for <isis-wg@optimus.ietf.org>; Thu, 27 Feb 2003 06:03:22 -0500 Received: from net4u.net4u.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24877 for <isis-wg@ietf.org>; Thu, 27 Feb 2003 05:52:54 -0500 (EST) Received: from net4u.ch (zux006-036-123.adsl.green.ch [81.6.36.123]) by net4u.net4u.ch (8.11.3/8.11.3) with ESMTP id h1RAuiZ19122; Thu, 27 Feb 2003 11:56:44 +0100 Message-ID: <3E5DEEC5.4080106@net4u.ch> From: Tony Przygienda <prz@net4u.ch> 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: Amir Hermelin <amir@cwnt.com> CC: Tony Li <Tony.Li@procket.com>, isis-wg@ietf.org Subject: Re: [Isis-wg] Meeting in San Francisco References: <C7DF4400240AFB4095D98C7C6EC2A34A5EAEF9@bart.cwnt.com> 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 27 Feb 2003 11:56:05 +0100 Content-Transfer-Encoding: 7bit Amir Hermelin wrote: >Don't rent a car? Anybody second that motion? > if you're from NYC, _rent_ a car. You will be shocked how incompetent but friendly drivers can be ;-) And the jams are not worst than what I saw in front of Lincoln Tunnel. --- tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 27 15:24:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20538 for <isis-archive@lists.ietf.org>; Thu, 27 Feb 2003 15:24:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKTRp18510; Thu, 27 Feb 2003 15:29:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1RKSZp18472 for <isis-wg@optimus.ietf.org>; Thu, 27 Feb 2003 15:28:35 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20275 for <isis-wg@ietf.org>; Thu, 27 Feb 2003 15:17:57 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8539823C3F; Thu, 27 Feb 2003 12:33:11 -0800 (PST) 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 h1RKLpDw012546; Thu, 27 Feb 2003 12:21:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Meeting in San Francisco Message-ID: <D2EC481073504E498A8DB9C0687E8CAF01AD149B@EXCHANGE0-0.na.procket.com> Thread-Topic: [Isis-wg] Meeting in San Francisco Thread-Index: AcLc84rojvXLnYlySCyY6/4531FnsQBVb5VwABT4+aA= From: "Tony Li" <Tony.Li@procket.com> To: "Amir Hermelin" <amir@cwnt.com>, <isis-wg@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1RKSZp18473 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 27 Feb 2003 12:21:51 -0800 Content-Transfer-Encoding: 8bit | Don't rent a car? Anybody second that motion? If it helps, some rationale: parking in SF is expensive. Something like $14/day is pretty common. I bet that the hotel is more. We're in the theatre district, so you won't need it for meals and such. You won't need it to get from the airport to the hotel: take a van. For sightseeing in the city, the cable cars or Muni will get you most of the traditional places. If you're going to be doing sightseeing outside of the city (Napa, YFRV), then you'll need a car. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 27 19:18:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28612 for <isis-archive@lists.ietf.org>; Thu, 27 Feb 2003 19:18:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0Qep01027; Thu, 27 Feb 2003 19:26:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0PJp00987 for <isis-wg@optimus.ietf.org>; Thu, 27 Feb 2003 19:25:19 -0500 Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28536 for <isis-wg@ietf.org>; Thu, 27 Feb 2003 19:14:35 -0500 (EST) Received: from extremenetworks.com (unknown [10.0.8.86]) by gnat.inet.org (Postfix) with ESMTP id 52E926710B for <isis-wg@ietf.org>; Thu, 27 Feb 2003 19:32:29 -0500 (EST) Subject: Re: [Isis-wg] Meeting in San Francisco Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson <rja@extremenetworks.com> To: "'isis-wg@ietf.org'" <isis-wg@ietf.org> Content-Transfer-Encoding: 7bit In-Reply-To: <3E5DEEC5.4080106@net4u.ch> Message-Id: <292CA902-4AB2-11D7-B74E-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.551) 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 27 Feb 2003 19:18:28 -0500 Content-Transfer-Encoding: 7bit Oh, and if the only place one is going other than IETF is in Silicon Valley, one should consider taking "Cal-Train". Cal-Train is the passenger rail system from San Francisco south down the peninsula through Menlo Park, Palo Alto, Mt View, Sunnyvale, Santa Clara, to San Jose. It works well -- as long as one's destination is near a Cal-Train station. BART is the subway system for San Francisco, Berkeley, Oakland, etc. One can use that to get to the norh/east side of the SF Bay Area. I don't know any URLs, try Google if you need more data. Ran _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Thu Feb 27 19:34:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28791 for <isis-archive@lists.ietf.org>; Thu, 27 Feb 2003 19:34:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0h9p02356; Thu, 27 Feb 2003 19:43:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S0gkp02316 for <isis-wg@optimus.ietf.org>; Thu, 27 Feb 2003 19:42:46 -0500 Received: from demiurge.exodus.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28744 for <isis-wg@ietf.org>; Thu, 27 Feb 2003 19:32:01 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id QAA18655; Thu, 27 Feb 2003 16:32:59 -0800 (PST) From: andrewl@xix-w.bengi.exodus.net To: RJ Atkinson <rja@extremenetworks.com> Cc: "'isis-wg@ietf.org'" <isis-wg@ietf.org> Subject: Re: [Isis-wg] Meeting in San Francisco Message-ID: <20030227163259.R5760@demiurge.exodus.net> References: <3E5DEEC5.4080106@net4u.ch> <292CA902-4AB2-11D7-B74E-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <292CA902-4AB2-11D7-B74E-00039357A82A@extremenetworks.com>; from rja@extremenetworks.com on Thu, Feb 27, 2003 at 07:18:28PM -0500 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 27 Feb 2003 16:32:59 -0800 BART: www.bart.gov CalTrain: www.caltrain.com Check the schedule for CalTrain, if you get a local, it can take as much as 2 hours to get from SF to Sunnyvale/Santa Clara. Also, until the BART extention is done, the two don't hook up, which is inconvenient, but not impossible to deal with. Andrew On Thu, Feb 27, 2003 at 07:18:28PM -0500, RJ Atkinson wrote: > Subject: Re: [Isis-wg] Meeting in San Francisco > From: RJ Atkinson <rja@extremenetworks.com> > To: "'isis-wg@ietf.org'" <isis-wg@ietf.org> > In-Reply-To: <3E5DEEC5.4080106@net4u.ch> > X-Mailer: Apple Mail (2.551) > Errors-To: isis-wg-admin@ietf.org > X-BeenThere: isis-wg@ietf.org > X-Mailman-Version: 2.0.12 > Precedence: bulk > List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, > <mailto:isis-wg-request@ietf.org?subject=unsubscribe> > List-Id: IETF IS-IS working group <isis-wg.ietf.org> > List-Post: <mailto:isis-wg@ietf.org> > List-Help: <mailto:isis-wg-request@ietf.org?subject=help> > List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, > <mailto:isis-wg-request@ietf.org?subject=subscribe> > List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> > Date: Thu, 27 Feb 2003 19:18:28 -0500 > X-Spam-Status: No, hits=-3.9 required=5 > X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) > X-OriginalArrivalTime: 28 Feb 2003 00:22:02.0237 (UTC) FILETIME=[6A3E1AD0:01C2DEBF] > > > Oh, and if the only place one is going other than IETF is in Silicon > Valley, one should consider taking "Cal-Train". > > Cal-Train is the passenger rail system from San Francisco south down > the peninsula through Menlo Park, Palo Alto, Mt View, Sunnyvale, > Santa Clara, to San Jose. It works well -- as long as one's > destination is near a Cal-Train station. > > BART is the subway system for San Francisco, Berkeley, Oakland, > etc. One can use that to get to the norh/east side of the SF Bay > Area. > > I don't know any URLs, try Google if you need more data. > > Ran > > _______________________________________________ > 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 Fri Feb 28 02:52:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16673 for <isis-archive@lists.ietf.org>; Fri, 28 Feb 2003 02:52:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S816p05142; Fri, 28 Feb 2003 03:01:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1S7xmp05030 for <isis-wg@optimus.ietf.org>; Fri, 28 Feb 2003 02:59:48 -0500 Received: from dmz1.procket.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16567 for <isis-wg@ietf.org>; Fri, 28 Feb 2003 02:48:54 -0500 (EST) Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 3214223C34; Fri, 28 Feb 2003 00:04:00 -0800 (PST) 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 h1S7qoDw006586; Thu, 27 Feb 2003 23:52:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Isis-wg] Meeting in San Francisco Message-ID: <D2EC481073504E498A8DB9C0687E8CAF05D884E3@EXCHANGE0-0.na.procket.com> Thread-Topic: [Isis-wg] Meeting in San Francisco Thread-Index: AcLewutufhjjZRYFTpyZjbhuP8qDggAOvpWA From: "Tony Li" <Tony.Li@procket.com> To: <andrewl@xix-w.bengi.exodus.net>, "RJ Atkinson" <rja@extremenetworks.com> Cc: <isis-wg@ietf.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1S7xmp05031 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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Thu, 27 Feb 2003 23:52:50 -0800 Content-Transfer-Encoding: 8bit | BART: www.bart.gov | CalTrain: www.caltrain.com Muni: www.sfmuni.com Muni adminsters the bus, trolley and cable cars within SF proper. For even more info: www.transitinfo.org. Tony _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg From isis-wg-admin@ietf.org Fri Feb 28 07:45:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24345 for <isis-archive@lists.ietf.org>; Fri, 28 Feb 2003 07:45:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCrpp24266; Fri, 28 Feb 2003 07:53:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1SCbfp23184 for <isis-wg@optimus.ietf.org>; Fri, 28 Feb 2003 07:37:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22998; Fri, 28 Feb 2003 07:26:41 -0500 (EST) Message-Id: <200302281226.HAA22998@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-wg-mib-11.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: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe> List-Id: IETF IS-IS working group <isis-wg.ietf.org> List-Post: <mailto:isis-wg@ietf.org> List-Help: <mailto:isis-wg-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe> List-Archive: <https://www1.ietf.org/pipermail/isis-wg/> Date: Fri, 28 Feb 2003 07:26:41 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : Management Information Base for IS-IS Author(s) : J. Parker Filename : draft-ietf-isis-wg-mib-11.txt Pages : 92 Date : 2003-2-27 This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [RFC1195]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-mib-11.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isis-wg-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-mib-11.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-2-27135934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27135934.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www1.ietf.org/mailman/listinfo/isis-wg