From isis-wg-admin@external.juniper.net Wed May 3 01:29:28 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18061 for ; Wed, 3 May 2000 01:29:27 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA34433; Tue, 2 May 2000 22:37:24 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA34404 for ; Tue, 2 May 2000 22:37:15 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 03 May 2000 11:05:37 +0530 Received: from vanik ([172.16.1.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA21270 for ; Wed, 3 May 2000 10:44:08 +0530 Received: by localhost with Microsoft MAPI; Wed, 3 May 2000 10:53:52 +0530 Message-Id: <01BFB4ED.DEB33AC0.vanik@future.futsoft.com> From: Vani Sree K Reply-To: "vanik@future.futsoft.com" To: "'isis-wg@external.juniper.net'" Date: Wed, 3 May 2000 10:53:51 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Subject: [Isis-wg] Incremental SPF Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, Is there any document or guide that explains about incremental SPF. Can anyone provide the pointer to it, if any. Thanks Regards -vani _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon May 8 22:22:12 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26421 for ; Mon, 8 May 2000 22:22:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA43610; Mon, 8 May 2000 19:30:28 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA43578 for ; Mon, 8 May 2000 19:30:26 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA06955 for ; Mon, 8 May 2000 19:17:37 -0700 (PDT) Received: from ns.chinanet.cn.net ([202.97.7.6]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id TAA20925 for ; Mon, 8 May 2000 19:41:09 -0700 (PDT) (envelope-from shenjun@ns.chinanet.cn.net) Received: from sandy ([202.97.3.143]) by ns.chinanet.cn.net (8.9.3/8.9.3) with SMTP id LAA03255; Tue, 9 May 2000 11:17:13 +0900 (CDT) Message-ID: <03a901bfb95c$12899700$8f0361ca@sandy> From: "shenjun" To: Cc: Date: Tue, 9 May 2000 10:12:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Isis-wg] undescribe Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit undescribe _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon May 8 22:32:02 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27197 for ; Mon, 8 May 2000 22:32:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA43708; Mon, 8 May 2000 19:40:58 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA43682 for ; Mon, 8 May 2000 19:40:57 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA07663 for ; Mon, 8 May 2000 19:28:09 -0700 (PDT) Received: from ns.chinanet.cn.net ([202.97.7.6]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id TAA21083 for ; Mon, 8 May 2000 19:51:47 -0700 (PDT) (envelope-from shenjun@ns.chinanet.cn.net) Received: from sandy ([202.97.3.143]) by ns.chinanet.cn.net (8.9.3/8.9.3) with SMTP id LAA03301; Tue, 9 May 2000 11:28:01 +0900 (CDT) Message-ID: <045701bfb95d$947bc660$8f0361ca@sandy> From: "shenjun" To: Cc: Date: Tue, 9 May 2000 10:23:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Isis-wg] (no subject) Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit undescribe _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Mon May 8 22:37:47 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27641 for ; Mon, 8 May 2000 22:37:46 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA43809; Mon, 8 May 2000 19:47:36 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id TAA43781 for ; Mon, 8 May 2000 19:47:34 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id TAA08122 for ; Mon, 8 May 2000 19:34:46 -0700 (PDT) Received: from ns.chinanet.cn.net ([202.97.7.6]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id TAA21175 for ; Mon, 8 May 2000 19:58:21 -0700 (PDT) (envelope-from shenjun@ns.chinanet.cn.net) Received: from sandy ([202.97.3.143]) by ns.chinanet.cn.net (8.9.3/8.9.3) with SMTP id LAA03359; Tue, 9 May 2000 11:34:34 +0900 (CDT) Message-ID: <04ad01bfb95e$7e887640$8f0361ca@sandy> From: "shenjun" To: Cc: Date: Tue, 9 May 2000 10:29:38 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Isis-wg] (no subject) Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit unsubscribe> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sun May 14 04:12:55 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06285 for ; Sun, 14 May 2000 04:12:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA52459; Sun, 14 May 2000 01:20:08 -0700 (PDT) Received: from arthur.caida.org (arthur.caida.org [204.212.46.6]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA52427 for ; Sun, 14 May 2000 01:20:06 -0700 (PDT) Received: from arthur.caida.org (localhost.caida.org [127.0.0.1]) by arthur.caida.org (8.9.0/8.9.0.Beta5) with ESMTP id EAA92401 for ; Sun, 14 May 2000 04:06:39 -0400 (EDT) Message-Id: <200005140806.EAA92401@arthur.caida.org> To: isis-wg@external.juniper.net Date: Sun, 14 May 2000 04:06:39 -0400 From: Daniel McRobb Subject: [Isis-wg] draft-ietf-isis-wg-mib-02 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I'm new to the list, so please forgive me if this issue has come up before (I dind't find it in a cursory search of the archives)... Is there any interest in making isisISAdjUpTime semantics similar to bgpPeerFsmEstablishedTime from BGP4-MIB, making it the number of seconds the adjacency has been 'up' if the current state is 'up', and seconds passed since the adjacency was last 'up' if the current state is not 'up'? I personally prefer these semantics (even if we define notifications for adjacency changes). Daniel ~~~~~~ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 07:53:14 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03206 for ; Thu, 18 May 2000 07:53:14 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA58168; Thu, 18 May 2000 04:58:13 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA58140 for ; Thu, 18 May 2000 04:58:11 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id EAA24065 for ; Thu, 18 May 2000 04:44:15 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id FAA13483 for ; Thu, 18 May 2000 05:09:17 -0700 (PDT) (envelope-from navaneethk@future.futsoft.com) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 18 May 2000 17:23:12 +0530 Received: from narenr.future.futsoft.com ([172.16.1.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id RAA07118 for ; Thu, 18 May 2000 17:00:36 +0530 Received: by localhost with Microsoft MAPI; Thu, 18 May 2000 17:12:19 +0530 Message-Id: <01BFC0EC.394C9BC0.navaneethk@future.futsoft.com> From: Navaneeth K Reply-To: "navaneethk@future.futsoft.com" To: "'isis-wg@juniper.net'" Date: Thu, 18 May 2000 17:12:18 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Clarification on Dual ISIS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi, The doubt is regarding a Dual environment where integrated ISIS is deployed. In this scenario, i. Is it possible for a system reachable through a circuit to have both IP and OSI addresses simultaneously? ii. In Dual routers, normally are both the IP and OSI addresses valid at the same time? According to RFC 1195, A dual router must be capable of routing both IP and OSI packets. Are there Any address considerations in this regard? Thanx Navaneeth. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 08:13:07 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03691 for ; Thu, 18 May 2000 08:13:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA58278; Thu, 18 May 2000 05:19:41 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id FAA58250 for ; Thu, 18 May 2000 05:19:39 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id FAA25436 for ; Thu, 18 May 2000 05:05:43 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id FAA13792 for ; Thu, 18 May 2000 05:30:47 -0700 (PDT) (envelope-from henk@Procket.com) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id FAA19374; Thu, 18 May 2000 05:05:09 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id OAA00802; Thu, 18 May 2000 14:14:42 +0200 Message-Id: <200005181214.OAA00802@kraak.procket.com> Subject: Re: [Isis-wg] Clarification on Dual ISIS To: navaneethk@future.futsoft.com Date: Thu, 18 May 2000 14:14:41 +0200 (MEST) Cc: isis-wg@juniper.net ('isis-wg@juniper.net') In-Reply-To: <01BFC0EC.394C9BC0.navaneethk@future.futsoft.com> from "Navaneeth K" at May 18, 2000 05:12:18 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Hi, > The doubt is regarding a Dual environment where integrated ISIS is > deployed. > In this scenario, > i. Is it possible for a system reachable through a circuit to have both > IP and OSI addresses simultaneously? Yes. Note, IP addresses are interface specific. E.g. each interface typically has one IP address. OSI addresses (NSAPs) are box specific. E.g. typically each router or each hosts has a single OSI address. > ii. In Dual routers, normally are both the IP and OSI addresses valid at > the same time? That is the definition of a Dual router. An ISIS-CLNS router has and OSI address (an NSAP), forwards CLNS packets, and does not forward IP packets. An ISIS-IP router has an IP addresses, forwards IP packets, and does not forward CLNS packets. Typically an ISIS-IP router still has an NSAP configured, because it needs a systemID and an area-address. A Dual router has all of that combined. IP addresses, an NSAP, and it does forward IP and CLNS packets. > According to RFC 1195, A dual router must be capable of routing both IP > and OSI packets. Are there Any address considerations in this regard? Not that I can think of. IP and OSI address space are independant. But don't forget that typically the NSAP is used to derive the systemID and the area-address. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 09:56:40 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06607 for ; Thu, 18 May 2000 09:56:39 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA58546; Thu, 18 May 2000 07:04:37 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA58519 for ; Thu, 18 May 2000 07:04:35 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA00303 for ; Thu, 18 May 2000 06:50:38 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id HAA15511 for ; Thu, 18 May 2000 07:15:43 -0700 (PDT) (envelope-from jparker@nexabit.com) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id JAA03650; Thu, 18 May 2000 09:49:20 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 09:49:20 -0400 Message-ID: From: Jeff Parker To: Henk Smit , navaneethk@future.futsoft.com Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Clarification on Dual ISIS Date: Thu, 18 May 2000 09:49:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > Note, IP addresses are interface specific. E.g. each > interface typically has one IP address. OSI addresses and the new TLV for Router ID that provides a unique IP address for a box. - jeff parker - Nexabit _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 11:47:24 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09127 for ; Thu, 18 May 2000 11:47:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA58733; Thu, 18 May 2000 08:54:47 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA58703 for ; Thu, 18 May 2000 08:54:45 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA08672 for ; Thu, 18 May 2000 08:40:47 -0700 (PDT) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by rojo.juniper.net (8.9.3/8.9.3) with SMTP id JAA18338 for ; Thu, 18 May 2000 09:05:53 -0700 (PDT) (envelope-from ben.abarbanel@ipoptical.com) Received: (cpmta 17008 invoked from network); 18 May 2000 08:40:15 -0700 Received: from dhcp182.altasoft.com (HELO bena) (204.242.142.182) by smtp.ipoptical.com with SMTP; 18 May 2000 08:40:15 -0700 X-Sent: 18 May 2000 15:40:15 GMT Message-ID: <002301bfc0f8$a13cc500$b68ef2cc@cysive.com> From: "ben abarbanel" To: "Henk Smit" , Cc: References: <200005181214.OAA00802@kraak.procket.com> Subject: Re: [Isis-wg] Clarification on Dual ISIS Date: Thu, 18 May 2000 09:35:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Does anybody know where I can purchase a reliable implementation of ISIS with dual mode. Thanks, Ben ----- Original Message ----- From: Henk Smit To: Cc: Sent: Thursday, May 18, 2000 5:14 AM Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > Hi, > > The doubt is regarding a Dual environment where integrated ISIS is > > deployed. > > In this scenario, > > i. Is it possible for a system reachable through a circuit to have both > > IP and OSI addresses simultaneously? > > Yes. > Note, IP addresses are interface specific. E.g. each interface typically > has one IP address. OSI addresses (NSAPs) are box specific. E.g. typically > each router or each hosts has a single OSI address. > > > ii. In Dual routers, normally are both the IP and OSI addresses valid at > > the same time? > > That is the definition of a Dual router. > An ISIS-CLNS router has and OSI address (an NSAP), forwards CLNS packets, > and does not forward IP packets. > An ISIS-IP router has an IP addresses, forwards IP packets, and does not > forward CLNS packets. Typically an ISIS-IP router still has an NSAP > configured, because it needs a systemID and an area-address. > > A Dual router has all of that combined. IP addresses, an NSAP, and it > does forward IP and CLNS packets. > > > According to RFC 1195, A dual router must be capable of routing both IP > > and OSI packets. Are there Any address considerations in this regard? > > Not that I can think of. IP and OSI address space are independant. > But don't forget that typically the NSAP is used to derive the systemID > and the area-address. > > Hope this helps, > > Henk. > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 12:00:21 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09437 for ; Thu, 18 May 2000 12:00:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA58861; Thu, 18 May 2000 09:11:27 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA58831 for ; Thu, 18 May 2000 09:11:26 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id IAA09983 for ; Thu, 18 May 2000 08:57:28 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id JAA18742 for ; Thu, 18 May 2000 09:22:34 -0700 (PDT) (envelope-from jparker@nexabit.com) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id LAA04668; Thu, 18 May 2000 11:56:55 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 11:56:55 -0400 Message-ID: From: Jeff Parker To: ben abarbanel Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Clarification on Dual ISIS Date: Thu, 18 May 2000 11:56:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > -----Original Message----- > From: ben abarbanel [mailto:ben.abarbanel@ipoptical.com] > Sent: Thursday, May 18, 2000 12:36 PM > To: Henk Smit; navaneethk@future.futsoft.com > Cc: isis-wg@juniper.net > Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > Does anybody know where I can purchase a reliable > implementation of ISIS > with dual mode. > > Thanks, > Ben Ben - Are you looking to route both OSI and IP, or are you asking for dual mode because you want to route IP? - jeff parker - Nexabit Networks - Lucent Technologies _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 13:15:51 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10754 for ; Thu, 18 May 2000 13:15:49 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA59021; Thu, 18 May 2000 10:23:25 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA58990 for ; Thu, 18 May 2000 10:23:24 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA15289 for ; Thu, 18 May 2000 10:09:25 -0700 (PDT) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by rojo.juniper.net (8.9.3/8.9.3) with SMTP id KAA20837 for ; Thu, 18 May 2000 10:34:31 -0700 (PDT) (envelope-from emmanuel.dauvergne@rd.francetelecom.fr) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Thu, 18 May 2000 19:09:04 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B444@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS To: "'isis-wg@juniper.net'" Date: Thu, 18 May 2000 19:09:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] Behavior upon new adjacency Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hello, A few questions regarding the Update Process and the Decision Process upon new adjacency event. 1. Update Process : Upon an LSP generation (either a periodic regeneration or an event driven generation), ISO10589 indicates that the LSP(s) shall be sent on every circuit with an IS adjacency of the appropriate level, by setting the SRMFlag on each circuits. In the case of an new adjacency (event driven generation), is there any restriction regarding the circuit corresponding to this new adjacency which has triggered the generation of the LSP? According to the spec, the LSP shall be sent on that circuit as well, but is it recommended to wait for a certain time before sending routing information through that new adjacency? In that same case what chronological order should be respected between the sending of LSP and CSNP (p2p link)? 2. Decision Process : ISO10589 indicates that any topological change (notified by the update process) can trigger an SPF calculation. Is a new adjacency considered as a topological change? Shouldn't the local router wait for the LSP of the new adjacent router before triggering the SPF calculation? Thanks for your time Manu _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 13:40:43 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11061 for ; Thu, 18 May 2000 13:40:42 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA59194; Thu, 18 May 2000 10:48:08 -0700 (PDT) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id KAA59167 for ; Thu, 18 May 2000 10:48:06 -0700 (PDT) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id TAA05492 for isis-wg@external.juniper.net; Thu, 18 May 2000 19:31:15 +0200 From: Tony Przygienda Message-Id: <200005181731.TAA05492@net4u.net4u.ch> To: isis-wg@external.juniper.net Date: Thu, 18 May 2000 19:31:14 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Isis-wg] last calls ... Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit After simmering for a while and enough experience following drafts are going last call: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt 4. draft-kaplan-isis-ext-eth-01.txt Authors of 4. pls comment whether you want to pursuit informational, experimental or standards track. 1-3 are informational. Last call ends June 3rd thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 14:21:34 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11641 for ; Thu, 18 May 2000 14:21:33 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA59380; Thu, 18 May 2000 11:31:47 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA59312 for ; Thu, 18 May 2000 11:31:44 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA20567 for ; Thu, 18 May 2000 11:17:43 -0700 (PDT) Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by rojo.juniper.net (8.9.3/8.9.3) with SMTP id LAA22898 for ; Thu, 18 May 2000 11:42:50 -0700 (PDT) (envelope-from ben.abarbanel@ipoptical.com) Received: (cpmta 29153 invoked from network); 18 May 2000 10:15:05 -0700 Received: from dhcp182.altasoft.com (HELO bena) (204.242.142.182) by smtp.ipoptical.com with SMTP; 18 May 2000 10:15:05 -0700 X-Sent: 18 May 2000 17:15:05 GMT Message-ID: <003501bfc105$e0d95540$b68ef2cc@cysive.com> From: "ben abarbanel" To: "Jeff Parker" Cc: References: Subject: Re: [Isis-wg] Clarification on Dual ISIS Date: Thu, 18 May 2000 13:15:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Looking for dual mode to route IP. Regards, Ben ----- Original Message ----- From: Jeff Parker To: ben abarbanel Cc: Sent: Thursday, May 18, 2000 8:56 AM Subject: RE: [Isis-wg] Clarification on Dual ISIS > > -----Original Message----- > > From: ben abarbanel [mailto:ben.abarbanel@ipoptical.com] > > Sent: Thursday, May 18, 2000 12:36 PM > > To: Henk Smit; navaneethk@future.futsoft.com > > Cc: isis-wg@juniper.net > > Subject: Re: [Isis-wg] Clarification on Dual ISIS > > > > > > Does anybody know where I can purchase a reliable > > implementation of ISIS > > with dual mode. > > > > Thanks, > > Ben > > Ben - > Are you looking to route both OSI and IP, > or are you asking for dual mode because you > want to route IP? > > - jeff parker > - Nexabit Networks > - Lucent Technologies > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 14:29:59 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11719 for ; Thu, 18 May 2000 14:29:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA59484; Thu, 18 May 2000 11:38:48 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA59457 for ; Thu, 18 May 2000 11:38:47 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA21003 for ; Thu, 18 May 2000 11:24:48 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id LAA23087 for ; Thu, 18 May 2000 11:49:55 -0700 (PDT) (envelope-from jparker@nexabit.com) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id OAA05712; Thu, 18 May 2000 14:24:16 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 14:24:16 -0400 Message-ID: From: Jeff Parker To: ben abarbanel Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] Clarification on Dual ISIS Date: Thu, 18 May 2000 14:24:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > > > Does anybody know where I can purchase a reliable > > > implementation of ISIS > > > with dual mode. > > > > > > Thanks, > > > Ben Ben - If you intend to route IP, then the usual suspects (ourselves included) ship a version of ISIS. I'm not sure that this is the venue to discuss reliability of implementations rather than protocols. I'm not sure how much recent work there has been on routing both OSI and IP using IS-IS. - jeff parker - Nexabit Networks - Lucent Technologies _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 15:50:54 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12365 for ; Thu, 18 May 2000 15:50:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA59805; Thu, 18 May 2000 13:01:07 -0700 (PDT) Received: from mail.rdc1.nj.home.com (ha1.rdc1.nj.home.com [24.3.128.66]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63410 for ; Mon, 17 Jan 2000 13:20:05 -0800 (PST) Received: from siara.com ([24.6.232.151]) by mail.rdc1.nj.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000117211452.GGEN3365.mail.rdc1.nj.home.com@siara.com>; Mon, 17 Jan 2000 13:14:52 -0800 Message-ID: <3883864D.EFA54AA0@siara.com> Date: Mon, 17 Jan 2000 16:14:54 -0500 From: Tony Przygienda Reply-To: prz@siara.com Organization: Siara Systems Inc. X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Jeff Learman , Jorge , IS-IS-Group Subject: Re: [Isis-wg] Problem for Support Frame Relay . References: <3883469B.7F8F9532@siara.com> <1829.000117@amt.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Monday, January 17, 2000, 7:43:07 PM, Tony Przygienda wrote: > > again, first a problem statement would be nice to make sure > > we're all tackling the same problem. > > Well, I think Jorge's initial messages are quite > clear on that---running IS-IS over NBMA media. > ...and whichever issues related :) again, it may be the partial mesh problem (the protocol needs to understand the topology correctly) or the "running over dial-up links" problem. > > 2nd, Alex, you're oversimpliofying here ;-) > > Tony, I'm not. I'm just correcting the statement > that on-demand VCs cannot be used with IS-IS. this part you don't, right. But after that you're saying it's easy and doesn't need anything, that's at least slightly oversimplifying. You can run it that way but you'll stop pretty soon after the montly bills come. If you don't beleive me, try an ISDN link with OSPF active ;-) > > Just "running" > > the protocol that way leads to extensive thrashing of up&downs > > of the circuit > > Quoting myself: > > "...provided that the idle timer doesn't close > the VC before the next Hello PDU is sent over it." then de-facto you _never_ close the circuit wyhen the protocol is running and if you're paying usage, that's expensive stuff, either charged per data unit or per time unit (2nd is worse normally). If that's the soluiton people are happy with (but weren't in OSPF) then de facto, no work needs tio be done in layer 3 and Alex's right. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 15:54:04 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12402 for ; Thu, 18 May 2000 15:54:03 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA59863; Thu, 18 May 2000 13:04:37 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA59507 for ; Thu, 18 May 2000 11:39:50 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA21086 for ; Thu, 18 May 2000 11:25:52 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id LAA23129 for ; Thu, 18 May 2000 11:50:59 -0700 (PDT) (envelope-from tli@Procket.com) Received: (from tli@localhost) by miata.procket.com (8.9.3/8.9.3) id LAA29781; Thu, 18 May 2000 11:25:20 -0700 Date: Thu, 18 May 2000 11:25:20 -0700 Message-Id: <200005181825.LAA29781@miata.procket.com> X-Confidential: Procket Confidential/Need to know X-Authentication-Warning: miata.procket.com: tli set sender to tli@miata.procket.com using -f From: Tony Li To: ben.abarbanel@ipoptical.com CC: jparker@nexabit.com, isis-wg@juniper.net In-reply-to: <003501bfc105$e0d95540$b68ef2cc@cysive.com> (ben.abarbanel@ipoptical.com) Subject: Re: [Isis-wg] Clarification on Dual ISIS References: <003501bfc105$e0d95540$b68ef2cc@cysive.com> Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net | Looking for dual mode to route IP. There is at least one implementation in the world that routes IP but not CLNP. This can't strictly be called dual mode. Tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:01:53 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12505 for ; Thu, 18 May 2000 16:01:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60044; Thu, 18 May 2000 13:11:17 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA00239 for ; Wed, 12 Apr 2000 04:20:56 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id EAA28287 for ; Wed, 12 Apr 2000 04:11:23 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id EAA53587 for ; Wed, 12 Apr 2000 04:31:08 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15127; Wed, 12 Apr 2000 07:11:20 -0400 (EDT) Message-Id: <200004121111.HAA15127@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 12 Apr 2000 07:11:20 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-hmac-01.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IS-IS for IP Internets Working Group of the IETF. Title : IS-IS Cryptographic Authentication Author(s) : T. Li, R. Atkinson Filename : draft-ietf-isis-hmac-01.txt Pages : 11 Date : 11-Apr-00 This document specifies an algorithm-independent cryptographic authentication mechanism for use with the IS-IS routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-hmac-01.txt 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-hmac-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-hmac-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000411095848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-hmac-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-hmac-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000411095848.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:23 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12534 for ; Thu, 18 May 2000 16:05:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60251; Thu, 18 May 2000 13:14:35 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id CAA34872 for ; Wed, 3 May 2000 02:51:45 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 03 May 2000 15:19:51 +0530 Received: from narenr.future.futsoft.com ([172.16.1.15]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA28256; Wed, 3 May 2000 14:58:07 +0530 Received: by localhost with Microsoft MAPI; Wed, 3 May 2000 15:08:37 +0530 Message-Id: <01BFB511.75007920.navaneethk@future.futsoft.com> From: Navaneeth K Reply-To: "navaneethk@future.futsoft.com" To: "'jparker@nexabit.com'" Date: Wed, 3 May 2000 15:08:35 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Clarification on ISIS MIB Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi... My doubt is with regard to the ISIS MIB.. In the IpRA table, There is a field for the IpRASNPA address.. This is mentioned as to be used as the NextHop for reaching the Reachable address.. But in case of IP , How can the NExtHop address be got.. Since the SNPA address is equivalent to the MAC address, what address can be considered as the nexthop address? Please Clarify. Thanx Navaneeth. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:27 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12545 for ; Thu, 18 May 2000 16:05:26 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60145; Thu, 18 May 2000 13:14:27 -0700 (PDT) Received: from prz-laptop.redback.com (prz-laptop.redback.com [155.53.36.102]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA57227 for ; Wed, 17 May 2000 15:33:26 -0700 (PDT) Received: (from root@localhost) by prz-laptop.redback.com (8.8.8/8.8.8) id QAA00569 for isis-wg@external.juniper.net; Wed, 17 May 2000 16:12:48 -0700 (PDT) Date: Wed, 17 May 2000 16:12:48 -0700 (PDT) From: Charlie Root Message-Id: <200005172312.QAA00569@prz-laptop.redback.com> To: isis-wg@external.juniper.net Subject: [Isis-wg] Last call started for 3 drafts Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net going last call for informational: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt Last calls end June 2nd thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:32 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12556 for ; Thu, 18 May 2000 16:05:32 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60248; Thu, 18 May 2000 13:14:35 -0700 (PDT) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by external.juniper.net (8.9.3/8.9.3) with SMTP id CAA14527 for ; Fri, 21 Apr 2000 02:56:29 -0700 (PDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <2KJV5QGB>; Fri, 21 Apr 2000 11:45:42 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B3F0@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS To: isis-wg@external.juniper.net Date: Fri, 21 Apr 2000 11:45:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [Isis-wg] ID status ? Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, Just a refresh regarding 2 IDs : Is the ISIS WG still concerned with OMP works? (The last ID I read was draft-ietf-isis-omp-01) Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved to the TEWG? Regardless of subTLV specifications, what is the status of the "wider metric" concept which was introduced in that ID? Thanks Manu _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:38 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12566 for ; Thu, 18 May 2000 16:05:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60118; Thu, 18 May 2000 13:14:25 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA57202 for ; Wed, 17 May 2000 15:30:55 -0700 (PDT) From: prz@redback.com Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 9E0B52AA25 for ; Wed, 17 May 2000 15:17:02 -0700 (PDT) Received: (from prz@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id PAA27650 for isis-wg@external.juniper.net; Wed, 17 May 2000 15:16:16 -0700 (PDT) Date: Wed, 17 May 2000 15:16:16 -0700 (PDT) Message-Id: <200005172216.PAA27650@malt.redback.com> Content-Type: text Subject: [Isis-wg] (no subject) Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net going last call for informational: 1. draft-ietf-isis-wg-255adj-02.txt 2. draft-ietf-isis-domain-wide-02.txt 3. draft-ietf-isis-wg-mesh-group-00.txt Last calls end June 2nd thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:45 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12576 for ; Thu, 18 May 2000 16:05:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60537; Thu, 18 May 2000 13:15:02 -0700 (PDT) Received: from postal.redback.com (postal.redback.com [155.53.12.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA13580 for ; Thu, 20 Apr 2000 13:06:36 -0700 (PDT) Received: from redback.com (prz-laptop.redback.com [155.53.36.102]) by postal.redback.com (Postfix) with ESMTP id D57502AA02; Thu, 20 Apr 2000 12:56:01 -0700 (PDT) Message-ID: <38FF6DD3.C7DD34D5@redback.com> Date: Thu, 20 Apr 2000 13:51:32 -0700 From: Tony Przygienda Reply-To: prz@redback.com Organization: Redback Networks X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: Henk Smit Cc: navaneethk@future.futsoft.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] Clarification.. References: <200004201737.KAA14550@redd210.procket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Henk Smit wrote: > > Thanks for the reponse. > > I still have one doubt.. Can we use these addresses advetised in LSP TLV's > > for next hop addresses.Since these addresses have no specific mapping to > > the IP reachability information. > > Please correct me if I'm wrong. > > Ai, sorry, I was to quick in my reply. > The IP interface address TLV (TLV #132) I was talking about are the IP > interface address TLVs used in *hellos*. Not in LSPs. > > In LSPs there is the same TLV (TLV #132). But those have no practical use. > And you are not supposed to use them in your routing calculations. > The easiest thing is to just ignore them during your SPF computation. You are not supposed to use them in the routing calculations, so far Henk's correct, but some people use them as the management address of the router so basically if they need to connect to the box to manage it, they use this specific address. That way you can advertise a stable loopback independent from the fact whether certain router interfaces are up or not ... One can solve the problem in different ways as well but that's one way ... just my 2c -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:52 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12587 for ; Thu, 18 May 2000 16:05:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60207; Thu, 18 May 2000 13:14:32 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id BAA57780 for ; Thu, 18 May 2000 01:34:25 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id BAA16112 for ; Thu, 18 May 2000 01:20:29 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id BAA11530 for ; Thu, 18 May 2000 01:45:32 -0700 (PDT) (envelope-from ethkkg@etxb.ericsson.se) Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.9) with ESMTP id e4I8KPq14040 for ; Thu, 18 May 2000 10:20:25 +0200 (MET DST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 18 May 2000 10:18:27 +0200 Received: from esealnt409-in.al.sw.ericsson.se ([153.88.251.32]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 18 May 2000 08:18:27 0000 (GMT) Received: from esealnt400.al.sw.ericsson.se ([153.88.251.21]) by esealnt409-in.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 18 May 2000 10:18:27 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Thu, 18 May 2000 10:20:23 +0200 Message-ID: From: "Gabor Korossy (ETH)" To: mpls@UU.NET, "'isis-wg@juniper.net'" , "'te-wg@uu.net'" Date: Thu, 18 May 2000 10:20:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 18 May 2000 08:18:27.0859 (UTC) FILETIME=[A4E7DE30:01BFC0A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id BAA57781 Subject: [Isis-wg] RE: MPLS and IS-IS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 8bit Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:54 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12597 for ; Thu, 18 May 2000 16:05:53 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60461; Thu, 18 May 2000 13:14:57 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA10537 for ; Wed, 19 Apr 2000 03:54:07 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.8.8/8.8.5) with ESMTP id DAA26211 for ; Wed, 19 Apr 2000 03:43:45 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id EAA72713 for ; Wed, 19 Apr 2000 04:04:30 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02780; Wed, 19 Apr 2000 06:43:41 -0400 (EDT) Message-Id: <200004191043.GAA02780@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 19 Apr 2000 06:43:40 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-snp-checksum-01.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --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 : Optional Checksums in ISIS Author(s) : A. Przygienda Filename : draft-ietf-isis-wg-snp-checksum-01.txt Pages : 3 Date : 18-Apr-00 This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt 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-snp-checksum-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000418080618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-wg-snp-checksum-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-wg-snp-checksum-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000418080618.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:05:59 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12608 for ; Thu, 18 May 2000 16:05:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60327; Thu, 18 May 2000 13:14:43 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id AAA23078 for ; Wed, 26 Apr 2000 00:41:11 -0700 (PDT) Received: from siara.com (adsl-63-200-50-92.dsl.snfc21.pacbell.net) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FTM0052P4P26W@mta6.snfc21.pbi.net> for isis-wg@external.juniper.net; Wed, 26 Apr 2000 00:27:03 -0700 (PDT) Date: Wed, 26 Apr 2000 01:22:10 -0700 From: Tony Przygienda Subject: Re: [Isis-wg] ID status ? To: DAUVERGNE Emmanuel FTRD/DAC/ISS Cc: "'isis-wg@external.juniper.net'" Reply-to: prz@siara.com Message-id: <3906A731.4E78412B@siara.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <98388C05D464D111B61800805F1504160148B3FD@p-ibis.issy.cnet.fr> Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit DAUVERGNE Emmanuel FTRD/DAC/ISS wrote: > Hi, > > Just a refresh regarding 2 IDs : > > Is the ISIS WG still concerned with OMP works? (The last ID I read was > draft-ietf-isis-omp-01, and it disapeared from the IETF server) expired a while ago. > Is there any update of draft-ietf-isis-traffic-01.txt? Did this work moved > to the TEWG? > Regardless of subTLV specifications, what is the status of the "wider > metric" concept which was introduced in that ID? Henk promised a new version in 2--3 weeks (and it was 2--3 weeks ago ;-) thanks -- tony > > > Thanks > Manu > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:06:16 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12618 for ; Thu, 18 May 2000 16:06:15 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60397; Thu, 18 May 2000 13:14:50 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id EAA47118 for ; Thu, 11 May 2000 04:10:25 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id DAA05146 for ; Thu, 11 May 2000 03:57:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id EAA73931 for ; Thu, 11 May 2000 04:21:23 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23479; Thu, 11 May 2000 06:57:18 -0400 (EDT) Message-Id: <200005111057.GAA23479@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 11 May 2000 06:57:18 -0400 Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-01.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --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 : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-01.txt Pages : 4 Date : 10-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-01.txt 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-kaplan-isis-ext-eth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:07:01 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12631 for ; Thu, 18 May 2000 16:06:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60399; Thu, 18 May 2000 13:14:52 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA45921 for ; Wed, 10 May 2000 06:26:47 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id GAA14674 for ; Wed, 10 May 2000 06:13:48 -0700 (PDT) Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id GAA51469 for ; Wed, 10 May 2000 06:37:42 -0700 (PDT) (envelope-from jkaplan@UU.NET) Received: from gen3.ffx.ops.us.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiooq27915 for ; Wed, 10 May 2000 13:13:47 GMT Received: from haiti.corp.us.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: haiti.corp.us.uu.net [153.39.146.67]) id QQiooq01482; Wed, 10 May 2000 09:13:35 -0400 (EDT) Received: from localhost by haiti.corp.us.uu.net with ESMTP (peer crosschecked as: jkaplan@localhost) id QQiooq12382; Wed, 10 May 2000 09:13:35 -0400 (EDT) Date: Wed, 10 May 2000 09:13:35 -0400 (EDT) From: Jed Kaplan X-Sender: jkaplan@haiti.corp.us.uu.net To: isis-wg@juniper.net cc: jkalpan@UU.NET Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-684387517-957964415=:12311" Subject: [Isis-wg] Extended Ethernet Frame Size Support Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-684387517-957964415=:12311 Content-Type: TEXT/PLAIN; charset=US-ASCII A revised ISIS draft (draft-kaplan-isis-ext-eth-01.txt) by O'Dell, Kaplan, Hayes, Schroeder, Singh, and Hsu entitled: "Extended Ethernet Frame Size Support" has been submitted to the IETF. The is a resubmission of the draft, draft-kaplan-isis-ext-eth-00.txt, that expired in November, 1999. The sole change to the draft was an update of authorship. The draft abstract is: This document presents an extension to the current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. Jed kaplan jkaplan@uu.net ---559023410-684387517-957964415=:12311 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-kaplan-isis-ext-eth-01.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-kaplan-isis-ext-eth-01.txt" Content-Transfer-Encoding: BASE64 TmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBNaWtlIE8nRGVsbA0KSW50ZXJuZXQgRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKZWQgS2FwbGFu DQpFeHBpcmF0aW9uIERhdGU6IE5vdmVtYmVyIDE5OTkJCQkJVVVORVQgVGVj aG5vbG9naWVzLCBJbmMuDQoNCgkJCQkJCQlKb2huIEhheWVzDQoJCQkJCQkJ VGVkIFNjaHJvZWRlcg0KCQkJCQkJCUFsdGVvbiBXZWJTeXN0ZW1zLCBJbmMu DQoJCQkJCQkJDQoJCQkJCQkJUC5KLiBTaW5naA0KCQkJCQkJCVBhY2tldCBF bmdpbmVzLCBJbmMuDQoNCgkJCQkJCQlEYWVtb24gTW9ycmVsbA0KCQkJCQkJ CUp1bmlwZXIgTmV0d29ya3MsIEluYy4NCg0KCQkJCQkJCUplbm5pZmVyIEhz dQ0KCQkJCQkJDQoNCg0KCSAgICAgICAgICBFeHRlbmRlZCBFdGhlcm5ldCBG cmFtZSBTaXplIFN1cHBvcnQgDQoNCgkJICAgIGRyYWZ0LWthcGxhbi1pc2lz LWV4dC1ldGgtMDAudHh0DQoNCg0KMS4gU3RhdHVzIG9mIHRoaXMgTWVtbw0K DQoJVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMg aW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIA0KCWFsbCBwcm92aXNpb25zIG9m IFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KCUludGVybmV0LURyYWZ0cyBh cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nDQoJVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3 b3JraW5nIGdyb3Vwcy4gTm90ZSB0aGF0DQoJb3RoZXIgZ3JvdXBzIG1heSBh bHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt DQoJRHJhZnRzLg0KDQoJSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1 bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIA0KCWFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55DQoJdGltZS4gSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KCW1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiINCg0KCVRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt RHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCglodHRwOi8vd3d3LmlldGYu b3JnL2lldGYvbGlkLWFic3RyYWN0cy50eHQNCg0KCVRoZSBsaXN0IG9mIElu dGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQNCglodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQoNCg0K Mi4gQWJzdHJhY3QNCg0KCVRoaXMgZG9jdW1lbnQgcHJlc2VudHMgYW4gZXh0 ZW5zaW9uIHRvIGN1cnJlbnQgRXRoZXJuZXQgRnJhbWUgDQoJc3RhbmRhcmRz IHRvIHN1cHBvcnQgcGF5bG9hZHMgZ3JlYXRlciB0aGFuIDE1MDAgQnl0ZXMg Zm9yIEV0aGVybmV0X0lJDQoJYW5kIDgwMi4zIGZyYW1lcy4gVGhpcyBpcyB1 c2VmdWwgZm9yIEdpZ2FiaXQgRXRoZXJuZXQgdGVjaG5vbG9neSwgDQogICAg ICAgIHByb3ZpZGluZyBhIG1lYW5zIHRvIGNhcnJ5IGxhcmdlIE1UVSBwYWNr ZXRzIHdpdGhvdXQgZnJhZ21lbnRhdGlvbiANCiAgICAgICAgb3ZlciBhIGhp Z2gtc3BlZWQgYnJvYWRjYXN0IG5ldHdvcmsuDQoNCjMuIE92ZXJ2aWV3DQoN CglUaGVyZSBhcmUgdHdvIGZ1bmRhbWVudGFsIGZyYW1lIHR5cGVzIGRlZmlu ZWQgZm9yIEV0aGVybmV0Og0KCUV0aGVybmV0IElJIFtFVEhdIFtSRkM4OTRd IGFuZCA4MDIuMyBbSUVFRTgwMi4zXS4gODAyLjMgaGVhZGVycw0KCW1heSBi ZSBmb2xsb3dlZCBieSBhIExvZ2ljYWwgTGluayBDb250cm9sIGhlYWRlciwN Cgk4MDIuMiBbSUVFRTgwMi4yXS4gQm90aCB0eXBlcyBvZiBlbmNhcHN1bGF0 aW9ucyBjYW4gY28tZXhpc3Qgb24NCgl0aGUgc2FtZSBtZWRpYSBhdCB0aGUg c2FtZSB0aW1lLiBFbmNvZGluZ3MgZm9yIEV0aGVybmV0IElJIGFuZCA4MDIu Mw0KCWZyYW1lcyBldm9sdmVkIHN1Y2ggdGhhdCwgYXMgbG9uZyBhcyBwYXls b2FkcyB3ZXJlIGxlc3MgdGhhbiAxNTAwDQoJYnl0ZXMsIEV0aGVybmV0IElJ IGZyYW1lcyBjb3VsZCBhbHdheXMgYmUgZGlzdGluZ3Vpc2hlZCBmcm9tDQoJ SUVFRSA4MDIuMyBmcmFtZXMuDQoNCglIb3dldmVyLCB3aGVuIHRoZSBwYXls b2FkIGlzIGdyZWF0ZXIgdGhhbiAxNTAwIGJ5dGVzIGZyYW1lcyBtYXkgDQog ICAgICAgIG5vdCBiZSB1bmlxdWVseSBkaXN0aW5ndWlzaGFibGUgYXMgY29u Zm9ybWluZyB0byBFdGhlcm5ldCBJSSBvciANCiAgICAgICAgODAyLjMgZm9y bWF0cy4gVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBFdGhlcm5ldCBmcmFt ZSBmb3JtYXQgDQoJdG8gYWxsb3cgRXRoZXJuZXRfSUkgb3IgODAyLjMgZnJh bWUgcGF5bG9hZHMgbGFyZ2VyIHRoYW4gMTUwMCBieXRlcyANCiAgICAgICAg dG8gYmUgdW5pcXVlbHkgZGlzdGluZ3Vpc2hlZC4NCg0KNC4gRXRoZXJuZXQg RnJhbWUgRm9ybWF0cw0KDQoJQS4gRXRoZXJuZXQgSUkNCgkJDQoJCSstLS0t Ky0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLSsNCgkJfCBEQSB8IFNBIHwgVHlw ZSB8IERhdGEgfCBGQ1MgfA0KCQkrLS0tLSstLS0tKy0tLS0tLSstLS0tLS0r LS0tLS0rDQoJICANCgkJREEgICAgICBEZXN0aW5hdGlvbiBNQUMgQWRkcmVz cyAoNiBieXRlcykNCgkJU0EgICAgICBTb3VyY2UgTUFDIEFkZHJlc3MgICAg ICAoNiBieXRlcykNCgkJVHlwZSAgICBQcm90b2NvbCBUeXBlICAgICAgICAg ICAoMiBieXRlcykNCgkJRGF0YSAgICBQcm90b2NvbCBEYXRhICAgICAgICAg ICAoNDYgLSAxNTAwIGJ5dGVzKQ0KCQlGQ1MgICAgIEZyYW1lIENoZWNrc3Vt ICAgICAgICAgICg0IGJ5dGVzKQ0KDQoJQi4gSUVFRSA4MDIuMyBhbmQgZGVy aXZhdGl2ZXMNCg0KCQkrLS0tLSstLS0tKy0tLS0tLSstLS0tLS0rLS0tLS0r DQoJCXwgREEgfCBTQSB8IExlbiAgfCBEYXRhIHwgRkNTIHwNCgkJKy0tLS0r LS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tKw0KDQoJCURBICAgICAgRGVzdGlu YXRpb24gTUFDIEFkZHJlc3MgKDYgYnl0ZXMpDQoJCVNBICAgICAgU291cmNl IE1BQyBBZGRyZXNzICAgICAgKDYgYnl0ZXMpDQoJCUxlbiAgICAgTGVuZ3Ro IG9mIERhdGEgZmllbGQgICAgKDIgYnl0ZXMpDQoJCURhdGEgICAgUHJvdG9j b2wgRGF0YSAgICAgICAgICAgKDQ2IC0gMTUwMCBieXRlcykNCgkJRkNTICAg ICBGcmFtZSBDaGVja3N1bSAgICAgICAgICAoNCBieXRlcykNCgkgIA0KCVRo ZSBkZXJpdmF0aXZlcyBpbmNsdWRlIExMQyAoODAyLjIpIGFuZCBTTkFQIHdo aWNoIHByZWZpeCB0aGUNCglkYXRhIGZpZWxkIHdpdGggYW4gTExDIGhlYWRl ci4gIEluIHRoZXNlIGluc3RhbmNlcyB0aGUgTGVuIGZpZWxkDQoJdGhlbiBj b3JyZXNwb25kcyB0byB0aGUgY29tYmluZWQgc2l6ZSBvZiBib3RoIHRoZSBk YXRhIHBvcnRpb24NCglvZiB0aGUgZnJhbWUgYW5kIHRoZSBMTEMgaGVhZGVy Lg0KCQ0KCU9uIHJlY2VwdGlvbiwgdGhlIHR3byBmb3JtYXRzIGFyZSBkaWZm ZXJlbnRpYXRlZCBiYXNlZCBvbiB0aGUNCgltYWduaXR1ZGUgb2YgdGhlIFR5 cGUvTGVuZ3RoIGZpZWxkLCBhcyBmb2xsb3dzOg0KDQoJPiAxNTAwIGJ5dGVz OiAgIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgdHlwZSBmaWVsZC4gIFRoZSBm cmFtZSBpcyBhbg0KCQkJRXRoZXJuZXQgSUkgZnJhbWUsIHdpdGggdHlwZSB2 YWx1ZXMgc3RhcnRpbmcNCgkJCWF0IDE1MzYgKDYwMCBoZXgpLg0KDQoJPD0g MTUwMCBieXRlczogIHZhbHVlIGNvcnJlc3BvbmRzIHRvIGEgbGVuZ3RoIGZp ZWxkLiAgVGhlIGZyYW1lIGlzDQoJCQlhbiBJRUVFIDgwMi4zIGZvcm1hdCAo b3IgZGVyaXZhdGl2ZSkgd2l0aCBhIG1heGltdW0NCgkJCWRhdGEgbGVuZ3Ro IG9mIDE1MDAgYnl0ZXMuDQoNCjUuIFByb2JsZW0gd2l0aCBMYXJnZSA4MDIu MyBGcmFtZXMgaW4gdGhlIHByZXNlbmNlIG9mIEV0aGVybmV0X0lJIEZyYW1l cw0KDQoJU29tZSBwcm90b2NvbHMgY29tbW9ubHkgdXNlZCBpbiB0aGUgSW50 ZXJuZXQsIHN1Y2ggYXMgRVNJUw0KCWFuZCBJU0lTIHdoaWNoIGFyZSBjYXJy aWVkIGFzIENMTlMgcGFja2V0cywgaGF2ZSBubyByZXNlcnZlZA0KICAgICAg ICBFdGhlcnR5cGUuICBTdWNoIHBhY2tldHMgY2FuIG9ubHkgdXNlIHRoZSBJ RUVFIDgwMi4zLzgwMi4yIGVuY29kaW5nLCANCiAgICAgICAgYW5kIHNvIGFy ZSBsaW1pdGVkIGluIGxlbmd0aCB0byAxNTAwIGJ5dGVzLg0KDQogCUV0aGVy bmV0X0lJIGZyYW1lcyBoYXZlIG5vIGxlbmd0aCBmaWVsZC4gUHJvdG9jb2xz IGVuY2Fwc3VsYXRlZCBpbiANCglFdGhlcm5ldCBJSSBmcmFtZXMsIHN1Y2gg YXMgSVAsIGFyZSBub3QgbGltaXRlZCBpbiBsZW5ndGggdG8gMTUwMCANCiAg ICAgICAgYnl0ZXMgYnkgZnJhbWluZy4NCg0KNi4gUHJvcG9zZWQgRXRoZXJu ZXQgRnJhbWUgRXh0ZW5zaW9uDQoNCglMYXJnZSA4MDIuMyBhbmQgRXRoZXJu ZXRfSUkgZnJhbWVzIGNhbiBiZSBzdXBwb3J0ZWQgYnkgdGhlIGZvbGxvd2lu ZzoNCgkNCgkrICBEZWZpbmUgYW4gRXRoZXJ0eXBlIGZvciA4MDIuMywgMHg4 ODcwLCBhbmQgZW5jb2RlIGxhcmdlIGZyYW1lcw0KCSAgICh3aGVyZSB0aGUg ZGF0YSBmaWVsZCBpcyBncmVhdGVyIHRoYW4gMTUwMCBieXRlcyksDQoJICAg ZXhjbHVzaXZlIG9mIHRoZSBEZXN0aW5hdGlvbiBNQUMgYWRkcmVzcywgU291 cmNlIE1BQyBhZGRyZXNzLA0KICAgICAgICAgICBhbmQgRGF0YSBsZW5ndGgg ZmllbGRzLCB3aXRoaW4gRXRoZXJuZXQgSUkuDQoNCgkgICBMYXJnZSA4MDIu My84MDIuMiBmcmFtZXMgd291bGQgaGF2ZSB0aGUgZm9sbG93aW5nIGZpZWxk czoNCiANCgkJKy0tLS0rLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0t LS0rLS0tLS0tKy0tLS0tKw0KCQl8IERBIHwgU0EgfCBUeXBlIHwgRFNBUCB8 IFNTQVAgfCBDdHJsIHwgRGF0YSB8IEZDUyB8DQoJCSstLS0tKy0tLS0rLS0t LS0tKy0tLS0tLSstLS0tLS0rLS0tLS0tKy0tLS0tLSstLS0tLSsNCgkJCQkg ID09PSA4MDIuMiBIZWFkZXIgPT09DQoNCgkJREEgICAgICBEZXN0aW5hdGlv biBNQUMgQWRkcmVzcyAgICAgICAgICAgICAgICAgKDYgYnl0ZXMpDQoJCVNB ICAgICAgU291cmNlIE1BQyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAg ICg2IGJ5dGVzKQ0KCQlUeXBlICAgIDB4ODg3MCAoRXRoZXJ0eXBlKSAgICAg ICAgICAgICAgICAgICAgICAoMiBieXRlcykNCgkJRFNBUCAgICA4MDIuMiBE ZXN0aW5hdGlvbiBTZXJ2aWNlIEFjY2VzcyBQb2ludCAgKDEgYnl0ZSkNCgkJ U1NBUCAgICA4MDIuMiBTb3VyY2UgU2VydmljZSBBY2Nlc3MgUG9pbnQgICAg ICAgKDEgYnl0ZSkNCgkJQ3RybCAgICA4MDIuMiBDb250cm9sIEZpZWxkICAg ICAgICAgICAgICAgICAgICAgKDEgYnl0ZSkNCgkJRGF0YSAgICBQcm90b2Nv bCBEYXRhICAgICAgICAgICAgICAgICAgICAgICAgICAgKCA+IDQ2IGJ5dGVz KQ0KCQlGQ1MgICAgIEZyYW1lIENoZWNrc3VtICAgICAgICAgICAgICAgICAg ICAgICAgICAoNCBieXRlcykNCgkgIA0KCSsgIEFsbG93IEV0aGVybmV0IElJ IGZyYW1lcyB0byBoYXZlIHBheWxvYWRzIGdyZWF0ZXIgdGhhbiAxNTAwIGJ5 dGVzLg0KDQoJVGhlcmUgaXMgbm8gbG9zcyBvZiBpbmZvcm1hdGlvbiBmcm9t IDgwMi4zLzgwMi4yIGZyYW1lcy4gQWx0aG91Z2ggDQogICAgICAgIHRoZSA4 MDIuMyBsZW5ndGggZmllbGQgaXMgbWlzc2luZywgdGhlIGZyYW1lIGxlbmd0 aCBpcyBrbm93biBieSANCiAgICAgICAgdmlydHVlIG9mIHRoZSBmcmFtZSBi ZWluZyBhY2NlcHRlZCBieSB0aGUgbmV0d29yayBpbnRlcmZhY2UuDQoNCglJ biB0aGlzIG1hbm5lciwgYWxsIEV0aGVybmV0IElJIGZyYW1lcywgaW5jbHVk aW5nIGxhcmdlIDgwMi4zIA0KIAlwYWNrZXRzLCBjYW4gYmUgbG9uZ2VyIHRo YW4gMTUwMCBieXRlcywgeWV0IGFyZSB1bmlxdWVseSBpZGVudGlmaWVkLg0K DQoNCjcuIFJlZmVyZW5jZXMNCg0KW0VUSF0gIlRoZSBFdGhlcm5ldCAtIEEg TG9jYWwgQXJlYSBOZXR3b3JrIiwgdmVyc2lvbiAxLjAsIERpZ2l0YWwNCkVx dWlwbWVudCBDb3Jwb3JhdGlvbiwgU2VwdGVtYmVyIDE5ODAsIGFuZCAiVGhl IEV0aGVybmV0LCBBIExvY2FsDQpBcmVhIE5ldHdvcmsiIERhdGEgTGluayBM YXllciBhbmQgUGh5c2ljYWwgTGF5ZXIgU3BlY2lmaWNhdGlvbnMiLA0KRGln aXRhbCwgSW50ZWwsIGFuZCBYZXJveCwgTm92ZW1iZXIsIDE5ODIuDQoNCltS RkM4OTRdIElFVEYgUkZDIDg5NA0KDQpbSUVFRTgwMi4zXSBJRUVFIFN0ZCA4 MDIuMw0KDQpbSUVFRTgwMl0gSUVFRSBTdGQgODAyDQoNCltJRUVFODAyLjNa XSBJRUVFIFN0ZCA4MDIuM3oNCg0KW0VYVC5GUkFNRV0gIlVzZSBvZiBFeHRl bmRlZCBGcmFtZSBTaXplcyBpbiBFdGhlcm5ldCBOZXR3b3JrcyIsIGRyYWZ0 DQoyLjEsIEFsdGVvbiBOZXR3b3JrcywgSW5jLg0KDQoNCjguIEF1dGhvcidz IEFkZHJlc3Nlcw0KDQpNaWtlIE8nRGVsbA0KVVVORVQgYW4gTUNJIFdvcmxk Q29tIENvbXBhbnkNCjMwNjAgV0lsbGFpbXMgRHJpdmUNCkZhaXJmYXgsIFZh LiAyMjAzMS00NjQ4DQo3MDMtMjA2LTU4OTANCmVtYWlsOiBtb0B1dS5uZXQN Cg0KSmVkIEthcGxhbg0KVVVORVQgYW4gTUNJIFdvcmxkQ29tIENvbXBhbnkN CjMwNjAgV0lsbGFpbXMgRHJpdmUNCkZhaXJmYXgsIFZhLiAyMjAzMS00NjQ4 DQo5MTQtNzAxLTUzMDkNCmVtYWlsOiBqa2FwbGFuQHV1Lm5ldA0KDQpKb2hu IEhheWVzDQpBbHRlb24gV2ViU3lzdGVtcywgSW5jLg0KNTAgR3JlYXQgT2Fr cyBCbHZkLg0KU2FuIEpvc2UsIENBIDk1MTE5DQo0MDgtMzYwLTU1MDcNCmVt YWlsOiBoYXllc0BhbHRlb24uY29tDQoNClRlZCBTY2hyb2VkZXINCkFsdGVv biBXZWJTeXN0ZW1zLCBJbmMuDQo1MCBHcmVhdCBPYWtzIEJsdmQuDQpTYW4g Sm9zZSwgQ0EgOTUxMTkNCjQwOC0zNjAtNTUwMA0KZW1haWw6IHRlZEBhbHRl b24uY29tDQoNClAuSi4gU2luZ2gNClBhY2tldCBFbmdpbmVzLCBJbmMuDQox MTcwNyBFYXN0IFNwcmFndWUgIzEwMQ0KU3Bva2FuZSBXQSAgOTkyMDYNCjUw OS03NzctNzAwMA0KZW1haWw6IHBqc2luZ2hAcGFja2V0ZW5naW5lcy5jb20N Cg0KRGFlbW9uIE1vcnJlbGwNCkp1bmlwZXIgTmV0d29ya3MsIEluYy4NCjEy MzQzLUQgU3VucmlzZSBWYWxsZXkgRHJpdmUNClJlc3RvbiwgVkEgMjAxOTEN CmVtYWlsOiBkbW9ycmVsbEBqdW5pcGVyLm5ldA0KDQpKZW5uaWZlciBIc3UN Cmpoc3VAbXVyLmNvbQ0K ---559023410-684387517-957964415=:12311-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:07:09 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12641 for ; Thu, 18 May 2000 16:07:08 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA60540; Thu, 18 May 2000 13:15:02 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id SAA53416 for ; Sun, 14 May 2000 18:25:08 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA25608 for ; Sun, 14 May 2000 18:11:37 -0700 (PDT) Received: from ssmtp02.melange.isp (smtp.arrakis.es [212.59.199.83]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id SAA32431 for ; Sun, 14 May 2000 18:36:10 -0700 (PDT) (envelope-from Internet-Drafts@ietf.org) Received: from ssmtp02.melange.isp ([127.0.0.1]) by ssmtp02.melange.isp (Netscape Messaging Server 4.15) with SMTP id FUKTUW03.03B for ; Mon, 15 May 2000 03:08:56 +0200 Received: from loki.ietf.org ([132.151.1.177]) by ssmtp04.melange.isp (Netscape Messaging Server 4.15) with ESMTP id FUE7O800.BK2 for ; Thu, 11 May 2000 12:24:08 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA00755 for ietf-123-outbound.07@ietf.org; Thu, 11 May 2000 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA00679 for ; Thu, 11 May 2000 06:57:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23479; Thu, 11 May 2000 06:57:18 -0400 (EDT) Message-Id: <200005111057.GAA23479@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net Reply-to: Internet-Drafts@ietf.org Date: Thu, 11 May 2000 06:57:18 -0400 Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-01.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --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 : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-01.txt Pages : 4 Date : 10-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-01.txt 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-kaplan-isis-ext-eth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000510111709.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 16:26:12 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12776 for ; Thu, 18 May 2000 16:26:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA61333; Thu, 18 May 2000 13:36:56 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA61134 for ; Thu, 18 May 2000 13:32:10 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA00129 for ; Thu, 18 May 2000 13:18:11 -0700 (PDT) Received: from mailgate.pit.comms.marconi.com (mailgate.fore.com [169.144.68.6]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id NAA26218 for ; Thu, 18 May 2000 13:43:18 -0700 (PDT) (envelope-from Daniel.Proch@marconi.com) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07415; Thu, 18 May 2000 16:17:18 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17046; Thu, 18 May 2000 16:17:16 -0400 (EDT) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 May 2000 16:11:13 -0400 Message-ID: From: "Proch, Daniel" To: "'Gabor Korossy (ETH)'" , mpls@UU.NET, "'isis-wg@juniper.net'" , "'te-wg@uu.net'" Subject: RE: [Isis-wg] RE: MPLS and IS-IS Date: Thu, 18 May 2000 16:17:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id NAA61135 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 8bit Gabor, http://202.38.127.18/res/www.ietf.org/internet-drafts/draft-ietf-isis-traffi c-01.txt If that link is broke, I will send it to you. ======================== Daniel Proch Marconi Communications ======================== -----Original Message----- From: Gabor Korossy (ETH) [mailto:ethkkg@etxb.ericsson.se] Sent: Thursday, May 18, 2000 4:20 AM To: mpls@UU.NET; 'isis-wg@juniper.net'; 'te-wg@uu.net' Subject: [Isis-wg] RE: MPLS and IS-IS Hi, if I may repeat, could anyone help me please, find the draft "IS-IS extensions for Traffic Engineering," draft-ietf-isis-traffic-01.txt If so many ISPs run IS-IS with MPLS TE extensions shouldn't it become an IETF standard? Maybe one of the MPLS, TE and IS-IS working groups doesn´t feel ashamed to adopt this child? regards - Gabor >> -----Original Message----- >> From: Chris.Flores@broadwing.com [mailto:Chris.Flores@broadwing.com] >> Sent: Wednesday, May 17, 2000 8:48 PM >> To: mpls@UU.NET >> Subject: FW: MPLS and IS-IS >> >> >> >> David - >> >> Most large ISPs in the US use ISIS: >> >> UUnet, C&W, Sprintlink, Qwest, Verio, Digex, Frontier, Broadwing. >> >> It also seems like more and more european ISPs are starting >> to use ISIS: >> EUnet, Ebone, Hermes, TeleDanMark, Renater (FT), Telia, Tele2, etc. >> >> Chris >> >> -----Original Message----- >> From: David Wang [mailto:david.wang@metro-optix.com] >> Sent: Wednesday, May 17, 2000 12:36 PM >> To: 'HANSEN CHAN'; mpls@UU.NET >> Subject: RE: MPLS and IS-IS >> >> >> Hi all, >> >> IS-IS is defined to work with CLNP not for IP originally. >> Until today a lot >> of SONET and telecommunication equipment vendors still use >> IS-IS to route >> CLNP packets through the SONET Data communication >> channel(DCC) to carry >> management information and there is a great pressure to >> change this to OSPF >> and IP. I also know that UUNET runs IS-IS on their network. >> I never heard >> any other networks run IS-IS. Seems I am wrong. My questions are. >> >> 1. You guys are talking about using IS-IS in a IP networks >> not in CLNP >> networks. The IS-IS has been modified according to RFC 1195 >> (Use of OSI >> IS-IS for Routing in TCP/IP and Dual Environments) or some >> other standard. >> Is this correct? >> >> 2. Besides UUNET, which ISPs run IS-IS protocol? Can you >> name a few? or >> what percentage of networks run IS-IS instead of OSPF? >> >> Thanks >> David >> >> >> -----Original Message----- >> From: HANSEN CHAN [mailto:hchan@newbridge.com] >> Sent: Tuesday, May 16, 2000 7:22 AM >> To: mpls@UU.NET >> Subject: MPLS and IS-IS >> >> >> Hi all, >> >> I have been hearing IS-IS is a better protocol to be used >> than OSPF in a >> MPLS >> network for TE application. Is that a fair statement? What >> are the technical >> reasons? >> >> Appreciate if someone can shed some light on this subject. >> >> Thanks, >> Hansen >> >> _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 17:22:22 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13273 for ; Thu, 18 May 2000 17:22:20 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA61461; Thu, 18 May 2000 14:33:33 -0700 (PDT) Received: from aurms0.aur.alcatel.com (aurms0.aur.alcatel.com [143.209.4.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA61432 for ; Thu, 18 May 2000 14:33:31 -0700 (PDT) Received: from aurmsb.aur.alcatel.com (aurmsb [143.209.4.165]) by aurms0.aur.alcatel.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA04163; Thu, 18 May 2000 17:19:31 -0400 (EDT) Received: from aurmsb.aur.alcatel.com (localhost [127.0.0.1]) by aurmsb.aur.alcatel.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e4ILJOn22234; Thu, 18 May 2000 17:19:24 -0400 (EDT) Received: from usa.alcatel.com (aursb7 [143.209.6.134]) by aurmsb.aur.alcatel.com (Switch-2.0.1/VSwitch-2.0.1) with ESMTP id e4ILJN722230; Thu, 18 May 2000 17:19:23 -0400 (EDT) Message-ID: <39245E5A.8B4AE661@usa.alcatel.com> Date: Thu, 18 May 2000 17:19:22 -0400 From: Thomas M Holland Reply-To: Thomas.M.Holland@usa.alcatel.com Organization: Alcatel Network Systems, Inc Raleigh, NC X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@external.juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] IS-IS mixed domains Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit I have a question about mixing Dual and OSI-only routers in an OSI-only area. Here is the configuration: Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 | | Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 (note: there are supposed to be vertical connections from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in case my artwork gets mangled) Each of these NEs support Integrated ISIS and are all in the same area. By definition, this must be an OSI-only area since two of the NEs are OSI-only. Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP reachability entries list. Dual-1 should now have 2 paths to IP3, one through OSI-1 and one through Dual-3. The one through OSI-1 looks like the shorter path, but won't work, because it includes OSI only routers. The standard states that you cannot route IP packets in an OSI-only area. But it doesn't indicate any checks that you must do to prevent doing this. Are you required to check the 'protocol supported' field in each LSP and keep track of what type of area you are in? It seems if the node was required to look at the 'protocol supported' field of each link to determine if the area was OSI-only, that would fix the problem. Either the node would drop the packet itself with an appropriate ICMP error, or perhaps the SPF algorithm would take into account which nodes support IP and which do not. However, the way the standard reads to me (especially sec 1.4 and 3.10), it implies that you just send it out and the packet will get dropped. Is my reading correct? It seems that if you have even one OSI only router in an area, there's not much use in having Dual routers in that area, since IP packets can't be routed. Is there any kind of mechanism for easing the transition from OSI to IP (or vice-versa)? Do you know if anyone is using RFC1195 to route both CLNP and IP? Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms for forwarding packets through incompatible routers (which might help ease the transition); do you know of any work along these lines? Thanks, Tom Holland Alcatel _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 18 17:56:49 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13537 for ; Thu, 18 May 2000 17:56:48 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA61724; Thu, 18 May 2000 15:07:10 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA61697 for ; Thu, 18 May 2000 15:07:08 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id OAA06432; Thu, 18 May 2000 14:53:05 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id AAA00883; Fri, 19 May 2000 00:02:40 +0200 Message-Id: <200005182202.AAA00883@kraak.procket.com> Subject: Re: [Isis-wg] IS-IS mixed domains To: Thomas.M.Holland@usa.alcatel.com Date: Fri, 19 May 2000 00:02:40 +0200 (MEST) Cc: isis-wg@external.juniper.net In-Reply-To: <39245E5A.8B4AE661@usa.alcatel.com> from "Thomas M Holland" at May 18, 2000 05:19:22 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > > I have a question about mixing Dual and OSI-only routers in an OSI-only area. > > Here is the configuration: > > Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 > | | > Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 > > (note: there are supposed to be vertical connections > from Dual-1 to Dual-3 and from Dual-2 to Dual-6, in > case my artwork gets mangled) The picture is crisp clear. > Each of these NEs support Integrated ISIS and are all in the same area. > By definition, this must be an OSI-only area since two of the NEs are > OSI-only. Don't know where you found that definition. This is what rfc1195 has to say. See paragraph 1.4: Support of Mixed Routing Domains. In a dual routing domain, IP-only, OSI-only, and dual routers may be mixed on a per-area basis. Specifically, each area may itself be defined to be pure IP, pure OSI, or dual. In a dual area within a dual routing domain only dual routers may be used. Both IP and OSI traffic can be routed within a dual area. When I read this, I understand that it states that you may not mix Dual routers and OSI-only routers *inside* one area. In the design you presented in your example, you do mix them. That is forbidden. Your network design will not work. > Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. > Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP > reachability entries list. Dual-1 should now have 2 paths to IP3, > one through OSI-1 and one through Dual-3. The one through OSI-1 > looks like the shorter path, but won't work, because it includes OSI > only routers. Correct. > The standard states that you cannot route IP packets in an OSI-only > area. But it doesn't indicate any checks that you must do to > prevent doing this. Are you required to check the 'protocol > supported' field in each LSP and keep track of what type of area you > are in? I would assume it is the responsability of the network adminstrator who install and configures the routers. Note: the protocol supported TLV is inside hello packets. So routers could check that to accept or reject adjacencies with other routers that are differently configured. Note also that this would make migration between modes more difficult. > It seems if the node was required to look at the 'protocol > supported' field of each link Which field ? The description of a link inside an LSP only tells you between which routers the link is, and what the cost is. It does not tell you which protocols are supported over that link. This is TLV #2. If you use the newer TLV #22, then you might want to add a new sub-TLV to describe the protocols supported. Then each router can run an SPF per protocol. IMHO this is not worth the trouble. > to determine if the area was OSI-only, > that would fix the problem. Either the node would drop the packet > itself with an appropriate ICMP error, or perhaps the SPF algorithm > would take into account which nodes support IP and which do > not. You'll need a separate SPF for IP and one for OSI. > However, the way the standard reads to me (especially sec 1.4 > and 3.10), it implies that you just send it out and the packet will > get dropped. Is my reading correct? My reading is that your setup is illegal. Behaviour of routers in illegal configurations in not (always) defined. > It seems that if you have even one OSI only router in an area, there's not > much use in having Dual routers in that area, since IP packets can't > be routed. Correct. That is probably why the requirement is there to make all routers inside an area in the same mode. > Is there any kind of mechanism for easing the transition > from OSI to IP (or vice-versa)? I am not sure what you mean by that question. > Do you know if anyone is using RFC1195 to route both CLNP and IP? Of course. > Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms > for forwarding packets through incompatible routers (which might help ease > the transition); do you know of any work along these lines? Nothing that I know of. Tunnels are a pain. Hope this helps, Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri May 19 16:08:39 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10418 for ; Fri, 19 May 2000 16:08:38 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63682; Fri, 19 May 2000 13:18:01 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA63653 for ; Fri, 19 May 2000 13:17:59 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4JK3oZ03368 for ; Fri, 19 May 2000 16:03:50 -0400 (EDT) Message-Id: <3.0.1.32.20000519153209.013056c0@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 May 2000 15:32:09 -0400 To: isis-wg@external.juniper.net From: Jeff Learman Subject: Re: [Isis-wg] IS-IS mixed domains Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net >> I have a question about mixing Dual and OSI-only routers in an OSI-only area. You can mix OSI-only and dual routers in an area, but only OSI routing will be supported in the area. While the dual routers support IP routing capability, you won't get meaningful IP routing in the area. RFC1195 says: In a pure-OSI area within a dual domain, OSI-only and dual routers may be freely mixed. Only OSI traffic can be routed by level 1 routing within a pure OSI area. The protocol does not enforce the requirement. But if you try to break the rules, it just won't work. IP-capable routers may attempt to forward IP packets to OSI-only routers, which will drop them (if it's robust, but NE implementations aren't always as robust as one might wish ;-). As Henk says, the protocol doesn't distinguish between CLNP links and IP links. It just describes links, and a link is assumed to be capable of any protocol supported by the router that's running SPF. The strange upshot of this is that there are some mixed networks (some dual, some CLNP-only) where IP actually works, but only because all best paths between dual routers are via dual routers. I would strongly recommend against building a network like this on purpose, except in very special cases. Note that the fault tolerance assesment is much more complicated. For example, in your picture: >> >> Here is the configuration: >> >> Dual-1 --- OSI-1 --- OSI-2 --- Dual-2 >> | | >> Dual-3 --- Dual-4 --- Dual-5 --- Dual-6 >> If Dual-1 is trying to send IP traffic to Dual 2, it will forward it via OSI-1, which will just drop it. Assuming all link costs are equal, Dual-3 will be able to exchange IP traffic with Dual-6, but only if none of the links between them are down. >> Each of these NEs support Integrated ISIS and are all in the same area. >> By definition, this must be an OSI-only area since two of the NEs are >> OSI-only. Correct. >> Assume Dual-1 wants to send an IP packet to IP3 which is attached to Dual-2. >> Dual-1 has received an L1-LSP from Dual-2 with IP3 in its IP >> reachability entries list. Dual-1 should now have 2 paths to IP3, >> one through OSI-1 and one through Dual-3. The one through OSI-1 >> looks like the shorter path, but won't work, because it includes OSI >> only routers. > > Correct. > >> The standard states that you cannot route IP packets in an OSI-only >> area. But it doesn't indicate any checks that you must do to >> prevent doing this. Are you required to check the 'protocol >> supported' field in each LSP and keep track of what type of area you >> are in? > > I would assume it is the responsability of the network adminstrator > who install and configures the routers. > Note: the protocol supported TLV is inside hello packets. So routers could > check that to accept or reject adjacencies with other routers that > are differently configured. Note also that this would make migration > between modes more difficult. > >> It seems if the node was required to look at the 'protocol >> supported' field of each link to determine if the area was OSI-only, >> that would fix the problem. Either the node would drop the packet >> itself with an appropriate ICMP error, or perhaps the SPF algorithm >> would take into account which nodes support IP and which do >> not. As Henk says, there is no information for each link. There is, however, a Protocols Supported TLV in each LSP, identifying the protocols supported by the router, according to RFC 1195: The "Protocols Supported" field identifies the protocols which are supported by each router. This field must be included in all IS-IS Hello packets and all LSPs with LSP number 0 transmitted by IP- capable routers. But this information is not consulted when running SPF (or at any other time, so some implementations might even omit them from LSPs, and there would be no side effects except when trying to debug routing problems by looking in a router's LSDB). >> However, the way the standard reads to me (especially sec 1.4 >> and 3.10), it implies that you just send it out and the packet will >> get dropped. Is my reading correct? > > My reading is that your setup is illegal. Behaviour of routers in > illegal configurations in not (always) defined. I disagree that the setup is illegal (using dual routers in an OSI-only area). I do agree that trying to route IP traffic in this area is illegal. This is only a semantic nit I am picking ;-) and I agree with Henk's assessment that the behavior is a "don't care case" in the spec. >> It seems that if you have even one OSI only router in an area, there's not >> much use in having Dual routers in that area, since IP packets can't >> be routed. The only reason would be for transition purposes. >> Is there any kind of mechanism for easing the transition >> from OSI to IP (or vice-versa)? Introduce dual routers, but use only CLNP, until all routers are dual- capable. Then it is a dual area, and you can start using IP. >> Also, sec 3.8 of the RFC refers to future optional encapsulation mechanisms >> for forwarding packets through incompatible routers (which might help ease >> the transition); do you know of any work along these lines? Unfortunately, RFC 1195 makes this difficult if not impossible to do, because of ignoring the Protocols Supported TLV when running SPF. This makes tunneling impossible without creating some new special kind of link that would need to be understood by all dual routers in the area as being an IP-only link. This need to upgrade all dual routers in the area makes such an enhancement impractical. Regards, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat May 20 16:55:58 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01240 for ; Sat, 20 May 2000 16:55:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA66902; Sat, 20 May 2000 14:05:08 -0700 (PDT) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA66870 for ; Sat, 20 May 2000 14:05:05 -0700 (PDT) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id WAA08021 for isis-wg@external.juniper.net; Sat, 20 May 2000 22:47:39 +0200 From: Tony Przygienda Message-Id: <200005202047.WAA08021@net4u.net4u.ch> To: isis-wg@external.juniper.net Date: Sat, 20 May 2000 22:47:39 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Last call for draft-kaplan-isis-ext-eth-01.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Last call for draft-kaplan-isis-ext-eth-01.txt to go informational. Last call ends June 5th thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 24 09:01:19 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05085 for ; Wed, 24 May 2000 09:01:18 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA01155; Wed, 24 May 2000 06:05:55 -0700 (PDT) Received: from aurms0.aur.alcatel.com (aurms0.aur.alcatel.com [143.209.4.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA01123 for ; Wed, 24 May 2000 06:05:47 -0700 (PDT) Received: from aurmsb.aur.alcatel.com (aurmsb [143.209.4.165]) by aurms0.aur.alcatel.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA20408; Wed, 24 May 2000 08:56:22 -0400 (EDT) Received: from aurmsb.aur.alcatel.com (localhost [127.0.0.1]) by aurmsb.aur.alcatel.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e4OCuAd10837; Wed, 24 May 2000 08:56:11 -0400 (EDT) Received: from usa.alcatel.com (aursb7 [143.209.6.134]) by aurmsb.aur.alcatel.com (Switch-2.0.1/VSwitch-2.0.1) with ESMTP id e4OCuAq10827; Wed, 24 May 2000 08:56:10 -0400 (EDT) Message-ID: <392BD167.F01D1888@usa.alcatel.com> Date: Wed, 24 May 2000 08:56:07 -0400 From: Thomas M Holland Reply-To: Thomas.M.Holland@usa.alcatel.com Organization: Alcatel Network Systems, Inc Raleigh, NC X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@external.juniper.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Isis-wg] IDRPI field Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Does anyone know if the Inter-Domain Routing Protocol Information field (TLV 131) is used very much out in the field? Are there other values for the Inter-Domain Information Type than (0, 1, and 2) in use? I did not see any reference to them in IANA. For Type 1 (i.e., local) are there standard or common formats in use? Thanks, Tom Holland Alcatel _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 24 09:48:00 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05978 for ; Wed, 24 May 2000 09:47:59 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA01259; Wed, 24 May 2000 06:53:17 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA01231 for ; Wed, 24 May 2000 06:53:15 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id GAA04921; Wed, 24 May 2000 06:43:47 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id PAA00799; Wed, 24 May 2000 15:53:47 +0200 Message-Id: <200005241353.PAA00799@kraak.procket.com> Subject: Re: [Isis-wg] IDRPI field To: Thomas.M.Holland@usa.alcatel.com Date: Wed, 24 May 2000 15:53:46 +0200 (MEST) Cc: isis-wg@external.juniper.net In-Reply-To: <392BD167.F01D1888@usa.alcatel.com> from "Thomas M Holland" at May 24, 2000 08:56:07 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit I have never seen it in any LSPs. I don't know of any vendor that has implemented this. In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) Henk. > Does anyone know if the Inter-Domain Routing > Protocol Information field (TLV 131) is used > very much out in the field? > > Are there other values for the Inter-Domain > Information Type than (0, 1, and 2) in use? > I did not see any reference to them in IANA. > > For Type 1 (i.e., local) are there standard > or common formats in use? > > Thanks, > > Tom Holland > Alcatel > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 24 14:36:23 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10779 for ; Wed, 24 May 2000 14:36:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA01552; Wed, 24 May 2000 11:42:23 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA00984 for ; Wed, 24 May 2000 03:44:40 -0700 (PDT) Received: from rojo.juniper.net (rojo.juniper.net [208.223.209.3]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id DAA21781 for ; Wed, 24 May 2000 03:35:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by rojo.juniper.net (8.9.3/8.9.3) with ESMTP id DAA16660 for ; Wed, 24 May 2000 03:55:59 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01877; Wed, 24 May 2000 06:35:13 -0400 (EDT) Message-Id: <200005241035.GAA01877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 24 May 2000 06:35:13 -0400 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-3way-02.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --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 : Three-Way Handshake for IS-IS Point-to-Point Adjacencies Author(s) : D. Katz, R. Saluja Filename : draft-ietf-isis-3way-02.txt Pages : 7 Date : 23-May-00 The IS-IS routing protocol (ISO 10589) does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-3way-02.txt 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-3way-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-3way-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000523121610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-3way-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-3way-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000523121610.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 24 16:13:36 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12091 for ; Wed, 24 May 2000 16:13:34 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA01773; Wed, 24 May 2000 13:19:04 -0700 (PDT) Received: from MailGate.Adtech-Inc.COM (smtp.adtech-inc.com [192.216.50.164]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA01741 for ; Wed, 24 May 2000 13:19:02 -0700 (PDT) Received: from mgmgrand.adtech-inc.com (Trans_Exchange.Adtech-Inc.COM [192.216.50.163]) by MailGate.Adtech-Inc.COM (8.10.0/8.10.0) with ESMTP id e4OKBS214818 for ; Wed, 24 May 2000 10:11:28 -1000 (HST) Received: by mgmgrand.adtech-inc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 May 2000 10:09:34 -1000 Message-ID: From: "Nava.Zvaig" To: isis-wg@external.juniper.net Date: Wed, 24 May 2000 10:09:33 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFC5BB.FA81D192" Subject: [Isis-wg] Packet encapsulations Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFC5BB.FA81D192 Content-Type: text/plain; charset="iso-8859-1" I'm looking for the latest encapsulations of IS-IS packets. It seemed that the format detailed in RFC 1195 and RFC 1142 has changed. For example, by searching the web, I found out that the common header doesn't include the ECO and USER ECO fields and has the Maximum Area Addresses field. Is there another source that describes the encapsulations of the Hello, LSP, and SNPs (for IS-IS over IP)? TIA, Nava ------_=_NextPart_001_01BFC5BB.FA81D192 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Packet encapsulations

I'm looking for the latest encapsulations of IS-IS = packets.  It seemed that the format detailed in RFC 1195 and RFC = 1142 has changed.  For example, by searching the web, I found out = that the common header doesn't include the ECO and USER ECO fields and = has the Maximum Area Addresses field.  Is there another source = that describes the encapsulations of the Hello, LSP, and SNPs (for = IS-IS over IP)?

TIA,
Nava

------_=_NextPart_001_01BFC5BB.FA81D192-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 24 16:32:31 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12620 for ; Wed, 24 May 2000 16:32:29 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA01902; Wed, 24 May 2000 13:38:26 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA01832 for ; Wed, 24 May 2000 13:38:22 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4OKSrZ21014; Wed, 24 May 2000 16:28:54 -0400 (EDT) Message-Id: <3.0.1.32.20000524162554.012f9520@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 24 May 2000 16:25:54 -0400 To: isis-wg@external.juniper.net From: Jeff Learman Subject: [Isis-wg] draft-ietf-isis-3way-02.txt questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net The procedures in draft-ietf-isis-3way-02 look great. I have a suggestion: It should be stated that this mechanism is unnecessary when using a reliable link layer service, and that implementing this mechanism relaxes certain requirements stated in ISO 10589 for the operation of IS-IS over point-to-point links. These requirements are: "a) Provision that both source and destination systems complete startup before PDU exchange can occur; b) Detection of remote start-up; c) Provision that no old PDUs be received after start-up is complete; d) Provision that no PDUs transmitted after a particular startup is complete are delivered out of sequence; e) Provision that failure to deliver a specific subnetwork SDU will result in the timely disconnexion of the subnetwork connection in both directions and that this failure will be reported to both systems; and f) Reporting of other subnetwork failures and degrade subnetwork conditions. g) The following events are "very low probability", ..." Clearly, the draft relieves the subnetwork of requirements a, b, e, and f. I don't know whether the mechanism has any impact on requirements c and d. Regards, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 24 18:38:57 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13750 for ; Wed, 24 May 2000 18:38:56 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA02078; Wed, 24 May 2000 15:44:58 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA02046 for ; Wed, 24 May 2000 15:44:56 -0700 (PDT) Received: from emailid-pc.cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA12879; Wed, 24 May 2000 15:35:21 -0700 (PDT) Message-Id: <4.2.0.58.20000524173333.01bc5c40@127.0.0.1> X-Sender: mbartell@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 24 May 2000 17:37:59 -0500 To: "Nava.Zvaig" , isis-wg@external.juniper.net From: Micah Bartell Subject: Re: [Isis-wg] Packet encapsulations In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net With regards to the encapsulations of IS-IS packets, they are encapsulated within the Data Link. They do not run over CLNS or over IP. Does this answer you question? I would also not recommend the use of RFC 1142 as it is not the final draft of ISO 10589. I would instead recommend the obtaining an actual copy of ISO 10589 with the related updates which are packaged together by ANSI. Yes, work is in progress to produce a new edition of ISO 10589 which contains the defect reports integrated into the standard. /mpb At 10:09 AM 5/24/2000 -1000, Nava.Zvaig wrote: >I'm looking for the latest encapsulations of IS-IS packets. It seemed that the format detailed in RFC 1195 and RFC 1142 has changed. For example, by searching the web, I found out that the common header doesn't include the ECO and USER ECO fields and has the Maximum Area Addresses field. Is there another source that describes the encapsulations of the Hello, LSP, and SNPs (for IS-IS over IP)? > >TIA, >Nava -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 25 10:43:55 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10190 for ; Thu, 25 May 2000 10:43:54 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA03146; Thu, 25 May 2000 06:47:55 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA03116 for ; Thu, 25 May 2000 06:47:53 -0700 (PDT) Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Thu, 25 May 2000 08:36:56 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS8678HV; Thu, 25 May 2000 06:36:26 -0700 Received: from nortelnetworks.com (lead.engeast.baynetworks.com [192.32.148.52]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS52HB6N; Thu, 25 May 2000 09:36:27 -0400 Message-ID: <392D2C5B.1246FA2F@nortelnetworks.com> Date: Thu, 25 May 2000 09:36:27 -0400 From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Learman CC: isis-wg@external.juniper.net Subject: Re: [Isis-wg] draft-ietf-isis-3way-02.txt questions References: <3.0.1.32.20000524162554.012f9520@mail.one.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Jeff, It is a valid point. Thanks for your suggestion. Regards, Rajesh Jeff Learman wrote: > The procedures in draft-ietf-isis-3way-02 look great. I have a suggestion: > > It should be stated that this mechanism is unnecessary when using a > reliable link layer service, and that implementing this mechanism relaxes > certain requirements stated in ISO 10589 for the operation of IS-IS over > point-to-point links. These requirements are: > > "a) Provision that both source and destination systems complete startup > before PDU exchange can occur; > b) Detection of remote start-up; > c) Provision that no old PDUs be received after start-up is complete; > d) Provision that no PDUs transmitted after a particular startup is > complete are delivered out of sequence; > e) Provision that failure to deliver a specific subnetwork SDU will > result in the timely disconnexion of the subnetwork connection in > both directions and that this failure will be reported to both systems; > and > f) Reporting of other subnetwork failures and degrade subnetwork conditions. > g) The following events are "very low probability", ..." > > Clearly, the draft relieves the subnetwork of requirements a, b, e, and f. > I don't know whether the mechanism has any impact on requirements c and d. > > Regards, > Jeff > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Thu May 25 17:17:00 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20849 for ; Thu, 25 May 2000 17:16:58 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA03601; Thu, 25 May 2000 14:21:04 -0700 (PDT) Received: from hermes.balink.com (baisgate.bellatlantic.net [199.45.32.51]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA03575 for ; Thu, 25 May 2000 14:21:01 -0700 (PDT) Received: by HERMES with Internet Mail Service (5.5.2448.0) id ; Thu, 25 May 2000 17:10:32 -0400 Message-ID: <4F8C08CC6E76D311AD1F00508B787249F8EE8A@HERMES> From: "Martin, Christian" To: "'Henk Smit'" , Thomas.M.Holland@usa.alcatel.com Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] IDRPI field Date: Thu, 25 May 2000 17:10:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Henk, I posed a question regarding this a while back. As you know, RFC1195 indicates that the IDRPI field could be used for adminstrative tagging, a la OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for a type 2. From an operational perspective, this would be useful additional information that could aid in things like redistribution filtering. Given all the TE work being done to extend the protocol, it should be a relatively painless addition to the next rev. Regards, Chris -----Original Message----- From: Henk Smit [mailto:henk@Procket.com] Sent: Wednesday, May 24, 2000 9:54 AM To: Thomas.M.Holland@usa.alcatel.com Cc: isis-wg@external.juniper.net Subject: Re: [Isis-wg] IDRPI field I have never seen it in any LSPs. I don't know of any vendor that has implemented this. In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) Henk. > Does anyone know if the Inter-Domain Routing > Protocol Information field (TLV 131) is used > very much out in the field? > > Are there other values for the Inter-Domain > Information Type than (0, 1, and 2) in use? > I did not see any reference to them in IANA. > > For Type 1 (i.e., local) are there standard > or common formats in use? > > Thanks, > > Tom Holland > Alcatel > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri May 26 01:08:25 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28961 for ; Fri, 26 May 2000 01:08:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA04012; Thu, 25 May 2000 22:13:45 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA03985 for ; Thu, 25 May 2000 22:13:38 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 26 May 2000 10:44:23 +0530 Received: from vanik ([172.16.1.28]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA19009 for ; Fri, 26 May 2000 10:20:43 +0530 Received: by localhost with Microsoft MAPI; Fri, 26 May 2000 10:33:09 +0530 Message-Id: <01BFC6FD.C90A8A80.vanik@future.futsoft.com> From: Vani Sree K Reply-To: "vanik@future.futsoft.com" To: "'isis-wg@external.juniper.net'" Date: Fri, 26 May 2000 10:27:07 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Subject: [Isis-wg] Doubt on IS-IS Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Hi, In the Intermediate system Neighbors option of LAN Hello, the code value carries the 6 Octet Mac Address. (10589, 1992) My doubt is whether it is the Mac Address of the interface from which the Hello is sent or System Id of the Intermediate system. (Assuming one of the Mac address is system Id). (In one of the Cisco document of IS-IS, it has been stated that the "SystemID is usually the MAC identifier of an interface on the device. The IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has been heard within the last Hold time..") While creating new adjacencies, the NeigbourSNPA Address is set to the MAC source address of the PDU. It means, the source MAC address is got from the Ethernet header.? Please correct me. Thanks -vani _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri May 26 09:27:02 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14806 for ; Fri, 26 May 2000 09:27:00 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA04648; Fri, 26 May 2000 06:26:34 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA04619 for ; Fri, 26 May 2000 06:26:32 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Fri, 26 May 2000 08:16:33 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L40WYRSB; Fri, 26 May 2000 09:16:32 -0400 Received: from nortelnetworks.com (lead.engeast.baynetworks.com [192.32.148.52]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS52HDLR; Fri, 26 May 2000 09:16:31 -0400 Message-ID: <392E792E.5304F3F1@nortelnetworks.com> Date: Fri, 26 May 2000 09:16:30 -0400 From: "Rajesh Saluja" X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "vanik@future.futsoft.com" CC: "'isis-wg@external.juniper.net'" Subject: Re: [Isis-wg] Doubt on IS-IS References: <01BFC6FD.C90A8A80.vanik@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit LAN Hello carries the system ID. -Rajesh Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri May 26 11:41:12 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18478 for ; Fri, 26 May 2000 11:41:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA04873; Fri, 26 May 2000 08:47:36 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA04844 for ; Fri, 26 May 2000 08:47:33 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4QFbkZ12776; Fri, 26 May 2000 11:37:46 -0400 (EDT) Message-Id: <3.0.1.32.20000526113744.012ac780@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 26 May 2000 11:37:44 -0400 To: Vani Sree K From: Jeff Learman Subject: Re: [Isis-wg] Doubt on IS-IS Cc: In-Reply-To: <01BFC6FD.C90A8A80.vanik@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Fri May 26 12:15:02 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19212 for ; Fri, 26 May 2000 12:15:01 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA05016; Fri, 26 May 2000 09:21:18 -0700 (PDT) Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39]) by external.juniper.net (8.9.3/8.9.3) with SMTP id JAA04989 for ; Fri, 26 May 2000 09:21:16 -0700 (PDT) Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id ; Fri, 26 May 2000 18:11:33 +0200 Message-ID: <98388C05D464D111B61800805F1504160148B478@p-ibis.issy.cnet.fr> From: DAUVERGNE Emmanuel FTRD/DAC/ISS To: Vani Sree K Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] Doubt on IS-IS Date: Fri, 26 May 2000 18:11:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by external.juniper.net id JAA04990 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 8bit ...and this MAC address (SNPA) is used in the DIS election : (if no priority imposed) choose the highest one. Regards, Manu -----Message d'origine----- De: Jeff Learman [mailto:jjl@one.com] Date: vendredi 26 mai 2000 17:38 Ŕ: Vani Sree K Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat May 27 01:32:12 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05966 for ; Sat, 27 May 2000 01:32:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA06414; Fri, 26 May 2000 22:37:40 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id WAA06384 for ; Fri, 26 May 2000 22:37:35 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Sat, 27 May 2000 11:08:59 +0530 Received: from saver.future ([172.16.1.27]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA07739 for ; Sat, 27 May 2000 10:44:26 +0530 Received: by localhost with Microsoft MAPI; Sat, 27 May 2000 10:52:55 +0530 Message-Id: <01BFC7C9.B66E5060.selvarajr@future.futsoft.com> From: SelvarajR Reply-To: "selvarajr@future.futsoft.com" To: "'DAUVERGNE Emmanuel FTRD/DAC/ISS'" Cc: "'ISIS-WG'" Subject: RE: [Isis-wg] Doubt on IS-IS Date: Sat, 27 May 2000 10:52:52 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BFC7C9.B68FE220" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net ------ =_NextPart_000_01BFC7C9.B68FE220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Except resolving tie does the SNPA is useful for any other purpose that can't be done using System ID. Also for breaking Tie, if there are two string(or value) that can be compared then that's enough. But those string(or value) necessarily not be the SNPA. In case of Integrated ISIS while the protocol runs over IP , I feel it is little bit inefficient to get the MAC address from the Ethernet header. Pls clarify if wrong. SELVA -----Original Message----- From: DAUVERGNE Emmanuel FTRD/DAC/ISS [SMTP:emmanuel.dauvergne@rd.francetelecom.fr] Sent: Friday, May 26, 2000 9:42 PM To: Vani Sree K Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] Doubt on IS-IS ...and this MAC address (SNPA) is used in the DIS election : (if no priority imposed) choose the highest one. Regards, Manu -----Message d'origine----- De: Jeff Learman [mailto:jjl@one.com] Date: vendredi 26 mai 2000 17:38 A: Vani Sree K Cc: isis-wg@external.juniper.net Objet: Re: [Isis-wg] Doubt on IS-IS Vani, While it is true that a LAN IIH carries a system ID, the Intermediate System Neighbors option in a LAN IIH carries the MAC address of the neighbor, not the system ID. The MAC address of the neighbor is obtained from the Ethernet header of the IIH received from the neighbor. See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, on page 50. Regards, Jeff Vani Sree K wrote: > Hi, > > In the Intermediate system Neighbors option of LAN Hello, the code value > carries the 6 Octet Mac Address. (10589, 1992) > My doubt is whether it is the Mac Address of the interface from which the > Hello is sent or System Id of the Intermediate system. (Assuming one of the > Mac address is system Id). > (In one of the Cisco document of IS-IS, it has been stated that the > "SystemID is usually the MAC identifier of an interface on the device. The > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > been heard within the last Hold time..") > > While creating new adjacencies, the NeigbourSNPA Address is set to the MAC > source address of the PDU. > It means, the source MAC address is got from the Ethernet header.? > > Please correct me. > > Thanks > -vani > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg ------ =_NextPart_000_01BFC7C9.B68FE220 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjcFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAwAMAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAZAAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAERBVVZFUkdORSBFbW1h bnVlbCBGVFJEL0RBQy9JU1MAU01UUABlbW1hbnVlbC5kYXV2ZXJnbmVAcmQuZnJhbmNldGVsZWNv bS5mcgAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAJwAAAGVtbWFudWVsLmRhdXZlcmduZUBy ZC5mcmFuY2V0ZWxlY29tLmZyAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAiAAAAJ0RBVVZFUkdO RSBFbW1hbnVlbCBGVFJEL0RBQy9JU1MnAAAAAgELMAEAAAAsAAAAU01UUDpFTU1BTlVFTC5EQVVW RVJHTkVAUkQuRlJBTkNFVEVMRUNPTS5GUgADAAA5AAAAAAsAQDoAAAAAAwBxOgAAAAAeAPZfAQAA ACAAAABEQVVWRVJHTkUgRW1tYW51ZWwgRlRSRC9EQUMvSVNTAAIB918BAAAAZAAAAAAAAACBKx+k vqMQGZ1uAN0BD1QCAAABAERBVVZFUkdORSBFbW1hbnVlbCBGVFJEL0RBQy9JU1MAU01UUABlbW1h bnVlbC5kYXV2ZXJnbmVAcmQuZnJhbmNldGVsZWNvbS5mcgADAP1fAQAAAAMA/18AAAAAAgH2DwEA AAAEAAAAAAAAAxAAAAADAAAwBAAAAAsADw4AAAAAAgH/DwEAAABuAAAAAAAAALU7wsAsdxAaobwI ACsqVsIVAAAAE95ma15h0xGoWAAgNR+SoGSIAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABJU0lT LVdHAFNNVFAAaXNpcy13Z0BleHRlcm5hbC5qdW5pcGVyLm5ldAAAAB4AAjABAAAABQAAAFNNVFAA AAAAHgADMAEAAAAdAAAAaXNpcy13Z0BleHRlcm5hbC5qdW5pcGVyLm5ldAAAAAADABUMAgAAAAMA /g8GAAAAHgABMAEAAAAKAAAAJ0lTSVMtV0cnAAAAAgELMAEAAAAiAAAAU01UUDpJU0lTLVdHQEVY VEVSTkFMLkpVTklQRVIuTkVUAAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAACAAAAElTSVMtV0cA AgH3XwEAAAAsAAAAvwAAALU7wsAsdxAaobwIACsqVsIVAAAAE95ma15h0xGoWAAgNR+SoGSIAAAD AP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABDXPAQSAAQAdAAAAUkU6IFtJc2lzLXdnXSBE b3VidCBvbiBJUy1JUwDsCAEFgAMADgAAANAHBQAbAAoANAA0AAYAbwEBIIADAA4AAADQBwUAGwAK ACUAAAAGACwBAQmAAQAhAAAAMkFCMEE1QkRCMDMzRDQxMUE4NTgwMDIwMzUxRjkyQTAA9gYBA5AG AGgLAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAAAAAA QAA5AECeG5ubx78BHgBwAAEAAAAdAAAAUkU6IFtJc2lzLXdnXSBEb3VidCBvbiBJUy1JUwAAAAAC AXEAAQAAABYAAAABv8ebmwq9pbAsM7AR1KhYACA1H5KgAAAeAB4MAQAAAAUAAABTTVRQAAAAAB4A HwwBAAAAHQAAAHNlbHZhcmFqckBmdXR1cmUuZnV0c29mdC5jb20AAAAAAwAGEP8jp7cDAAcQfwgA AB4ACBABAAAAZQAAAEVYQ0VQVFJFU09MVklOR1RJRURPRVNUSEVTTlBBSVNVU0VGVUxGT1JBTllP VEhFUlBVUlBPU0VUSEFUQ0FOVEJFRE9ORVVTSU5HU1lTVEVNSURBTFNPRk9SQlJFQUtJTkdUSUUA AAAAAgEJEAEAAADsBwAA6AcAAJwPAABMWkZ19+scXXcACgEDAfcgAqQD4wIAY4JoCsBzZXQwIAcT DwKDAFADVA9ZQm9vaxEDgk9sZAYAdHlsGmUCgzIC4w9ZVGFoCwNxAoMzDudwcnEyTQ/2fQqACMgg OwlvMsw1NQKACoF1YwBQCwMGYwBBC2BuZzEwM4MU8QvEIEV4Y2UFMRUJcHMG8HYLgGcgdJEIkCBk bweRdGgb4CBTTlBBIAQAIHV5D7BmdQMgAhAFwABweSwgbxxRBcBwCHBwb6sPsBxBYQVAYwBwJwVA emIb4m4b4B0QG4IGsHOAdGVtIElELgqiWQqAQWwbQB1zYglwYUZrG4IHYGUsIBzQZs8cQglwHbAj UXR3IaAgkGsFEBnAKAWxdgdAClAp9x7XH4IFoG0KsQmAHEIDoB0e4icEIAnwCGBnaC7zCuMKgEJ1 BUAcUB6iJA//H+Aa0AQQCsADEB3gJzAfc3ccViEFIRRJA6AfMB6xbz8jACwwIKAJwB8AJjFJU/Et kCB3aAMQKsQVkB4Alm8I4RsQdQYxb3YeMehJUCAiwEkdcAngAyBWaQVAHOFsMHB0LhFi5zByH+AB IGljCJACMBuwjSGgZw/AHENNQUMdsLxkZBshBCADUhxDRR4Sfx/gBUAcYDMwBJArayEUUL8hgB8g C2AGgR3gIvF3A2B/GcA1PxlCAUAAoABABgBFOExWQQxAAtETMXMxnjY4GhThOCkw0DM2AUBXLoIF kAVALTziTwUQZ/8LgAdABdAp4jJwPOMrdjx0DzxBCxM8dAIAaS0xNMY0AUAw0DE4MAFADNBRQINi IEYDYToMg2IBD+BEQVVWRVJHdE5FGqBtA4EKUAMgRpBUUkQvQqBDLy2QgQXwW1NNVFA6ILChQ2Qu ZGF1L3FnH+D6QAsgLgNQAHAa0CCgEsD7JdFGUV0rdUGwBmACMEIXVUHQaUWQeSLATUkQIBwyNiLA AdBBECA5OpI0FcBQTUd3VG9CF5pWAHBpBgAJ0SBLR3ccQ2NCFwQABAAtd2c4QGV4IKAEoAdALmof LyAFIDURNJFHeHViaqM8oUIXUkU6RJBJTdR2XUKQCGBiBUACIC2BLb8tkD6PP5o8BAu2ISMuVdDv AHAmQhzhMvooHJIk8Bzk9xJwC4AcQ0QtsUbSG8BSUf1RMCgi8ScwLnFZQAUQEqD3IRQHcB6SZCTw D3AR4B6zXxvgLfAnYAeQUjJlK2tS8y0QCxFzLCEUSVBDgCt6dzzjPcUb8CdaQT1hPipESmVRMEoB ESBMIiByfQOCWxlTHVEAwAMQLrA68GpqbEBcsiXROMMdUPsP4EdlRC1BUTAvcFYQCXEPTABJkGMy ScQxNzoz4jgrdSdjMFEwS99NEfNNv07PCk9QMUgwB/Bhsb9RX1JtNW5oIl4lIRRXLfMvMHQkEApQ HtRhYiBBTukg0ElIHyFyCIEEIHGw/nMghl4lHFIs4mJgZhEtQf8gZgfAXEEG4A+gHfAFMFlC/1hB cbchFHJWMr4ssRxSH+D/dZQiwCpyHFJy9CvVIPAi0O5UeD95SxzSb20QC3EmMX8DUnOYNE15FnIS CXAa0Gk/L3B+ZHlLIQUGYHQRU08RZwAwNThKIDE5OccVwAZgWSQ5LjUv4XRPP3VXCHBeFlJRCrBg MTUw/1zvXfhh4m6OTBU3QmWBK3roPiBIb3Y+jEYsMXP/73L1dX8ssXHSSDBACQAiwX8cUgWgAQAk lIxGd6pmYE93PLAygUlQYw/wM0QngCjXg6MiwIQCKYxGTR3gHAD/bQIc4S3gD8AeInC1MsKUSPd5 FguAahFmANAb4DOzLeH/D3AcQoxHkSIc0g+wMhEFsb8gdhJwgGaOb0cgV0BBBBD8dW0bgh/SLLBz l5XXlEG3MzabwpyGKSEFjKAoLDG7n3QcQ0MEAAWgG/FjnxD/nAMswVKSIsAwcQ+ABCAfkJ8mgSCQ LUMe45q5ICIgdPsg4BzUdQdAKkEytkjwMgH/BpAIkSyiA5GZaFJRHFIBAL8bcBrQIQV7wY1nBfBO IgD9BCBDOYAwwSCQHDSh13yj/6jBeYczlS3gM9FxsJtkpbH/jEal8zTRCyAt0DBwLfBYVHsLYFyB SAbwJkEHcVXQIv+VxoxGcFQFACIgG8AbkR/g+wfgMzBqmcFGkHKRIsAcUv+PkoayHJOYdpvDMiMy tYxGjxtACHCZ0XxNUERVonf+SQVAB4AAcZFlurUy+hzh7mcqgTO/NMY/jP02YCIg/x6xJcFycDyi tEGM/XvAAHC6a7GXLSSgAwCM/V/GP//HT8gajWdphGMzG4Kt8iLQfi0i0GxVae9PSIygYsZoYQJA cDovL8u/NJEvu2NCA4EvrfILgAIQL2l1/2RmK3rIH9N/1I/Vnyt6ItD/YevYX9j3hSM0kWwg2PJj uv3XJUUZwDGBBnEbkV6RPgFnBcDdTyLQVm+r4dqEKAA3MzQpLTk3NVot30AyOzUi0E9DESjeT08Q A6AHwCPBcsRQ3AqNhQJjJPAi0EZheNqEWd8aNjlAodclMgHANe8GAAhgHFAs0WQdECQRPZH4UGt3 SSFQEDBwG+AZ4Lnkh0FuA6AHEHnjTTAAKCA0OBngNCLQVVP/OaDSL+qP65/sr9Zv7Q/v3//tTywR yb/Kz86PT3bNj/Rv/8+v0L/uL/sv/D/xX/Jv839/9I/1n/av97/4z/nYGJEAAQawAwAQEAAAAAAD ABEQAAAAAB4AQhABAAAAPwAAADw5ODM4OEMwNUQ0NjREMTExQjYxODAwODA1RjE1MDQxNjAxNDhC NDc4QHAtaWJpcy5pc3N5LmNuZXQuZnI+AAADAIAQ/////0AABzDgF9Jjmce/AUAACDDgF9Jjmce/ AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAA EIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAAMAB4AIIAYAAAAAAMAAAAAA AABGAAAAAAGFAAAAAAAAHgAIgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAFAAAAOC4wNAAA AAALAAmACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAA ABGFAAAAAAAAAwALgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAAyACCAGAAAAAADAAAAA AAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgANgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAAB AAAAAAAAAB4ADoAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUA AABSRTogAAAAAAMADTT9NwAARWY= ------ =_NextPart_000_01BFC7C9.B68FE220-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat May 27 02:00:44 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09069 for ; Sat, 27 May 2000 02:00:43 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA06517; Fri, 26 May 2000 23:07:03 -0700 (PDT) Received: from fsnt.future.futusoft.com ([203.197.140.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA06489 for ; Fri, 26 May 2000 23:06:59 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Sat, 27 May 2000 11:38:23 +0530 Received: from tangcm.future.futsoft.com ([172.16.1.29]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id LAA08039; Sat, 27 May 2000 11:13:51 +0530 Message-Id: <04e901bfc7a1$5d819a20$1d0110ac@future.futsoft.com> From: "Jorge" To: "'DAUVERGNE Emmanuel FTRD/DAC/ISS'" Cc: "'ISIS-WG'" References: <01BFC7C9.B66E5060.selvarajr@future.futsoft.com> Subject: Re: [Isis-wg] Doubt on IS-IS Date: Sat, 27 May 2000 11:34:05 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by external.juniper.net id XAA06490 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 8bit I also agree with most of what Mr/Miss SELVA say . for actually now integrated Is-Is communication with IP layer only through Raw socket API , can somebody tell me how i can get the Ethernet header from raw socket with the condition that i won't encapsulate Is-Is packet with Ethernet header myself ( And also i can't make assumption that another implementation for integrated is-is will encapsulate Is-Is packet with Ethernet header in raw socket ) . ----- Original Message ----- From: SelvarajR To: 'DAUVERGNE Emmanuel FTRD/DAC/ISS' Cc: 'ISIS-WG' Sent: Saturday, May 27, 2000 10:52 AM Subject: RE: [Isis-wg] Doubt on IS-IS > Except resolving tie does the SNPA is useful for any other purpose that > can't be done using System ID. > Also for breaking Tie, if there are two string(or value) that can be > compared then that's enough. > But those string(or value) necessarily not be the SNPA. > > In case of Integrated ISIS while the protocol runs over IP , I feel it is > little bit inefficient to get the MAC address from the Ethernet header. > > > Pls clarify if wrong. > > SELVA > > -----Original Message----- > From: DAUVERGNE Emmanuel FTRD/DAC/ISS > [SMTP:emmanuel.dauvergne@rd.francetelecom.fr] > Sent: Friday, May 26, 2000 9:42 PM > To: Vani Sree K > Cc: isis-wg@external.juniper.net > Subject: RE: [Isis-wg] Doubt on IS-IS > > ...and this MAC address (SNPA) is used in the DIS election : (if no > priority > imposed) choose the highest one. > > Regards, > Manu > > -----Message d'origine----- > De: Jeff Learman [mailto:jjl@one.com] > Date: vendredi 26 mai 2000 17:38 > A: Vani Sree K > Cc: isis-wg@external.juniper.net > Objet: Re: [Isis-wg] Doubt on IS-IS > > > > Vani, > > While it is true that a LAN IIH carries a system ID, > the Intermediate System Neighbors option in a LAN IIH > carries the MAC address of the neighbor, not the system > ID. The MAC address of the neighbor is obtained from > the Ethernet header of the IIH received from the neighbor. > See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, > on page 50. > > Regards, > Jeff > > Vani Sree K wrote: > > > Hi, > > > > In the Intermediate system Neighbors option of LAN Hello, the code value > > carries the 6 Octet Mac Address. (10589, 1992) > > My doubt is whether it is the Mac Address of the interface from which the > > Hello is sent or System Id of the Intermediate system. (Assuming one of > the > > Mac address is system Id). > > (In one of the Cisco document of IS-IS, it has been stated that the > > "SystemID is usually the MAC identifier of an interface on the device. > The > > IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has > > been heard within the last Hold time..") > > > > While creating new adjacencies, the NeigbourSNPA Address is set to the > MAC > > source address of the PDU. > > It means, the source MAC address is got from the Ethernet header.? > > > > Please correct me. > > > > Thanks > > -vani > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat May 27 06:14:25 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16015 for ; Sat, 27 May 2000 06:14:25 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA06973; Sat, 27 May 2000 03:20:52 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA06944 for ; Sat, 27 May 2000 03:20:51 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id DAA26263; Sat, 27 May 2000 03:11:00 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id MAA01321; Sat, 27 May 2000 12:21:03 +0200 Message-Id: <200005271021.MAA01321@kraak.procket.com> Subject: Re: [Isis-wg] Doubt on IS-IS To: selvarajr@future.futsoft.com Date: Sat, 27 May 2000 12:21:03 +0200 (MEST) Cc: emmanuel.dauvergne@rd.francetelecom.fr ('DAUVERGNE Emmanuel FTRD/DAC/ISS'), isis-wg@external.juniper.net ('ISIS-WG') In-Reply-To: <01BFC7C9.B66E5060.selvarajr@future.futsoft.com> from "SelvarajR" at May 27, 2000 10:52:52 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > In case of Integrated ISIS while the protocol runs over IP , I feel it is > little bit inefficient to get the MAC address from the Ethernet header. > > Pls clarify if wrong. Yes, this is wrong. There is a relatively new draft proposal to define an IP encapsulation for IS-IS. But integrated ISIS, as defined in rfc1195, uses the same encapsulation as ISIS defined in ISO/IEC DIS 10589. IS-IS packets are encapsulated directly in the data-link layer. No IP headers anywhere ...... Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat May 27 06:16:42 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16031 for ; Sat, 27 May 2000 06:16:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA07021; Sat, 27 May 2000 03:23:14 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA06994 for ; Sat, 27 May 2000 03:23:13 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id DAA26277; Sat, 27 May 2000 03:13:20 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id MAA01335; Sat, 27 May 2000 12:23:23 +0200 Message-Id: <200005271023.MAA01335@kraak.procket.com> Subject: Re: [Isis-wg] Doubt on IS-IS To: tangcm@future.futsoft.com (Jorge) Date: Sat, 27 May 2000 12:23:23 +0200 (MEST) Cc: emmanuel.dauvergne@rd.francetelecom.fr ('DAUVERGNE Emmanuel FTRD/DAC/ISS'), isis-wg@external.juniper.net ('ISIS-WG') In-Reply-To: <04e901bfc7a1$5d819a20$1d0110ac@future.futsoft.com> from "Jorge" at May 27, 2000 11:34:05 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > I also agree with most of what Mr/Miss SELVA say . for actually now > integrated Is-Is communication with IP layer only through Raw socket > API , can somebody tell me how i can get the Ethernet header from raw > socket with the condition that i won't encapsulate Is-Is packet with > Ethernet header myself ( And also i can't make assumption that another > implementation for integrated is-is will encapsulate Is-Is packet with > Ethernet header in raw socket ) . These are all clearly *implementation* questions. The answers depend on the OS you use. Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Sat May 27 15:31:22 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20722 for ; Sat, 27 May 2000 15:31:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA09474; Sat, 27 May 2000 12:38:02 -0700 (PDT) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id MAA09407 for ; Sat, 27 May 2000 12:37:58 -0700 (PDT) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id VAA07198 for isis-wg@external.juniper.net; Sat, 27 May 2000 21:29:56 +0200 From: Tony Przygienda Message-Id: <200005271929.VAA07198@net4u.net4u.ch> Subject: Re: [Isis-wg] Doubt on IS-IS To: isis-wg@external.juniper.net Date: Sat, 27 May 2000 21:29:56 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > > I also agree with most of what Mr/Miss SELVA say . for actually now > > integrated Is-Is communication with IP layer only through Raw socket > > API , can somebody tell me how i can get the Ethernet header from raw > > socket with the condition that i won't encapsulate Is-Is packet with > > Ethernet header myself ( And also i can't make assumption that another > > implementation for integrated is-is will encapsulate Is-Is packet with > > Ethernet header in raw socket ) . > > These are all clearly *implementation* questions. > The answers depend on the OS you use. > > Henk. Correct, however nothings' wrong with posting implementation qeustions on this list ;-) Henk was right in the other mail as well, there is the IPv4 encaps draft and one of the reasons for it was the difficulty to get mac header in many environments. Observe however that today's deployment occurs without IPv4 encaps pretty much. If you primarily want to play with ISIS without the realities of the market-place and only care to have it talk to e.g. gated, IPv4 encaps is nice since it let's you forget most of those ethernet header problems which are not easily taken care of on any Unix platform and in fact imply writing your own encaps and lots of toying around wiht things like SOCK_PACKET stuff. -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue May 30 06:44:24 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23093 for ; Tue, 30 May 2000 06:44:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA12795; Tue, 30 May 2000 03:48:04 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id DAA12766 for ; Tue, 30 May 2000 03:48:03 -0700 (PDT) Received: from blush.juniper.net (blush.juniper.net [208.223.209.7]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id DAA11454 for ; Tue, 30 May 2000 03:37:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by blush.juniper.net (8.9.3/8.9.3) with ESMTP id DAA10944 for ; Tue, 30 May 2000 03:38:38 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22751; Tue, 30 May 2000 06:34:26 -0400 (EDT) Message-Id: <200005301034.GAA22751@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: isis-wg@juniper.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 30 May 2000 06:34:25 -0400 Subject: [Isis-wg] I-D ACTION:draft-kaplan-isis-ext-eth-02.txt Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net --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 : Extended Ethernet Frame Size Support Author(s) : M. O'Dell, J. Kaplan, J. Hayes, T. Schroeder, P. Singh, D. Morrell, J. Hsu Filename : draft-kaplan-isis-ext-eth-02.txt Pages : 4 Date : 26-May-00 This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt 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-kaplan-isis-ext-eth-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kaplan-isis-ext-eth-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000526105527.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaplan-isis-ext-eth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaplan-isis-ext-eth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000526105527.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue May 30 14:20:50 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06288 for ; Tue, 30 May 2000 14:20:50 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13305; Tue, 30 May 2000 11:27:12 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13268 for ; Tue, 30 May 2000 11:27:09 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4UIGmZ25247; Tue, 30 May 2000 14:16:48 -0400 (EDT) Message-Id: <3.0.1.32.20000530141643.0131fad0@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 30 May 2000 14:16:43 -0400 To: "Rajesh Saluja" From: Jeff Learman Subject: Re: [Isis-wg] draft-ietf-isis-3way-02.txt questions Cc: In-Reply-To: <392D2C5B.1246FA2F@nortelnetworks.com> References: <3.0.1.32.20000524162554.012f9520@mail.one.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Rajesh, Does the 3-way handshake resolve the problem of a loss of the initial CSNP? I see how the probability is reduced by handling the restart case. But over Frame Relay, for example, the first CSNP could be dropped without a restart. Is this covered by the procedure? If not, a timer could be added forcing a circuit restart if the CSNP is not received within a reasonable time. Also, if the first CSNP is lost, I would expect it to take up to 20 minutes for all systems to regenerate their LSPs, causing them to be flooded throughout the area and correcting the problem (not 18 hours). How did you come up with 18 hours? Thanks, Jeff ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue May 30 14:21:18 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06316 for ; Tue, 30 May 2000 14:21:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13331; Tue, 30 May 2000 11:27:13 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13272 for ; Tue, 30 May 2000 11:27:10 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4UIGkZ25244; Tue, 30 May 2000 14:16:47 -0400 (EDT) Message-Id: <3.0.1.32.20000530141646.012f0920@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 30 May 2000 14:16:46 -0400 To: "selvarajr@future.futsoft.com" From: Jeff Learman Subject: RE: [Isis-wg] Doubt on IS-IS Cc: "'DAUVERGNE Emmanuel FTRD/DAC/ISS'" , "'ISIS-WG'" In-Reply-To: <01BFC7C9.B66E5060.selvarajr@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net In addition to resolving the tie for Designated IS, the SNPA address in the LAN IIH is used to govern the adjacency transition from "initializing" to "up". You don't transition the adjacency for a neigboring IS to "up" until you see your MAC address in the neighbor's IIH (in the Intermediate System Neighbors option). Note that if your IS has multiple LAN interfaces on the same LAN, you will have multiple adjacencies for each neighbor IS, and each adjacency's state is independently controlled by the presence of its MAC address in the neighbor's IIH. Concerning implementation issues, most UNIX systems, including Solaris and AIX, support DLPI (Data Link Provider Interface), a STREAMS-based interface to the data link layer. This interface provides all necessary link and MAC layer addressing information. At 10:52 AM 5/27/00 +0530, SelvarajR wrote: >Except resolving tie does the SNPA is useful for any other purpose that >can't be done using System ID. >Also for breaking Tie, if there are two string(or value) that can be >compared then that's enough. >But those string(or value) necessarily not be the SNPA. > >In case of Integrated ISIS while the protocol runs over IP , I feel it is >little bit inefficient to get the MAC address from the Ethernet header. > > >Pls clarify if wrong. > >SELVA > >-----Original Message----- >From: DAUVERGNE Emmanuel FTRD/DAC/ISS >[SMTP:emmanuel.dauvergne@rd.francetelecom.fr] >Sent: Friday, May 26, 2000 9:42 PM >To: Vani Sree K >Cc: isis-wg@external.juniper.net >Subject: RE: [Isis-wg] Doubt on IS-IS > >...and this MAC address (SNPA) is used in the DIS election : (if no >priority >imposed) choose the highest one. > >Regards, >Manu > >-----Message d'origine----- >De: Jeff Learman [mailto:jjl@one.com] >Date: vendredi 26 mai 2000 17:38 >A: Vani Sree K >Cc: isis-wg@external.juniper.net >Objet: Re: [Isis-wg] Doubt on IS-IS > > > >Vani, > >While it is true that a LAN IIH carries a system ID, >the Intermediate System Neighbors option in a LAN IIH >carries the MAC address of the neighbor, not the system >ID. The MAC address of the neighbor is obtained from >the Ethernet header of the IIH received from the neighbor. >See ISO 10589:1992 Section 9.5, Intermediate System Neighbours, >on page 50. > >Regards, >Jeff > >Vani Sree K wrote: > >> Hi, >> >> In the Intermediate system Neighbors option of LAN Hello, the code value >> carries the 6 Octet Mac Address. (10589, 1992) >> My doubt is whether it is the Mac Address of the interface from which the >> Hello is sent or System Id of the Intermediate system. (Assuming one of >the >> Mac address is system Id). >> (In one of the Cisco document of IS-IS, it has been stated that the >> "SystemID is usually the MAC identifier of an interface on the device. >The >> IS Nbrs CLV lists the system Ids of all neighbors from whom a Hello has >> been heard within the last Hold time..") >> >> While creating new adjacencies, the NeigbourSNPA Address is set to the >MAC >> source address of the PDU. >> It means, the source MAC address is got from the Ethernet header.? >> >> Please correct me. >> >> Thanks >> -vani >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA >____________________________________________________________________ > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg >Attachment Converted: "c:\eudora\attach\RE [Isis-wg] Doubt on IS-IS" > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Tue May 30 14:39:18 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06681 for ; Tue, 30 May 2000 14:39:16 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13473; Tue, 30 May 2000 11:45:29 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA13444 for ; Tue, 30 May 2000 11:45:27 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id LAA32610; Tue, 30 May 2000 11:35:09 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id UAA03560; Tue, 30 May 2000 20:36:06 +0200 Message-Id: <200005301836.UAA03560@kraak.procket.com> Subject: Re: [Isis-wg] draft-ietf-isis-3way-02.txt questions To: jjl@one.com (Jeff Learman) Date: Tue, 30 May 2000 20:36:06 +0200 (MEST) Cc: rsaluja@nortelnetworks.com (Rajesh Saluja), isis-wg@external.juniper.net In-Reply-To: <3.0.1.32.20000530141643.0131fad0@mail.one.com> from "Jeff Learman" at May 30, 2000 02:16:43 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Also, if the first CSNP is lost, I would expect it to take up to It should be noted that in addition to sending a CSNP, you must also set the SRM bit for this interface on all LSPs. If the CSNP from your neighbor does arrive, you can probably unset the SRM bits for lots of LSPs. If the CSNP from your neighbor is dropped, you end up sending all LSPs to your neighbor. That is gonna take more resources than strictly needed, but at least you are sure that the LSPDBs are synced quickly. > 20 minutes for all systems to regenerate their LSPs, causing them > to be flooded throughout the area and correcting the problem > (not 18 hours). How did you come up with 18 hours? The Remaininglifetime in the LSPs is 2 bytes. So in theory you could set the Remaininglifetime of a new LSP to 65535 seconds. If you adhere strictly to 10589, such an LSP should be considered to be corrupted. However, IMHO there is no need to be so restrictive. Some implementations will work fine with Remaininglifetimes larger than 20 minutes. Some implementations will even allow you to configure the router to set the Remaininglifetime higher than 20 minutes on new LSPs. This helps to bring down the "background flooding noise". 65535 seconds is 18.7 hours. Voila .... Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 00:06:46 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17774 for ; Wed, 31 May 2000 00:06:44 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA13956; Tue, 30 May 2000 21:12:38 -0700 (PDT) Received: from net4u.net4u.ch (net4u.net4u.ch [194.191.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id VAA13928 for ; Tue, 30 May 2000 21:12:33 -0700 (PDT) Received: (from prz@localhost) by net4u.net4u.ch (8.9.3/8.9.3) id GAA03050 for isis-wg@external.juniper.net; Wed, 31 May 2000 06:03:18 +0200 From: Tony Przygienda Message-Id: <200005310403.GAA03050@net4u.net4u.ch> To: isis-wg@external.juniper.net Date: Wed, 31 May 2000 06:03:18 +0200 (MEST) X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Isis-wg] Agenda for Pittsburgh ... Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit it's time to start to gather the agenda (beside the last calls and new draft versions) for Pittsburgh. Requests for slots pls to me or Tony Li -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 09:24:27 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08680 for ; Wed, 31 May 2000 09:24:22 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA14638; Wed, 31 May 2000 06:29:16 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id GAA14610 for ; Wed, 31 May 2000 06:28:59 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id GAA04840; Wed, 31 May 2000 06:18:14 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id SAA07533; Fri, 26 May 2000 18:46:27 +0200 Message-Id: <200005261646.SAA07533@kraak.procket.com> Subject: Re: [Isis-wg] IDRPI field To: CMartin@mercury.balink.com (Martin, Christian) Date: Fri, 26 May 2000 18:46:27 +0200 (MEST) Cc: henk@Procket.com ('Henk Smit'), Thomas.M.Holland@usa.alcatel.com, isis-wg@external.juniper.net In-Reply-To: <4F8C08CC6E76D311AD1F00508B787249F8EE8A@HERMES> from "Martin, Christian" at May 25, 2000 05:10:29 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > Henk, > > I posed a question regarding this a while back. As you know, RFC1195 > indicates that the IDRPI field could be used for adminstrative tagging, a la > OSPF admin tags when the type is set to 1, or an External AS LSA (LSA 6) for > a type 2. Because TLV 131 is not well documented, different people can use it for different things. And if their technology gets deployed, the customers run into interoperability problems. > From an operational perspective, this would be useful additional > information that could aid in things like redistribution filtering. I agree it can be useful to have that kind of information available in the protocol. I'm not sure TLV 131 is the right place to do that. E.g. as far as I can see, TLV 131 stands on itself inside an LSP, and is not associated with any IP prefixes. How would you want to associate TLV 131 with particular IP prefixes ? By looking at the ordering of the TLVs inside an LSP ? For the obvious reasons, that doesn't seem a good idea to me. Can you let us know if you have a better idea about how to do that ? BTW, I tried to answer the question whether TLV 131 was deployed in the real world. I did not want to touch the subject of what it could be used for. That is another discussion. > Given all the TE work being done to extend the protocol, it should > be a relatively painless addition to the next rev. Agreed. However, if you look at the traffic-eng draft, you see there is new TLV for IP prefixes, TLV 135. Besides having wider metrics, this new TLV also has the capability to store sub-TLVs associated with an IP prefix. We designed to have these sub-TLVs to store TE info. But also other useful info can be stored there, like redistribution information. Feel free to implement a solution and write a draft about it. Yeah, yeah, yeah, I know I'm supposed to submit the next version of draft-draft-ietf-isis-traffic-0x.txt. :-) RSN ........ Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 10:29:54 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11701 for ; Wed, 31 May 2000 10:29:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA14772; Wed, 31 May 2000 07:34:44 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id HAA14740 for ; Wed, 31 May 2000 07:34:40 -0700 (PDT) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA12033; Wed, 31 May 2000 10:22:40 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 10:22:40 -0400 Message-ID: From: Bryan Boulton To: Henk Smit , CMartin@mercury.balink.com Cc: Thomas.M.Holland@usa.alcatel.com, isis-wg@external.juniper.net Subject: RE: [Isis-wg] IDRPI field Date: Wed, 31 May 2000 10:22:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > Agreed. > However, if you look at the traffic-eng draft, you see there is new > TLV for IP prefixes, TLV 135. Besides having wider metrics, this > new TLV also has the capability to store sub-TLVs associated with an > IP prefix. We designed to have these sub-TLVs to store TE info. > But also other useful info can be stored there, like redistribution > information. Feel free to implement a solution and write a draft > about it. > Are these sub-TLVs defined anywhere? I notice the traffic-eng draft describes some for the extended IS reachability TLV (22) but not TLV 135. Thanks, -Bryan Boulton -Lucent Technologies _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 11:11:18 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13290 for ; Wed, 31 May 2000 11:11:17 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA14969; Wed, 31 May 2000 08:18:20 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id XAA06578 for ; Fri, 26 May 2000 23:19:08 -0700 (PDT) Received: from siara.com ([63.200.49.95]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FV700HBDFQKN4@mta6.snfc21.pbi.net> for isis-wg@external.juniper.net; Fri, 26 May 2000 23:09:08 -0700 (PDT) Date: Fri, 26 May 2000 23:17:30 -0700 From: Tony Przygienda Subject: Re: [Isis-wg] Doubt on IS-IS To: Jorge Cc: "'DAUVERGNE Emmanuel FTRD/DAC/ISS'" , "'ISIS-WG'" Reply-to: prz@siara.com Message-id: <392F687A.89F38344@siara.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <01BFC7C9.B66E5060.selvarajr@future.futsoft.com> <04e901bfc7a1$5d819a20$1d0110ac@future.futsoft.com> Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Jorge wrote: > I also agree with most of what Mr/Miss SELVA say . for actually now integrated Is-Is communication with IP layer only through Raw socket API , can somebody tell me how i can get the Ethernet header from raw socket with the condition that i won't encapsulate Is-Is packet with Ethernet header myself ( And also i can't make assumption that another implementation for integrated is-is will encapsulate Is-Is packet with Ethernet header in raw socket ) . look @ the ISIS over IPv4 draft ... thanks -- tony _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 11:11:20 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13300 for ; Wed, 31 May 2000 11:11:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA14942; Wed, 31 May 2000 08:18:18 -0700 (PDT) Received: from scotch.djinesys.com ([198.108.6.130]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA05200 for ; Fri, 26 May 2000 11:46:10 -0700 (PDT) Received: by scotch.djinesys.com (Postfix, from userid 9140) id 2111010692; Fri, 26 May 2000 14:36:29 -0400 (EDT) Date: Fri, 26 May 2000 14:36:29 -0400 From: "Christian E. Hopps" To: isis-wg@external.juniper.net Message-ID: <20000526143628.F5180@djinesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Subject: [Isis-wg] draft-ietf-isis-traffic Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Is this draft (draft-ietf-isis-traffic) going to be reissued? It appears to have expired. Thanks, Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 11:11:22 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13301 for ; Wed, 31 May 2000 11:11:19 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id IAA14907; Wed, 31 May 2000 08:18:16 -0700 (PDT) Received: from scotch.djinesys.com ([198.108.6.130]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id LAA05166 for ; Fri, 26 May 2000 11:34:43 -0700 (PDT) Received: by scotch.djinesys.com (Postfix, from userid 9140) id 8EE6210692; Fri, 26 May 2000 14:25:01 -0400 (EDT) Date: Fri, 26 May 2000 14:25:01 -0400 From: "Christian E. Hopps" To: Henk Smit Cc: Thomas.M.Holland@usa.alcatel.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] IDRPI field Message-ID: <20000526142501.E5180@djinesys.com> References: <392BD167.F01D1888@usa.alcatel.com> <200005241353.PAA00799@kraak.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: <200005241353.PAA00799@kraak.procket.com>; from henk@Procket.com on Wed, May 24, 2000 at 03:53:46PM +0200 Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net On Wed, May 24, 2000 at 03:53:46PM +0200, Henk Smit wrote: > > I have never seen it in any LSPs. > I don't know of any vendor that has implemented this. > In fact, I'm not even sure I know that TVL 131 is supposed to do. ;-) I'm not sure but I suspect this is somehow related to RC1745. However, RFC1745 uses other bits in the 32 bit ospf tag field that aren't available with the TLV131 type 2 description. If people want to implement RFC1745 I would think the new TE TLV (using a sub-TLV) would be a better way to do it. Chris. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 11:54:31 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14555 for ; Wed, 31 May 2000 11:54:30 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA15157; Wed, 31 May 2000 09:02:02 -0700 (PDT) Received: from miata.procket.com (miata.procket.com [205.253.146.45]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA15131 for ; Wed, 31 May 2000 09:02:01 -0700 (PDT) Received: from kraak.procket.com (miata.procket.com [10.1.1.1]) by miata.procket.com (8.9.3/8.9.3) with ESMTP id IAA07031; Wed, 31 May 2000 08:51:39 -0700 From: Henk Smit X-Confidential: Procket Confidential/Need to know Received: (from henk@localhost) by kraak.procket.com (8.9.3/8.9.3) id RAA05709; Wed, 31 May 2000 17:52:27 +0200 Message-Id: <200005311552.RAA05709@kraak.procket.com> Subject: Re: [Isis-wg] IDRPI field To: bboulton@nexabit.com (Bryan Boulton) Date: Wed, 31 May 2000 17:52:26 +0200 (MEST) Cc: henk@Procket.com (Henk Smit), CMartin@mercury.balink.com, Thomas.M.Holland@usa.alcatel.com, isis-wg@external.juniper.net In-Reply-To: from "Bryan Boulton" at May 31, 2000 10:22:39 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit > > However, if you look at the traffic-eng draft, you see there is new > > TLV for IP prefixes, TLV 135. Besides having wider metrics, this > > new TLV also has the capability to store sub-TLVs associated with an > > IP prefix. We designed to have these sub-TLVs to store TE info. > > But also other useful info can be stored there, like redistribution > > information. Feel free to implement a solution and write a draft > > about it. > > > Are these sub-TLVs defined anywhere? I notice the traffic-eng draft > describes some for the extended IS reachability TLV (22) but not > TLV 135. No, none have been described yet. Henk. _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 16:25:41 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23880 for ; Wed, 31 May 2000 16:25:40 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id NAA15499; Wed, 31 May 2000 13:32:46 -0700 (PDT) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id JAA15230 for ; Wed, 31 May 2000 09:16:27 -0700 (PDT) Received: from ibnets.com (IDENT:rhan@lampry.ironbridgenetworks.com [192.168.5.169]) by ironbridgenetworks.com (8.9.3/8.9.3) with ESMTP id MAA29086 for ; Wed, 31 May 2000 12:06:09 -0400 (EDT) Message-ID: <39353A4A.16E16F6D@ibnets.com> Date: Wed, 31 May 2000 16:14:02 +0000 From: Rick Han Reply-To: rhan@ibnets.com Organization: Iron Bridge Networks X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.31 i686) X-Accept-Language: en MIME-Version: 1.0 To: isis-wg@external.juniper.net Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Subject: [Isis-wg] question on MTU Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit Hi, iso10589 (8.2.3 (c)) says that IIH should be padded (at least for the first one) to the maxsize-1. This is to make sure that allISs in the domain use the same MTU. Does this mean that MTU check is part of HELLO checking before further processing the PDU? My understanding is that there will be no adjacency established if an IS uses different MTU as other ISs are configured. Is this correct? It seems Cisco allows adjacency setup even the two routers configured different MTU, why is that? Thanks Rick -- Rick Han Iron Bridge Networks, Inc. rhan@ibnets.com (781)372-8180 _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 17:02:42 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24917 for ; Wed, 31 May 2000 17:02:41 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA15588; Wed, 31 May 2000 14:07:25 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA15560 for ; Wed, 31 May 2000 14:07:23 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4VKuWZ16738; Wed, 31 May 2000 16:56:32 -0400 (EDT) Message-Id: <3.0.1.32.20000531165626.012aabd0@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 31 May 2000 16:56:26 -0400 To: rhan@ibnets.com From: Jeff Learman Subject: Re: [Isis-wg] question on MTU Cc: isis-wg@external.juniper.net In-Reply-To: <39353A4A.16E16F6D@ibnets.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Remember that ISO 10598 requires point-to-point links to be reliable, so that failure to deliver an IS-IS PDU would cause the link to go down. Note that 8.2.2 does not require the IS to check the size of the received IIH. I think the idea was to make sure that whatever your idea of the MTU size is, that you can transmit a packet of that size without worrying about it being dropped by the link layer. If you're transmitting IIHs that are too large to be received at the other end, your data-link connection will go down and the adjacency will never come up. But this only works if the link is reliable (that is, if the link goes down if it can't deliver a packet). Since Integrated IS-IS is usually used over unreliable links (ones where failure to deliver doesn't cause anything special), the guarantee that you can actually deliver a packet of what you think is the maximum size doesn't work any more. On the other hand, isn't MTU size negotiation handled by LCP/NCP? If IS-IS is run over PPP with MTU size negotiation, this IS-IS guarantee may no longer be important. Regards, Jeff At 04:14 PM 5/31/00 +0000, Rick Han wrote: >Hi, iso10589 (8.2.3 (c)) says that IIH should be padded (at least for the >first one) to the maxsize-1. This is to make sure that allISs in the domain >use the same MTU. Does this mean that MTU check is part of HELLO checking >before further processing the PDU? My understanding is that there will be >no adjacency established if an IS uses different MTU as other ISs are >configured. Is this correct? It seems Cisco allows adjacency setup even the >two routers configured different MTU, why is that? > >Thanks > >Rick >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 17:14:06 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25117 for ; Wed, 31 May 2000 17:14:05 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA15663; Wed, 31 May 2000 14:21:57 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA15635 for ; Wed, 31 May 2000 14:21:55 -0700 (PDT) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id RAA14982; Wed, 31 May 2000 17:10:54 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 17:10:54 -0400 Message-ID: From: Jeff Parker To: Jeff Learman , rhan@ibnets.com Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] question on MTU Date: Wed, 31 May 2000 17:10:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net > I think the idea was to make sure that whatever your idea of > the MTU size is, that you can transmit a packet of that size > without worrying about it being dropped by the link layer. > If you're transmitting IIHs that are too large to be received > at the other end, your data-link connection will go down and > the adjacency will never come up. But this only works if the > link is reliable (that is, if the link goes down if it can't > deliver a packet). > > Jeff Learman Internet: jjl@one.com You could send padded packets on pt2pt until the adjacency comes up. This makes no assumptions about the reliability of the link layer. - jeff parker - Lucent Technology _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 17:33:13 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25434 for ; Wed, 31 May 2000 17:33:11 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA15736; Wed, 31 May 2000 14:40:08 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id OAA15707 for ; Wed, 31 May 2000 14:40:06 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4VLTkZ17976; Wed, 31 May 2000 17:29:46 -0400 (EDT) Message-Id: <3.0.1.32.20000531172942.0131f370@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 31 May 2000 17:29:42 -0400 To: Jeff Parker From: Jeff Learman Subject: RE: [Isis-wg] question on MTU Cc: isis-wg@external.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Jeff Good point -- that would solve the problem. This could be added to the 3-way handshake RFC. It might be unnecessary, though, when operating over links where the MTU is negotiated end-to-end and IS-IS is using the result of that negotiation. Unfortunately, it wouldn't guarantee that you can receive big packets from the other end, which might not implement the new requirement. To do that, you'd have to check the size of the neighbor's IIH and only accept it if it looks like it's padded to a maximum size, during initialization phase. (But how would you do that? Presence of any padding option over some given size?) As you probably know, the check is important to make sure that any LSP you send over the link will actually make it. It is not necessary that the MTU size be equal in both directions, so it wouldn't necessarily be a good idea to require the received IIH to match your own MTU size. While I suppose it's uncommon to have asymmetrical MTU sizes, it might be useful in certain situations, like ADSL. To add such a check would be to add a new restriction on the use of IS-IS. Regards, Jeff At 05:10 PM 5/31/00 -0400, you wrote: >> I think the idea was to make sure that whatever your idea of >> the MTU size is, that you can transmit a packet of that size >> without worrying about it being dropped by the link layer. >> If you're transmitting IIHs that are too large to be received >> at the other end, your data-link connection will go down and >> the adjacency will never come up. But this only works if the >> link is reliable (that is, if the link goes down if it can't >> deliver a packet). >> >> Jeff Learman Internet: jjl@one.com > >You could send padded packets on pt2pt until the adjacency comes up. >This makes no assumptions about the reliability of the link layer. > >- jeff parker >- Lucent Technology ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 17:58:24 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25807 for ; Wed, 31 May 2000 17:58:23 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA15878; Wed, 31 May 2000 15:05:30 -0700 (PDT) Received: from one.com (ant.one.com [192.147.230.67]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA15810 for ; Wed, 31 May 2000 15:05:27 -0700 (PDT) Received: from laptop3 (laptop3.one.com [172.22.10.48]) by one.com (8.10.0/8.10.0) with SMTP id e4VLsZZ19446; Wed, 31 May 2000 17:54:35 -0400 (EDT) Message-Id: <3.0.1.32.20000531175424.0131fc40@mail.one.com> X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 31 May 2000 17:54:24 -0400 To: rhan@ibnets.com From: Jeff Learman Subject: Re: [Isis-wg] question on MTU Cc: Jeff Parker , isis-wg@external.juniper.net In-Reply-To: <39358995.DA01210A@ibnets.com> References: <3.0.1.32.20000531172942.0131f370@mail.one.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a big, bad, nasty problem. This case is NOT handled by the protocol -- you aren't told what to do, and no matter what you do, it's not good. It was discussed in detail at the SONET Interoperability Forum, where we have the unlucky situation that the SONET management channel (normally unused by you IP folks) is specified to use an MTU size of 512 bytes, but the rest of the natural world uses a size of 1500. Fortunately, there is a solution, which can be found in ftp://ftp.atis.org/pub/sif/arch/ar820317.doc I believe that this was submitted to ISO as a defect report or technical corrigendum, but I don't know the current status. Perhaps Les Guinsberg or Tom Rutt could fill us in, if they are listening. Regards, Jeff At 09:52 PM 5/31/00 +0000, Rick Han wrote: >Suppose we have following setup: > router1 (R1) --- router2 (R2)----- router3 (R3) > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1 >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the >following LSPs from R1, if they are in 4k packets? How does R2 propagate >them to R3? I guess that's why the adjacency between R1 and R2 is supposed >to be droped at the first place. But if we accept the neighbor, then what >if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go >through to R3 but the bigger one get droped at the link. Now we have >un-synchronized database over the domain. > >Rick > >Jeff Learman wrote: >> >> Jeff >> >> Good point -- that would solve the problem. This could be added >> to the 3-way handshake RFC. It might be unnecessary, though, when >> operating over links where the MTU is negotiated end-to-end >> and IS-IS is using the result of that negotiation. >> >> Unfortunately, it wouldn't guarantee that you can receive big >> packets from the other end, which might not implement the new >> requirement. To do that, you'd have to check the size of the >> neighbor's IIH and only accept it if it looks like it's padded >> to a maximum size, during initialization phase. (But how would >> you do that? Presence of any padding option over some given >> size?) >> >> As you probably know, the check is important to make sure that >> any LSP you send over the link will actually make it. It is not >> necessary that the MTU size be equal in both directions, so >> it wouldn't necessarily be a good idea to require the received >> IIH to match your own MTU size. While I suppose it's uncommon >> to have asymmetrical MTU sizes, it might be useful in certain >> situations, like ADSL. To add such a check would be to add a >> new restriction on the use of IS-IS. >> >> Regards, >> Jeff >> >> At 05:10 PM 5/31/00 -0400, you wrote: >> >> I think the idea was to make sure that whatever your idea of >> >> the MTU size is, that you can transmit a packet of that size >> >> without worrying about it being dropped by the link layer. >> >> If you're transmitting IIHs that are too large to be received >> >> at the other end, your data-link connection will go down and >> >> the adjacency will never come up. But this only works if the >> >> link is reliable (that is, if the link goes down if it can't >> >> deliver a packet). >> >> >> >> Jeff Learman Internet: jjl@one.com >> > >> >You could send padded packets on pt2pt until the adjacency comes up. >> >This makes no assumptions about the reliability of the link layer. >> > >> >- jeff parker >> >- Lucent Technology >> >> ____________________________________________________________________ >> >> Jeff Learman Internet: jjl@one.com >> Engineering Manager Voice: (734)-975-7323 >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 >> 2725 South Industrial Pkwy, Suite 100 >> Ann Arbor, MI 48104 USA >> ____________________________________________________________________ >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 18:07:03 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26022 for ; Wed, 31 May 2000 18:07:02 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA15938; Wed, 31 May 2000 15:12:38 -0700 (PDT) Received: from redbaron.nexabit.com (d28.nexabit.com [209.6.34.253]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA15910 for ; Wed, 31 May 2000 15:12:35 -0700 (PDT) Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id SAA15200; Wed, 31 May 2000 18:01:40 -0400 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 18:01:40 -0400 Message-ID: From: Jeff Parker To: Jeff Learman , rhan@ibnets.com Cc: Jeff Parker , isis-wg@external.juniper.net Subject: RE: [Isis-wg] question on MTU Date: Wed, 31 May 2000 18:01:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I think section 8.2.3 of ISO 10589 specifies that you use the appropriate L1 or L2 BufferSize, rather than the interface MTU. - jeff parker - Lucent Technology > > This is a big, bad, nasty problem. This case is NOT handled by > the protocol -- you aren't told what to do, and no matter what you > do, it's not good. It was discussed in detail at the SONET > Interoperability Forum, where we have the unlucky situation that > the SONET management channel (normally unused by you IP folks) > is specified to use an MTU size of 512 bytes, but the rest of > the natural world uses a size of 1500. > > Fortunately, there is a solution, which can be found in > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > I believe that this was submitted to ISO as a defect report or > technical corrigendum, but I don't know the current status. > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > are listening. > > Regards, > Jeff > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > >Suppose we have following setup: > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > R3 is 2k. If R1 > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > >following LSPs from R1, if they are in 4k packets? How does > R2 propagate > >them to R3? I guess that's why the adjacency between R1 and > R2 is supposed > >to be droped at the first place. But if we accept the > neighbor, then what > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > smaller LSP can go > >through to R3 but the bigger one get droped at the link. Now we have > >un-synchronized database over the domain. > > > >Rick > > > >Jeff Learman wrote: > >> > >> Jeff > >> > >> Good point -- that would solve the problem. This could be added > >> to the 3-way handshake RFC. It might be unnecessary, though, when > >> operating over links where the MTU is negotiated end-to-end > >> and IS-IS is using the result of that negotiation. > >> > >> Unfortunately, it wouldn't guarantee that you can receive big > >> packets from the other end, which might not implement the new > >> requirement. To do that, you'd have to check the size of the > >> neighbor's IIH and only accept it if it looks like it's padded > >> to a maximum size, during initialization phase. (But how would > >> you do that? Presence of any padding option over some given > >> size?) > >> > >> As you probably know, the check is important to make sure that > >> any LSP you send over the link will actually make it. It is not > >> necessary that the MTU size be equal in both directions, so > >> it wouldn't necessarily be a good idea to require the received > >> IIH to match your own MTU size. While I suppose it's uncommon > >> to have asymmetrical MTU sizes, it might be useful in certain > >> situations, like ADSL. To add such a check would be to add a > >> new restriction on the use of IS-IS. > >> > >> Regards, > >> Jeff > >> > >> At 05:10 PM 5/31/00 -0400, you wrote: > >> >> I think the idea was to make sure that whatever your idea of > >> >> the MTU size is, that you can transmit a packet of that size > >> >> without worrying about it being dropped by the link layer. > >> >> If you're transmitting IIHs that are too large to be received > >> >> at the other end, your data-link connection will go down and > >> >> the adjacency will never come up. But this only works if the > >> >> link is reliable (that is, if the link goes down if it can't > >> >> deliver a packet). > >> >> > >> >> Jeff Learman Internet: > jjl@one.com > >> > > >> >You could send padded packets on pt2pt until the > adjacency comes up. > >> >This makes no assumptions about the reliability of the link layer. > >> > > >> >- jeff parker > >> >- Lucent Technology > >> > >> > ____________________________________________________________________ > >> > >> Jeff Learman Internet: jjl@one.com > >> Engineering Manager Voice: (734)-975-7323 > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > >> 2725 South Industrial Pkwy, Suite 100 > >> Ann Arbor, MI 48104 USA > >> > ____________________________________________________________________ > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > >-- > >Rick Han > >Iron Bridge Networks, Inc. > >rhan@ibnets.com > >(781)372-8180 > > > > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 18:28:22 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26212 for ; Wed, 31 May 2000 18:28:21 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA16012; Wed, 31 May 2000 15:34:10 -0700 (PDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id PAA15984 for ; Wed, 31 May 2000 15:34:08 -0700 (PDT) Received: from emailid-pc.cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id PAA22186; Wed, 31 May 2000 15:23:04 -0700 (PDT) Message-Id: <4.2.0.58.20000531172042.00ac4cf0@127.0.0.1> X-Sender: mbartell@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 31 May 2000 17:25:35 -0500 To: Jeff Parker , Jeff Learman , rhan@ibnets.com From: Micah Bartell Subject: RE: [Isis-wg] question on MTU Cc: Jeff Parker , isis-wg@external.juniper.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Actually the IIH should be at least maxsize-1 octets. maxsize is the maximum of the three following values: 1. dataLinkBlocksize 2. originatingL1LSPBufferSize 3. originatingL2LSPBufferSize The reason for using maxsize-1 is any padding added needs to be at least 2 octets. So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also. /mpb At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: >I think section 8.2.3 of ISO 10589 specifies that you use the appropriate >L1 or L2 BufferSize, rather than the interface MTU. > >- jeff parker >- Lucent Technology > > > > This is a big, bad, nasty problem. This case is NOT handled by > > the protocol -- you aren't told what to do, and no matter what you > > do, it's not good. It was discussed in detail at the SONET > > Interoperability Forum, where we have the unlucky situation that > > the SONET management channel (normally unused by you IP folks) > > is specified to use an MTU size of 512 bytes, but the rest of > > the natural world uses a size of 1500. > > > > Fortunately, there is a solution, which can be found in > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > I believe that this was submitted to ISO as a defect report or > > technical corrigendum, but I don't know the current status. > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > are listening. > > > > Regards, > > Jeff > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > >Suppose we have following setup: > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > R3 is 2k. If R1 > > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > > >following LSPs from R1, if they are in 4k packets? How does > > R2 propagate > > >them to R3? I guess that's why the adjacency between R1 and > > R2 is supposed > > >to be droped at the first place. But if we accept the > > neighbor, then what > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > smaller LSP can go > > >through to R3 but the bigger one get droped at the link. Now we have > > >un-synchronized database over the domain. > > > > > >Rick > > > > > >Jeff Learman wrote: > > >> > > >> Jeff > > >> > > >> Good point -- that would solve the problem. This could be added > > >> to the 3-way handshake RFC. It might be unnecessary, though, when > > >> operating over links where the MTU is negotiated end-to-end > > >> and IS-IS is using the result of that negotiation. > > >> > > >> Unfortunately, it wouldn't guarantee that you can receive big > > >> packets from the other end, which might not implement the new > > >> requirement. To do that, you'd have to check the size of the > > >> neighbor's IIH and only accept it if it looks like it's padded > > >> to a maximum size, during initialization phase. (But how would > > >> you do that? Presence of any padding option over some given > > >> size?) > > >> > > >> As you probably know, the check is important to make sure that > > >> any LSP you send over the link will actually make it. It is not > > >> necessary that the MTU size be equal in both directions, so > > >> it wouldn't necessarily be a good idea to require the received > > >> IIH to match your own MTU size. While I suppose it's uncommon > > >> to have asymmetrical MTU sizes, it might be useful in certain > > >> situations, like ADSL. To add such a check would be to add a > > >> new restriction on the use of IS-IS. > > >> > > >> Regards, > > >> Jeff > > >> > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > >> >> I think the idea was to make sure that whatever your idea of > > >> >> the MTU size is, that you can transmit a packet of that size > > >> >> without worrying about it being dropped by the link layer. > > >> >> If you're transmitting IIHs that are too large to be received > > >> >> at the other end, your data-link connection will go down and > > >> >> the adjacency will never come up. But this only works if the > > >> >> link is reliable (that is, if the link goes down if it can't > > >> >> deliver a packet). > > >> >> > > >> >> Jeff Learman Internet: > > jjl@one.com > > >> > > > >> >You could send padded packets on pt2pt until the > > adjacency comes up. > > >> >This makes no assumptions about the reliability of the link layer. > > >> > > > >> >- jeff parker > > >> >- Lucent Technology > > >> > > >> > > ____________________________________________________________________ > > >> > > >> Jeff Learman Internet: jjl@one.com > > >> Engineering Manager Voice: (734)-975-7323 > > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > >> 2725 South Industrial Pkwy, Suite 100 > > >> Ann Arbor, MI 48104 USA > > >> > > ____________________________________________________________________ > > >> > > >> _______________________________________________ > > >> Isis-wg mailing list - Isis-wg@external.juniper.net > > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > > > >-- > > >Rick Han > > >Iron Bridge Networks, Inc. > > >rhan@ibnets.com > > >(781)372-8180 > > > > > > > > ____________________________________________________________________ > > > > Jeff Learman Internet: jjl@one.com > > Engineering Manager Voice: (734)-975-7323 > > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > 2725 South Industrial Pkwy, Suite 100 > > Ann Arbor, MI 48104 USA > > ____________________________________________________________________ > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > > >_______________________________________________ >Isis-wg mailing list - Isis-wg@external.juniper.net >http://external.juniper.net/mailman/listinfo/isis-wg -- Micah Bartell, CCIE #5069 mbartell@cisco.com Network Consulting Engineer, NSA Phone: 972.364.8829 Cisco Systems, Inc Fax: 972.364.8829 -- The Network Works, No Excuses _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 19:07:57 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26834 for ; Wed, 31 May 2000 19:07:57 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16119; Wed, 31 May 2000 16:15:02 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16090 for ; Wed, 31 May 2000 16:15:00 -0700 (PDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA11108; Wed, 31 May 2000 16:04:28 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 16:04:30 -0700 Message-ID: From: Les Ginsberg To: "'Jeff Learman'" , rhan@ibnets.com Cc: Jeff Parker , isis-wg@external.juniper.net Subject: RE: [Isis-wg] question on MTU Date: Wed, 31 May 2000 16:04:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net The problem that Rick refers to is not quite as bad as his example suggests. "originatingLxBufferSize" is limited to values between 512-1492. So long as the MTU of any link over which IS-IS operates is >= 1492 there should never be a problem propagating LSPs due to PDU size issues. This issue, as Jeff remembers all too well, actually occurs only when some of the links used for IS-IS have an MTU smaller than 1492 - as is the case with SONET DCC. The solution referred to below does not eliminate the problem, but it provides the protocol with the tools to detect and report the problem, hopefully before it ever occurs. The proposal is part of the revised agenda the US has submitted to ISO for producing a new draft revision of ISO 10589:1992. Inclusion of this proposal is of course subject to review by the international community - as of this date the revised draft is not yet available and the international review process has not yet begun. Les > -----Original Message----- > From: Jeff Learman [mailto:jjl@one.com] > Sent: Wednesday, May 31, 2000 2:54 PM > To: rhan@ibnets.com > Cc: Jeff Parker; isis-wg@external.juniper.net > Subject: Re: [Isis-wg] question on MTU > > > > This is a big, bad, nasty problem. This case is NOT handled by > the protocol -- you aren't told what to do, and no matter what you > do, it's not good. It was discussed in detail at the SONET > Interoperability Forum, where we have the unlucky situation that > the SONET management channel (normally unused by you IP folks) > is specified to use an MTU size of 512 bytes, but the rest of > the natural world uses a size of 1500. > > Fortunately, there is a solution, which can be found in > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > I believe that this was submitted to ISO as a defect report or > technical corrigendum, but I don't know the current status. > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > are listening. > > Regards, > Jeff > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > >Suppose we have following setup: > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > R3 is 2k. If R1 > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > >following LSPs from R1, if they are in 4k packets? How does > R2 propagate > >them to R3? I guess that's why the adjacency between R1 and > R2 is supposed > >to be droped at the first place. But if we accept the > neighbor, then what > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > smaller LSP can go > >through to R3 but the bigger one get droped at the link. Now we have > >un-synchronized database over the domain. > > > >Rick > > > >Jeff Learman wrote: > >> > >> Jeff > >> > >> Good point -- that would solve the problem. This could be added > >> to the 3-way handshake RFC. It might be unnecessary, though, when > >> operating over links where the MTU is negotiated end-to-end > >> and IS-IS is using the result of that negotiation. > >> > >> Unfortunately, it wouldn't guarantee that you can receive big > >> packets from the other end, which might not implement the new > >> requirement. To do that, you'd have to check the size of the > >> neighbor's IIH and only accept it if it looks like it's padded > >> to a maximum size, during initialization phase. (But how would > >> you do that? Presence of any padding option over some given > >> size?) > >> > >> As you probably know, the check is important to make sure that > >> any LSP you send over the link will actually make it. It is not > >> necessary that the MTU size be equal in both directions, so > >> it wouldn't necessarily be a good idea to require the received > >> IIH to match your own MTU size. While I suppose it's uncommon > >> to have asymmetrical MTU sizes, it might be useful in certain > >> situations, like ADSL. To add such a check would be to add a > >> new restriction on the use of IS-IS. > >> > >> Regards, > >> Jeff > >> > >> At 05:10 PM 5/31/00 -0400, you wrote: > >> >> I think the idea was to make sure that whatever your idea of > >> >> the MTU size is, that you can transmit a packet of that size > >> >> without worrying about it being dropped by the link layer. > >> >> If you're transmitting IIHs that are too large to be received > >> >> at the other end, your data-link connection will go down and > >> >> the adjacency will never come up. But this only works if the > >> >> link is reliable (that is, if the link goes down if it can't > >> >> deliver a packet). > >> >> > >> >> Jeff Learman Internet: > jjl@one.com > >> > > >> >You could send padded packets on pt2pt until the > adjacency comes up. > >> >This makes no assumptions about the reliability of the link layer. > >> > > >> >- jeff parker > >> >- Lucent Technology > >> > >> > ____________________________________________________________________ > >> > >> Jeff Learman Internet: jjl@one.com > >> Engineering Manager Voice: (734)-975-7323 > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > >> 2725 South Industrial Pkwy, Suite 100 > >> Ann Arbor, MI 48104 USA > >> > ____________________________________________________________________ > >> > >> _______________________________________________ > >> Isis-wg mailing list - Isis-wg@external.juniper.net > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > >-- > >Rick Han > >Iron Bridge Networks, Inc. > >rhan@ibnets.com > >(781)372-8180 > > > > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 19:25:38 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27060 for ; Wed, 31 May 2000 19:25:37 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16198; Wed, 31 May 2000 16:32:39 -0700 (PDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16168 for ; Wed, 31 May 2000 16:32:37 -0700 (PDT) Received: from cirrus.juniper.net (cirrus.juniper.net [208.197.169.207]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id QAA27974; Wed, 31 May 2000 16:21:45 -0700 (PDT) Received: (from dkatz@localhost) by cirrus.juniper.net (8.8.7/8.7.3) id QAA10322; Wed, 31 May 2000 16:21:45 -0700 (PDT) Date: Wed, 31 May 2000 16:21:45 -0700 (PDT) Message-Id: <200005312321.QAA10322@cirrus.juniper.net> From: Dave Katz To: jjl@one.com CC: rhan@ibnets.com, jparker@nexabit.com, isis-wg@external.juniper.net In-reply-to: <3.0.1.32.20000531175424.0131fc40@mail.one.com> (message from Jeff Learman on Wed, 31 May 2000 17:54:24 -0400) Subject: Re: [Isis-wg] question on MTU Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net LSPs have an architecturally-defined maximum size (1492 if memory serves) because, unlike in OSPF, they are not regenerated hop-by-hop so they must be small enough so that they are guaranteed to be able to cross *any* media in the network. Trying to use variable sizes gets very interesting. NLSP was operationally problematic due to this (try setting the MTU to 1500 and then accidentally using SNAP encapsulation on some links--whee!) The "big, bad, nasty problem" is due to the media of choice in the SONET application having an unfortunately small MTU, and the problem is confined entirely to such media (I think ARCnet is about the only other one; see earlier comment about NLSP). It in particular is *not* any sort of problem when dealing with links having MTUs *larger* than 1492. Even if the link MTU were negotiated, it would *not* have any use in the protocol per se (other than complaining if it were too small). OSPF has a hook added after the original spec came out which won't allow neighbors to become adjacent unless their MTUs agree--this is more important because LSUpdates are built hop-by-hop and so can become MTU-sized if the implementor so desires, but it also leads to regular customer service calls asking "why are my neighbors stuck in EXSTART state." IIH padding was intended to catch badly misconfigured boxes, and to a lesser extent size-dependent errors (though the padded ones were only supposed to be sent on point-to-point links only briefly, and these are the only links that usually ever show any size dependency). IIH padding has, in practice, been largely deprecated because it is essentially useless and creates lots of unnecessary customer service calls to vendors ("Why is my adjacency stuck in Init state?"). Incoming padding should be ignored, period. --Dave X-Sender: jjl@mail.one.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 31 May 2000 17:54:24 -0400 From: Jeff Learman Cc: Jeff Parker , isis-wg@external.juniper.net References: <3.0.1.32.20000531172942.0131f370@mail.one.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net This is a big, bad, nasty problem. This case is NOT handled by the protocol -- you aren't told what to do, and no matter what you do, it's not good. It was discussed in detail at the SONET Interoperability Forum, where we have the unlucky situation that the SONET management channel (normally unused by you IP folks) is specified to use an MTU size of 512 bytes, but the rest of the natural world uses a size of 1500. Fortunately, there is a solution, which can be found in ftp://ftp.atis.org/pub/sif/arch/ar820317.doc I believe that this was submitted to ISO as a defect report or technical corrigendum, but I don't know the current status. Perhaps Les Guinsberg or Tom Rutt could fill us in, if they are listening. Regards, Jeff At 09:52 PM 5/31/00 +0000, Rick Han wrote: >Suppose we have following setup: > router1 (R1) --- router2 (R2)----- router3 (R3) > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1 >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the >following LSPs from R1, if they are in 4k packets? How does R2 propagate >them to R3? I guess that's why the adjacency between R1 and R2 is supposed >to be droped at the first place. But if we accept the neighbor, then what >if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go >through to R3 but the bigger one get droped at the link. Now we have >un-synchronized database over the domain. > >Rick > >Jeff Learman wrote: >> >> Jeff >> >> Good point -- that would solve the problem. This could be added >> to the 3-way handshake RFC. It might be unnecessary, though, when >> operating over links where the MTU is negotiated end-to-end >> and IS-IS is using the result of that negotiation. >> >> Unfortunately, it wouldn't guarantee that you can receive big >> packets from the other end, which might not implement the new >> requirement. To do that, you'd have to check the size of the >> neighbor's IIH and only accept it if it looks like it's padded >> to a maximum size, during initialization phase. (But how would >> you do that? Presence of any padding option over some given >> size?) >> >> As you probably know, the check is important to make sure that >> any LSP you send over the link will actually make it. It is not >> necessary that the MTU size be equal in both directions, so >> it wouldn't necessarily be a good idea to require the received >> IIH to match your own MTU size. While I suppose it's uncommon >> to have asymmetrical MTU sizes, it might be useful in certain >> situations, like ADSL. To add such a check would be to add a >> new restriction on the use of IS-IS. >> >> Regards, >> Jeff >> >> At 05:10 PM 5/31/00 -0400, you wrote: >> >> I think the idea was to make sure that whatever your idea of >> >> the MTU size is, that you can transmit a packet of that size >> >> without worrying about it being dropped by the link layer. >> >> If you're transmitting IIHs that are too large to be received >> >> at the other end, your data-link connection will go down and >> >> the adjacency will never come up. But this only works if the >> >> link is reliable (that is, if the link goes down if it can't >> >> deliver a packet). >> >> >> >> Jeff Learman Internet: jjl@one.com >> > >> >You could send padded packets on pt2pt until the adjacency comes up. >> >This makes no assumptions about the reliability of the link layer. >> > >> >- jeff parker >> >- Lucent Technology >> >> ____________________________________________________________________ >> >> Jeff Learman Internet: jjl@one.com >> Engineering Manager Voice: (734)-975-7323 >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 >> 2725 South Industrial Pkwy, Suite 100 >> Ann Arbor, MI 48104 USA >> ____________________________________________________________________ >> >> _______________________________________________ >> Isis-wg mailing list - Isis-wg@external.juniper.net >> http://external.juniper.net/mailman/listinfo/isis-wg > >-- >Rick Han >Iron Bridge Networks, Inc. >rhan@ibnets.com >(781)372-8180 > > ____________________________________________________________________ Jeff Learman Internet: jjl@one.com Engineering Manager Voice: (734)-975-7323 ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 2725 South Industrial Pkwy, Suite 100 Ann Arbor, MI 48104 USA ____________________________________________________________________ _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 19:44:47 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27508 for ; Wed, 31 May 2000 19:44:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16310; Wed, 31 May 2000 16:52:24 -0700 (PDT) Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id QAA16244 for ; Wed, 31 May 2000 16:52:20 -0700 (PDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by ertpg14e1.nortelnetworks.com; Wed, 31 May 2000 18:58:56 -0400 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MA0HMQGK; Wed, 31 May 2000 18:58:59 -0400 Received: from nortelnetworks.com (CC775382-A [132.245.139.162]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LS52HM0W; Wed, 31 May 2000 18:58:48 -0400 Message-ID: <39359908.80BC1973@nortelnetworks.com> Date: Wed, 31 May 2000 18:58:16 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Rajesh Saluja" Organization: Nortel Networks X-Mailer: Mozilla 4.5 [en]C-AtHome0402 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Micah Bartell CC: Jeff Parker , Jeff Learman , rhan@ibnets.com, isis-wg@external.juniper.net Subject: Re: [Isis-wg] question on MTU References: <4.2.0.58.20000531172042.00ac4cf0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net Content-Transfer-Encoding: 7bit IIH maximum size and LSP maximum size are two different things. IIH size should be at least equal to the maximum(dataLinkBlocksize (MTU),LSPBuffersize) -1 according to the spec. The LSP packet maximum size has really a global significance in an ISIS area and it should be set consistently by system management. LSP packets have to travel throughout the area. Also note that dataLinkBlocksize should always be greater than or equal to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but dataLinkBlocksize - 1. Regards, Rajesh Micah Bartell wrote: > > Actually the IIH should be at least maxsize-1 octets. maxsize is the maximum of the three following values: > > 1. dataLinkBlocksize > 2. originatingL1LSPBufferSize > 3. originatingL2LSPBufferSize > > The reason for using maxsize-1 is any padding added needs to be at least 2 octets. So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also. > > /mpb > > At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: > >I think section 8.2.3 of ISO 10589 specifies that you use the appropriate > >L1 or L2 BufferSize, rather than the interface MTU. > > > >- jeff parker > >- Lucent Technology > > > > > > This is a big, bad, nasty problem. This case is NOT handled by > > > the protocol -- you aren't told what to do, and no matter what you > > > do, it's not good. It was discussed in detail at the SONET > > > Interoperability Forum, where we have the unlucky situation that > > > the SONET management channel (normally unused by you IP folks) > > > is specified to use an MTU size of 512 bytes, but the rest of > > > the natural world uses a size of 1500. > > > > > > Fortunately, there is a solution, which can be found in > > > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > > > I believe that this was submitted to ISO as a defect report or > > > technical corrigendum, but I don't know the current status. > > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > > are listening. > > > > > > Regards, > > > Jeff > > > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > > >Suppose we have following setup: > > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > > R3 is 2k. If R1 > > > >sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the > > > >following LSPs from R1, if they are in 4k packets? How does > > > R2 propagate > > > >them to R3? I guess that's why the adjacency between R1 and > > > R2 is supposed > > > >to be droped at the first place. But if we accept the > > > neighbor, then what > > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > > smaller LSP can go > > > >through to R3 but the bigger one get droped at the link. Now we have > > > >un-synchronized database over the domain. > > > > > > > >Rick > > > > > > > >Jeff Learman wrote: > > > >> > > > >> Jeff > > > >> > > > >> Good point -- that would solve the problem. This could be added > > > >> to the 3-way handshake RFC. It might be unnecessary, though, when > > > >> operating over links where the MTU is negotiated end-to-end > > > >> and IS-IS is using the result of that negotiation. > > > >> > > > >> Unfortunately, it wouldn't guarantee that you can receive big > > > >> packets from the other end, which might not implement the new > > > >> requirement. To do that, you'd have to check the size of the > > > >> neighbor's IIH and only accept it if it looks like it's padded > > > >> to a maximum size, during initialization phase. (But how would > > > >> you do that? Presence of any padding option over some given > > > >> size?) > > > >> > > > >> As you probably know, the check is important to make sure that > > > >> any LSP you send over the link will actually make it. It is not > > > >> necessary that the MTU size be equal in both directions, so > > > >> it wouldn't necessarily be a good idea to require the received > > > >> IIH to match your own MTU size. While I suppose it's uncommon > > > >> to have asymmetrical MTU sizes, it might be useful in certain > > > >> situations, like ADSL. To add such a check would be to add a > > > >> new restriction on the use of IS-IS. > > > >> > > > >> Regards, > > > >> Jeff > > > >> > > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > > >> >> I think the idea was to make sure that whatever your idea of > > > >> >> the MTU size is, that you can transmit a packet of that size > > > >> >> without worrying about it being dropped by the link layer. > > > >> >> If you're transmitting IIHs that are too large to be received > > > >> >> at the other end, your data-link connection will go down and > > > >> >> the adjacency will never come up. But this only works if the > > > >> >> link is reliable (that is, if the link goes down if it can't > > > >> >> deliver a packet). > > > >> >> > > > >> >> Jeff Learman Internet: > > > jjl@one.com > > > >> > > > > >> >You could send padded packets on pt2pt until the > > > adjacency comes up. > > > >> >This makes no assumptions about the reliability of the link layer. > > > >> > > > > >> >- jeff parker > > > >> >- Lucent Technology > > > >> > > > >> > > > ____________________________________________________________________ > > > >> > > > >> Jeff Learman Internet: jjl@one.com > > > >> Engineering Manager Voice: (734)-975-7323 > > > >> ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > > >> 2725 South Industrial Pkwy, Suite 100 > > > >> Ann Arbor, MI 48104 USA > > > >> > > > ____________________________________________________________________ > > > >> > > > >> _______________________________________________ > > > >> Isis-wg mailing list - Isis-wg@external.juniper.net > > > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > >-- > > > >Rick Han > > > >Iron Bridge Networks, Inc. > > > >rhan@ibnets.com > > > >(781)372-8180 > > > > > > > > > > > ____________________________________________________________________ > > > > > > Jeff Learman Internet: jjl@one.com > > > Engineering Manager Voice: (734)-975-7323 > > > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > > > 2725 South Industrial Pkwy, Suite 100 > > > Ann Arbor, MI 48104 USA > > > ____________________________________________________________________ > > > > > > _______________________________________________ > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > >_______________________________________________ > >Isis-wg mailing list - Isis-wg@external.juniper.net > >http://external.juniper.net/mailman/listinfo/isis-wg > > -- > Micah Bartell, CCIE #5069 mbartell@cisco.com > Network Consulting Engineer, NSA Phone: 972.364.8829 > Cisco Systems, Inc Fax: 972.364.8829 > -- > The Network Works, No Excuses > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 20:17:47 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28176 for ; Wed, 31 May 2000 20:17:47 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA16401; Wed, 31 May 2000 17:24:48 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id RAA16369 for ; Wed, 31 May 2000 17:24:46 -0700 (PDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA13106; Wed, 31 May 2000 17:14:18 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 17:14:21 -0700 Message-ID: From: Les Ginsberg To: "'Rajesh Saluja'" , Micah Bartell Cc: Jeff Parker , Jeff Learman , rhan@ibnets.com, isis-wg@external.juniper.net Subject: RE: [Isis-wg] question on MTU Date: Wed, 31 May 2000 17:14:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net (At the risk of belaboring a point...) dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of sending a padded IIH which is the maximum of the bunch is precisely to detect those misconfigurations where this is not the case. So if dataLinkBlockSize is NOT large enough, the adjacency presumably will never come up. Therefore stating that "So IMHO IIH size is nothing but dataLinkBlocksize - 1." is denying the possibility of a misconfiguration. I believe the original text in ISO 10589 8.2.3c is better, even if it rarely comes into play. Of course, given the global significance of originatingLxLSPBufferSize, this still does not guarantee consistency throughout the area/domain - hence the problem that occurs in SONET environments. Les > -----Original Message----- > From: Rajesh Saluja [mailto:rsaluja@nortelnetworks.com] > Sent: Wednesday, May 31, 2000 3:58 PM > To: Micah Bartell > Cc: Jeff Parker; Jeff Learman; rhan@ibnets.com; > isis-wg@external.juniper.net > Subject: Re: [Isis-wg] question on MTU > > > IIH maximum size and LSP maximum size are two different > things. IIH size > should be at least equal to the maximum(dataLinkBlocksize > (MTU),LSPBuffersize) -1 according to the spec. > The LSP packet maximum size has really a global significance > in an ISIS > area and it should be set consistently by system management. > LSP packets > have to travel throughout the area. > > Also note that dataLinkBlocksize should always be greater > than or equal > to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but > dataLinkBlocksize - 1. > > Regards, > Rajesh > > Micah Bartell wrote: > > > > Actually the IIH should be at least maxsize-1 octets. > maxsize is the maximum of the three following values: > > > > 1. dataLinkBlocksize > > 2. originatingL1LSPBufferSize > > 3. originatingL2LSPBufferSize > > > > The reason for using maxsize-1 is any padding added needs > to be at least 2 octets. So if the PDU length is maxsize-1 > you can't add 2 octets, requiring that to be a valid size also. > > > > /mpb > > > > At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote: > > >I think section 8.2.3 of ISO 10589 specifies that you use > the appropriate > > >L1 or L2 BufferSize, rather than the interface MTU. > > > > > >- jeff parker > > >- Lucent Technology > > > > > > > > This is a big, bad, nasty problem. This case is NOT handled by > > > > the protocol -- you aren't told what to do, and no > matter what you > > > > do, it's not good. It was discussed in detail at the SONET > > > > Interoperability Forum, where we have the unlucky situation that > > > > the SONET management channel (normally unused by you IP folks) > > > > is specified to use an MTU size of 512 bytes, but the rest of > > > > the natural world uses a size of 1500. > > > > > > > > Fortunately, there is a solution, which can be found in > > > > > > > > ftp://ftp.atis.org/pub/sif/arch/ar820317.doc > > > > > > > > I believe that this was submitted to ISO as a defect report or > > > > technical corrigendum, but I don't know the current status. > > > > Perhaps Les Guinsberg or Tom Rutt could fill us in, if they > > > > are listening. > > > > > > > > Regards, > > > > Jeff > > > > > > > > At 09:52 PM 5/31/00 +0000, Rick Han wrote: > > > > >Suppose we have following setup: > > > > > router1 (R1) --- router2 (R2)----- router3 (R3) > > > > > > > > > >linkMTU between R1 and R2 is 4k, and linkMTU between R2 and > > > > R3 is 2k. If R1 > > > > >sends a HELLO padded to 4k and R2 accepts it. What > does R2 do to the > > > > >following LSPs from R1, if they are in 4k packets? How does > > > > R2 propagate > > > > >them to R3? I guess that's why the adjacency between R1 and > > > > R2 is supposed > > > > >to be droped at the first place. But if we accept the > > > > neighbor, then what > > > > >if R1 sends two LSPs, one in 1.5k and another in 3k? The > > > > smaller LSP can go > > > > >through to R3 but the bigger one get droped at the > link. Now we have > > > > >un-synchronized database over the domain. > > > > > > > > > >Rick > > > > > > > > > >Jeff Learman wrote: > > > > >> > > > > >> Jeff > > > > >> > > > > >> Good point -- that would solve the problem. This > could be added > > > > >> to the 3-way handshake RFC. It might be > unnecessary, though, when > > > > >> operating over links where the MTU is negotiated end-to-end > > > > >> and IS-IS is using the result of that negotiation. > > > > >> > > > > >> Unfortunately, it wouldn't guarantee that you can receive big > > > > >> packets from the other end, which might not implement the new > > > > >> requirement. To do that, you'd have to check the size of the > > > > >> neighbor's IIH and only accept it if it looks like > it's padded > > > > >> to a maximum size, during initialization phase. > (But how would > > > > >> you do that? Presence of any padding option over some given > > > > >> size?) > > > > >> > > > > >> As you probably know, the check is important to make > sure that > > > > >> any LSP you send over the link will actually make > it. It is not > > > > >> necessary that the MTU size be equal in both directions, so > > > > >> it wouldn't necessarily be a good idea to require > the received > > > > >> IIH to match your own MTU size. While I suppose > it's uncommon > > > > >> to have asymmetrical MTU sizes, it might be useful in certain > > > > >> situations, like ADSL. To add such a check would be to add a > > > > >> new restriction on the use of IS-IS. > > > > >> > > > > >> Regards, > > > > >> Jeff > > > > >> > > > > >> At 05:10 PM 5/31/00 -0400, you wrote: > > > > >> >> I think the idea was to make sure that whatever > your idea of > > > > >> >> the MTU size is, that you can transmit a packet > of that size > > > > >> >> without worrying about it being dropped by the link layer. > > > > >> >> If you're transmitting IIHs that are too large to > be received > > > > >> >> at the other end, your data-link connection will > go down and > > > > >> >> the adjacency will never come up. But this only > works if the > > > > >> >> link is reliable (that is, if the link goes down > if it can't > > > > >> >> deliver a packet). > > > > >> >> > > > > >> >> Jeff Learman Internet: > > > > jjl@one.com > > > > >> > > > > > >> >You could send padded packets on pt2pt until the > > > > adjacency comes up. > > > > >> >This makes no assumptions about the reliability of > the link layer. > > > > >> > > > > > >> >- jeff parker > > > > >> >- Lucent Technology > > > > >> > > > > >> > > > > > ____________________________________________________________________ > > > > >> > > > > >> Jeff Learman Internet: > jjl@one.com > > > > >> Engineering Manager Voice: > (734)-975-7323 > > > > >> ONE (Open Networks Engineering, Inc) Fax: > (734)-975-6940 > > > > >> 2725 South Industrial Pkwy, Suite 100 > > > > >> Ann Arbor, MI 48104 USA > > > > >> > > > > > ____________________________________________________________________ > > > > >> > > > > >> _______________________________________________ > > > > >> Isis-wg mailing list - Isis-wg@external.juniper.net > > > > >> http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > >-- > > > > >Rick Han > > > > >Iron Bridge Networks, Inc. > > > > >rhan@ibnets.com > > > > >(781)372-8180 > > > > > > > > > > > > > > > ____________________________________________________________________ > > > > > > > > Jeff Learman Internet: > jjl@one.com > > > > Engineering Manager Voice: > (734)-975-7323 > > > > ONE (Open Networks Engineering, Inc) Fax: > (734)-975-6940 > > > > 2725 South Industrial Pkwy, Suite 100 > > > > Ann Arbor, MI 48104 USA > > > > > ____________________________________________________________________ > > > > > > > > _______________________________________________ > > > > Isis-wg mailing list - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > > > > > > >_______________________________________________ > > >Isis-wg mailing list - Isis-wg@external.juniper.net > > >http://external.juniper.net/mailman/listinfo/isis-wg > > > > -- > > Micah Bartell, CCIE #5069 mbartell@cisco.com > > Network Consulting Engineer, NSA Phone: 972.364.8829 > > Cisco Systems, Inc Fax: 972.364.8829 > > -- > > The Network Works, No Excuses > > > > _______________________________________________ > > Isis-wg mailing list - Isis-wg@external.juniper.net > > http://external.juniper.net/mailman/listinfo/isis-wg > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg From isis-wg-admin@external.juniper.net Wed May 31 23:42:51 2000 Received: from external.juniper.net (spider.juniper.net [208.197.169.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02931 for ; Wed, 31 May 2000 23:42:51 -0400 (EDT) Received: from spider.juniper.net (localhost [127.0.0.1]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA16617; Wed, 31 May 2000 20:50:01 -0700 (PDT) Received: from yarilo.pluris.com (pluris.com [208.227.9.12]) by external.juniper.net (8.9.3/8.9.3) with ESMTP id UAA16583 for ; Wed, 31 May 2000 20:49:59 -0700 (PDT) Received: from monterey.pluris.com (monterey.pluris.com [172.16.50.17]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA16244; Wed, 31 May 2000 20:39:30 -0700 (PDT) Received: by MONTEREY with Internet Mail Service (5.5.2650.21) id ; Wed, 31 May 2000 20:39:33 -0700 Message-ID: From: Les Ginsberg To: "'Jeff Learman'" , Jeff Parker Cc: isis-wg@external.juniper.net Subject: RE: [Isis-wg] question on MTU Date: Wed, 31 May 2000 20:39:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: isis-wg-admin@external.juniper.net Errors-To: isis-wg-admin@external.juniper.net X-Mailman-Version: 1.0rc3 Precedence: bulk List-Id: IETF IS-IS working group X-BeenThere: isis-wg@external.juniper.net I agree - I think it would be a useful addition to the three way handshake RFC - send padded IIHs until the adjacency is in the UP state. I also agree that the receiving side should not check the size of the received IIH. In addition to solving the issue in cases where the "first" IIH was lost, it would eliminate wording in 10589 that has always been a bit confusing. The use of the term "first" IIH PDU was never unambiguous. It really meant the IIH sent as a result of receiving an ISH PDU and if for some strange reason multiple ISH PDUs were received then one was left to wonder how to resolve the designation of an IIH sent in response to receipt of an ISH which was not the "first". Much less ambiguous to say "an IIH should be padded if the adjacency is not in the UP state". Les > -----Original Message----- > From: Jeff Learman [mailto:jjl@one.com] > Sent: Wednesday, May 31, 2000 2:30 PM > To: Jeff Parker > Cc: isis-wg@external.juniper.net > Subject: RE: [Isis-wg] question on MTU > > > > Jeff > > Good point -- that would solve the problem. This could be added > to the 3-way handshake RFC. It might be unnecessary, though, when > operating over links where the MTU is negotiated end-to-end > and IS-IS is using the result of that negotiation. > > Unfortunately, it wouldn't guarantee that you can receive big > packets from the other end, which might not implement the new > requirement. To do that, you'd have to check the size of the > neighbor's IIH and only accept it if it looks like it's padded > to a maximum size, during initialization phase. (But how would > you do that? Presence of any padding option over some given > size?) > > As you probably know, the check is important to make sure that > any LSP you send over the link will actually make it. It is not > necessary that the MTU size be equal in both directions, so > it wouldn't necessarily be a good idea to require the received > IIH to match your own MTU size. While I suppose it's uncommon > to have asymmetrical MTU sizes, it might be useful in certain > situations, like ADSL. To add such a check would be to add a > new restriction on the use of IS-IS. > > Regards, > Jeff > > At 05:10 PM 5/31/00 -0400, you wrote: > >> I think the idea was to make sure that whatever your idea of > >> the MTU size is, that you can transmit a packet of that size > >> without worrying about it being dropped by the link layer. > >> If you're transmitting IIHs that are too large to be received > >> at the other end, your data-link connection will go down and > >> the adjacency will never come up. But this only works if the > >> link is reliable (that is, if the link goes down if it can't > >> deliver a packet). > >> > >> Jeff Learman Internet: jjl@one.com > > > >You could send padded packets on pt2pt until the adjacency > comes up. > >This makes no assumptions about the reliability of the link layer. > > > >- jeff parker > >- Lucent Technology > > ____________________________________________________________________ > > Jeff Learman Internet: jjl@one.com > Engineering Manager Voice: (734)-975-7323 > ONE (Open Networks Engineering, Inc) Fax: (734)-975-6940 > 2725 South Industrial Pkwy, Suite 100 > Ann Arbor, MI 48104 USA > ____________________________________________________________________ > > _______________________________________________ > Isis-wg mailing list - Isis-wg@external.juniper.net > http://external.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@external.juniper.net http://external.juniper.net/mailman/listinfo/isis-wg